Article: Debunking the Myth of High-level Languages
Oliver Wong
<quote>
High-level languages are not intrinsically slow! David Chisnall explains how
programming in a low-level language can make a compiler's job harder,
essentially wasting effort and slowing down your program's processing.
</quote>
New info for me:
* Inlining saves a lot of CPU time. With JIT compilation, you can actually
inline calls to the standard libraries, and the linkage won't be preserved
between program invocations, so the library can be updated without going out
of sync with the library; something AOT compilers can't do.
* Arrays are a low level data abstraction, and are hard to optimize from a
compiler's perspective.
* A modern Pentium 4, for example, can have about 150 instructions in-flight
at once. To write optimal assembly code for this machine, the developer must
track a window of 150 instructions at any point to reduce dependencies. Such
work is much easier for a machine than for a human, so gradually machines
did it more and more.
- Oliver
Jon Harrop
> http://www.informit.com/articles/article.asp?p=486104&rl=1
> <quote>
> High-level languages are not intrinsically slow! David Chisnall explains
> how programming in a low-level language can make a compiler's job harder,
> essentially wasting effort and slowing down your program's processing.
> </quote>
>
> New info for me:
> * Inlining saves a lot of CPU time.
Sometimes. Other times it makes things slower.
> With JIT compilation, you can actually
> inline calls to the standard libraries, and the linkage won't be preserved
> between program invocations, so the library can be updated without going
> out of sync with the library; something AOT compilers can't do.
AFAIK, no JIT-compiled languages perform as well as statically-compiled
ones. Java certainly tends to be slow compared to C, C++, SML, OCaml etc.
> * Arrays are a low level data abstraction, and are hard to optimize from a
> compiler's perspective.
Not really true. Arrays are overused in languages that provide no or few
alternatives (e.g. hash sets, maps, trees, queues, stacks, lists) such as
C. Overuse of arrays leads to asymptotically slower code which makes
programs written in languages like C much slower than smaller, simpler
equivalents in languages like OCaml.
> * A modern Pentium 4, for example, can have about 150 instructions
> in-flight at once. To write optimal assembly code for this machine, the
> developer must track a window of 150 instructions at any point to reduce
> dependencies. Such work is much easier for a machine than for a human, so
> gradually machines did it more and more.
I'd add that computer architecture and compiler optimisations have developed
so much recently that there is almost no advantage in having a compiler
with 20 years of optimisations behind it. Indeed, most of those
optimisations are now useless.
It is amazing how fast modern languages can be if they have clean
implementations. Look at OCaml, for example. Comparatively tiny compiler
and yet performance typically far exceeding that of Java.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Morten Alver
> It is amazing how fast modern languages can be if they have clean
> implementations. Look at OCaml, for example. Comparatively tiny compiler
> and yet performance typically far exceeding that of Java.
Interesting statement, considering that two days later you ask
this same group if anyone has benchmarked OCaml vs. Java.
--
Morten