Re: The Speed, Size, and Dependability of Programming Languages

MarkWills <markrobertwills@xxxxxxxxxxx> writes:
On Jun 1, 11:24=A0pm, John Passaniti <john.passan...@xxxxxxxxx> wrote:
I found this blog entry really interesting:

http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html
....
Interesting indeed. Look at occam. Wow!

Very long programs. Wow?

Also, there seem to be only a few occam benchmarks. BTW, that shows a
flaw in the way the data was processed and presented: Remove the
longest and slowest programs from a particular language, and it will
move in the "ideal" direction. I guess that's also the reason why
bigForth is below Gforth (it's expected that it is to the right).

GForth seems to be OK, coming
somewhere around the middle of the dataset. Interesting that GCC in
general beats it on all metrics. Comparing GForth/bigForth and GCC are
we observing a limitation of the Forth language, something inherent in
the mechanics of the language, or is it that GForth is itself written
in C? Or am I being too simplistic. I wonder what threading model of
Gforth they used for the tests?

They used to use the Debian or Gentoo packages of Gforth, and they may
be using gforth (instead of gforth-fast). The Debian package of
Gforth-0.6.2 is a factor of 2 or more slower on the kinds of machines
they used than a version configured and built for speed with the right
version of gcc (the Gentoo version they used is probably little
better). As for threading model, it's hybrid direct/indirect threaded
code with static superinstructions in Gforth-0.6.2, and a well-built
version also has dynamic superinstructions. And if you want to know
what this technobabble means, I have written some papers about that.

Concerning the comparison with gcc, as long as both programs use the
same algorithm and the implementation of the algorithm is fine-tuned
to a similar degree, I would expect gcc to beat both BigForth and
Gforth, simply because gcc optimizes more.

What did cause my eyebrows to be temporarily un-encumbered by gravity
was the fact that Java is definitely to the left of both bigForth and
GForth. Shock horror! Can Java actually be faster than our beloved
Forth? Java, it seems, has come a long way!

Java compilers have a lot of effort put into them. And for these
small benchmarks the Hotspot optimizer is effective even for the
relatively short run-times of these benchmarks.

The reason why Java programs are often slow is not because the
language is slow or the compiler is slow, but because many programmers
don't write efficient Java programs. I call that idiomatic
inefficiency. Obviously the programmers who wrote the benchmark
programs wanted to write fast programs, so they avoided the idiomatic
inefficiency.

Moreover, the way the system is set up and many of these programs are
written means that a huge number of classes are loaded and a huge
number of methods are called. And in Hotspot the code is interpreted
at first, then (if it is executed often enough) it is compiled, and
only then it is fast. For these benchmarks the code that is executed
a lot is relatively small, so not much time is spent in interpretation
or compilation of that code; and apparently all the other startup
overhead is not enough to make Java look bad in benchmarks other than
startup.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
.

Relevant Pages

  • Re: A 21st Century Apple II?
    ... responded with specific benchmarks using the Java 6 client because I ... Intel compiler, then look at the average performance across all ... that appears to be supported by the benchmarks at the language shootout web site if you look at them in aggregate. ...
    (comp.sys.apple2)
  • Re: A 21st Century Apple II?
    ... For all 17 benchmarks, Java is never faster than C++, and up to 10x ... Java wins comprehensively are the only two that do either memory de- ... Language selection will always be a religious issue. ...
    (comp.sys.apple2)
  • Re: FORTH Trouble--Please Show Me
    ... Over the application benchmarks on the MPE website, ... the gforth-fast time is 3.90 times the VFX time on an i7. ... Everybody uses the benchmarks where their compiler shines most. ... sieve you use takes 458ms here on Gforth, ...
    (comp.lang.forth)
  • Re: Question from a newcomer - regarding words
    ... not so great for Gforth. ... but it does not normally use indirect-threaded code nowadays. ... rank, but it helps in the memory consumption rank. ... On individual benchmarks. ...
    (comp.lang.forth)
  • Re: java performance on machines
    ... Primarily the goal is to compare cpu/memory power on different ... The idea is to write a series of tests in java, both integer and float ... If synthetic benchmarks are ok then you could look at the SPEC benchmarks ...
    (comp.lang.java.help)