This is not an answer to just the latest post, it is directed at multiple
posts.
1. C# is typically compiled to Common Intermediate Language which very much
is a form of "byte code" in that it is not directly executed by the
processor. The .net environment will just in time compile that into a
machine representation, or you can ahead of time compile that into a native
image. Still, CIL is involved, and while it is not Java Byte Code, it is a
byte code.
2. C is closer to "portable" than other high level languages because it
doesn't attempt to do as much. It doesn't have the huge run time
environment of .net or Java. However, at some point, any library code you
use, if available on more than one platform, even if written in C, will
begin to take advantage of the preprocessor or separate source modules so
as to smooth over imperfect portability.
3. C++ is just as "portable" as C. I can write C++ that runs on multiple
platforms and uses multiple compilers. It was designed to run well on the
same types of platforms where C runs well. It has the same difficulties
with cross platform as C, needing to use different source files or
conditionalized code via the preprocessor.
3a. I'll grant that C++ does not have as many shipping compilers in the
world as does C, so in that sense C is more portable. It is easier to write
a C compiler than a C++ compiler. And that different C++ compilers support
the language to greater and lesser extents, so it is not as portable. That
being said, the reason C is so portable is that a lot of people ignore
language features that came after C89/C90 and that rely on implementation
defined behavior (or use the preprocessor). I just don't encounter C99 or
C11 code much at all in the wild.
4. Even modern CPUs aren't directly executing all of the machine code our
compilers generate. Those instructions often get re-written internally to
various microcode instructions. From that perspective, our CPUs JIT
"compile" the lowest level machine code we can provide into something even
better for them.
5. The more important aspect of efficiency is not whether your language
compiles to machine code or some byte code or uses object oriented
abstractions or goes for straight procedural code. The more important thing
is using efficient algorithms and data structures. A smart algorithm on a
very high level run time byte code interpreted language (say Python) *can*
beat the pants off a pedestrian algorithm written in finely tuned C.
I like C, and C++, and C#, and Python, and JavaScript, and a bunch of other
languages. Each have their place. I *prefer* C++ with certain libraries as
it gives me a good blend of low level capabilities of C with the higher
level abstractions available from an object oriented language and the
availability of much functionality in huge frameworks like C# & Java.
Too many of these technology based discussions (whether languages or
operating systems or text editors or database engines or whatever) break
down into almost a religious fervor of "this is the one true {fill in the
blank}". Our job as programmers or developers or engineers (pick your
label) is to express things in a form that the computer can process.
SDR
On Mon, Jun 15, 2015 at 5:26 AM, <david at andl.org> wrote:
> Ditto. My C# code routinely gets close to native C performance whenever I
> get around to benchmarking it, which is not often these days. And I can
> actually write code that runs safely on my 8 cores or on my teraflop GPU if
> I really need the speed.
>
> But as I said, I really don't think this is the place. I hate seeing posts
> like that pass without response but I think I've said more than enough on
> the subject. The hazards of https://xkcd.com/386/ are ever-present.
>
> Regards
> David M Bennett FACS
>
> Andl - A New Database Language - andl.org
>
> -----Original Message-----
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:
> sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Alex Bowden
> Sent: Monday, 15 June 2015 7:46 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Mozilla wiki 'avoid SQLite'
>
> Oh dear. So you think that a high level language is one that does things
> by calling a lower level language? Stop embarrassing yourself.
>
> A high level language is one where the language designers are free to use
> whatever structural concepts best fit the problems that the language is
> designed to address, whereas a low level language is one where the
> language designers are restricted to using structural concepts that map
> directly onto an assumed hardware model.
>
> The assumption that a low level language compiles to assembler is
> nonsense. I don?t remember any of them doing this before C, and even
> later, many compilers still compile directly to machine code.
>
> Assuming that higher level languages compile to lower level languages is
> also nonsense. And even for ones that do, and a classic example of a
> language designed to do this would be Ratfor, then provided that the lower
> level language is compiling to machine code, then the only thing that is
> being slowed is the build process. Not runtime execution.
>
> Now 20 years ago, folk like you, but better informed, would have argued
> that well written lower level language code was more efficient than higher
> level language code. And sometimes they would have been correct. But note
> the qualification of well written. And even then, this was debatable. If
> a language provides efficient higher level data structures, or fine grain
> synchronisation of multiple threads, then the user is more likely to use
> them than if they have to create them themselves for each platform.
>
> However today, it is rarely true.
>
> Good modern optimisers can achieve efficiency that few, if any, low level
> language programmers will ever achieve.
>
> And the thing is, that those compilers can do far broader optimisation of
> higher level languages that don?t expose features like the ability to write
> to a random address. The optimisation potential of C, beyond very local
> optimisation, is minimal.
>
> I?ve been running the same little benchmark across every hardware and
> language platform that I?ve used, for over 30 years.
>
> And I confess, I was very surprised when Java passed C in about 2005. And
> yes, that was Java compiled to byte codes with runtime JIT compilation of
> the byte codes to machine code. But it was faster.
>
> The trend hasn?t reversed.
>
>
>
> > On 14 Jun 2015, at 23:42, Scott Doctor <scott at scottdoctor.com> wrote:
> >
> > On 6/14/2015 3:00 PM, Simon Slavin wrote:
> >> The result is that that higher level the language you write in, the
> better.
> >
> > I disagree. The use of languages higher than C result in slow bloated
> code. A language that calls a language that calls a language. Simple
> programs become multi-megabyte resource hogs. I agree that C compilers are
> able to optimize assembler code to a level that hand-coded assembler
> probably could not achieve. The problem is that higher level languages are
> not compiling to assembler, but compiling to the language below it.
> >
> > ------------
> > Scott Doctor
> > scott at scottdoctor.com
> > ------------------
> >
> >
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users at mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
--
Scott Robison
