High-level Languages and Speed

nitsudima writes to tell us Informit's David Chisnall takes a look at the 'myth' of high-level languages versus speed and why it might not be entirely accurate. From the article: "When C was created, it was very fast because it was almost trivial to turn C code into equivalent machine code. But this was only a short-term benefit; in the 30 years since C was created, processors have changed a lot. The task of mapping C code to a modern microprocessor has gradually become increasingly difficult. Since a lot of legacy C code is still around, however, a huge amount of research effort (and money) has been applied to the problem, so we still can get good performance from the language."

Comments

Old debate

[overshoot]

Twenty years ago we were still in the midst of the "language wars" and this was a hot topic. The argument then, as now, was whether a high-level language could be compiled as efficiently as a low-level language like C [1].

Well, we ran our own tests. We took a sizable chunk of supposedly well-written time-critical code that the gang had produced in what was later to become Microsoft C [2] and rewrote the same modules in Logitech Modula-2. The upshot was that the M2 code was measurably faster, smaller, and on examination better optimized. Apparently the C compiler was handicapped by essentially having to figure out what the programmer meant with a long string of low-level expressions.

Extrapolations to today are left to the reader.

[1] I used to comment that C is not a high-level language, which would induce elevated blood pressure in C programmers. After working them up, I'd bet beer money on it -- and then trot out K&R, which contains the exact quote, "C is not a high-level language."
[2] MS originally relabled another company's C complier under license (I forget their name; they were an early object lesson.)

Re:Old debate

[CapnOats.com]

...trot out K&R, which contains the exact quote, "C is not a high-level language."

Actually the quote from my copy of K&R, on my desk beside me is,

C is not a "very high level" language...

emphasis is mine.

Re:Old debate

[shreevatsa]

For what it's worth, at The Computer Language Shootout, OCaml does pretty well. Of course, C is still faster for most things (but note that the really high factors (29 and 281) are in OCaml's favour!), but OCaml is pretty fast compared to Java or Perl. Haskell does pretty well too. Functional programming, anyone?
Of course, these benchmarks measure only speed, are just for fun, and are "flawed", but they are still interesting to play with. If you haven't seen the site before, enjoy fiddling with things to try and get your favourite language on top :)

Re:Old debate

[Marcos Eliziario]

Not really. Modern pipelined architectures make hard-written assembler slower than compiler generated. A human can't really deal with out-of-order execution.

Re:Old debate

[The_Wilschon]

Garbage collection, a form of memory management in widespread use today, was invented "around 1959" by John McCarthy as he discovered LISP. This predates K&R, first edition in 1978, by quite a bit.

Re:Old debate

[civilizedINTENSITY]

Actually, there was, way before C (let alone Java or C#.)

"Lisp is very old language, second only to Fortran in the family tree of high level languages." A Little history

Whereas C (rather like Fortran) wanted to stay "close to the metal", Lisp wanted to transcend metal to get closer to the math. Hence, innante elegance :-)

Towards the end of the initial period, it became clear that this combination of ideas made an elegant mathematical system as well as a practical programming language. Then mathematical neatness became a goal and led to pruning some features from the core of the language. This was partly motivated by esthetic reasons and partly by the belief that it would be easier to devise techniques for proving programs correct if the semantics were compact and without exceptions. The results of (Cartwright 1976) and (Cartwright and McCarthy 1978), which show that LISP programs can be interpreted as sentences and schemata of first order logic, provide new confirmation of the original intuition that logical neatness would pay off.

It is true that Lisp ran inside an interpreter rather than a VM. Still, garbage collection is *old*, and memory management techniques from the 1950s/60s shouldn't be considered a new thing.

Still waiting for the Visual.Lisp.Net, though :-) When UML and visual design paradims are finally swallowed by Lisp, oh what fun times we'll have! ;-)

Re:It's very simple

[rbarreira]

I'm no assembly guru, but I don't think I would have done as well writing assembly by hand

I don't believe this as much as the people who I see repeating that sentence all the time...

Not many years ago (with gcc), I got an 80% speed improvement just by rewriting a medium sized function to assembly. Granted, it was a function which was in itself, half C code, half inline assembly, which might hinder gcc a bit. But it's also important to note that if the function had been written in pure C code, the compiler wouldn't have generated better code anyway since it wouldn't use MMX opcodes... Last I checked, MMX code is only generated from pure C in modern compilers when it's quite obvious that it can be used, such as in short loops doing simple arithmetic operations.

An expert assembly programmer in a CPU which he knows well can still do much better than a compiler.

Re:It goes both ways

[pesc]

20 years ago there was nothing strange about having an actual quicksort machine instruction (VAXen had it).

While the VAX had some complex instructions (such as double-linked queue handling), it did not have a quicksort instruction.

Here is the instruction set manual.

Re:Article is theory not practice - no measurement

[mrchaotica]

The proof is in the pudding as they say

No, what they say is "the proof of the pudding is in the eating." (Just pointing it out because most people get it wrong.)

Re:Student Perspective

[embracethenerdwithin]

I thought it might be helpful for a current student to let you know what it is we learn today at my college. I'm a senior Software Engineering major, not a comp sci major. Comp Sci is another department and has a totaly different focus. They focus on super efficent algorithms, we focus on developing large software projects.

My software engineering program has been very Java intensive. My software engineering class, object oriented class, and software testing class were all java based. We dabbled in C# a bit as well.

However, I also had an assembly class, a programming languages class where we learned perl and scheme(this language sucks) and about five algorithms classes in C++. I also had an embedded systems class in both C and assembly(learned assembly MCU code, then did C).

I feel like this is all pretty well rounded; I've learned a bunch of languages and am not really specialized in one. I'd say I am best at Java right now, but I can also write C++ code just fine.

I've never been told a computer has any kind of crazy limitless performance. In embedded systems, I learned about performance. Making a little PIC microcontroller calculate arctan was fun(took literally 30 seconds without a smart solution). I also learned that there is a trade off between several things such as performance, development time, readability, and portability.

We are taught to see languages as tools, you look at your problem and pull a tool out of the tool box that you think fit the problem best. You have to weigh whats important for the project and chose based off of that.

The final thing I'd like to point out is that one huge issue with software today is it is bug ridden. How easy something is a test makes a big difference in my opinion. Assembly and C will pretty much always be harder to test than languages like Java and C#.

I don't think the universities are the problem, at least not in my experience.

C and Smalltalk is what happened.

[LWATCDR]

C became popular because of Unix. Since you could get the source code for Unix most big universities used Unix in there OS courses. And since it was written in c you where going to learn C if took Computer Science. Textbooks started to assume you knew c. Magazines started to assume you knew c. People wrote free small c compilers and then came GCC, so now you could have a good free c compiler for just about any system. But before GCC all the buzz was about Smalltalk. Smalltalk was the future. OOP was going to replace structured programing. The problem was very few people has a computer that could run Smalltalk. So C++ was born.
A final blow to Modula-2 was simply Borland didn't create a Modula-2 compiler. For many years when you said Pascal you reall meant Turbo or Borland Pascal. Borland was the Pascal company and they add objects to pascal and eventual created Delphi.
I am sure Topspeed has closed up shop. There just isn't much room for compiler makers anymore. You have the free software at the bottom end and the Microsoft Monster at the top. Only a few niche players are left. Ada seems to be a place where a good compiler company can still make a few dollars.

Re:Imaginary history

[masklinn]

LISP was not "the archetypal high-level language." The very names CAR and CDR mean "contents of address register" and "contents of decrement register," direct references to hardware registers on the IBM 704.

You forgot "CONS" which comes from the IBM cons cells (a 36bit machine word on the 704), which is the block holding both a CAR and a CDR.

The thing is, the names only existed because no one found any better name for them, or any more interresting name (Common Lisp now offers the "first" and "rest" aliases to CAR and CDR... yet quite a lot of people still prefer using CAR and CDR).

LISP has always been a high level language, because it was started from mathematics (untyped lambda calculus) and only then adapted to computers.

And the fact that Lisp Machines (trying to get away from the Von Neumann model) were built doesn't mean that Lisp is a low level language, only that IA labs needed power that the Lisp => Von Neumann machines mappings could not give them at that time.

Lisp is a high level languages, because Lisp abstracts the machine away (no memory management, not giving a fuck about registers or machine words [may I remind you that Lisp was one of the first languages with unbound integers and automatic promotion from machine to unbound integers?])