The Bagley Language Benchmarks

bench
Doug Bagley has done programmers a great service
by developing and displaying in very readable format a series of 25 benchmark tests of at least 40 languages. This should be taken like the TPC set of benchmarks – not absolutely unequivocal about performance; but clearly indicative of relative performances.

Programming language benchmarking is very difficult today, especially given the changing nature of computing with n-tier, network-latency type of applications. Nor do benchmarks capture a precise crossection of desktop computing activities (file io, many device response time dependencies, nature of the “typical” load, etc) even when network traffic and its delays/latencies are eliminated. But despite these provisos, the Bagleys do give a good indication of how well the various programming languages are geared to run the numbers, characters, bits and bytes.

Three Speed Tiers

What emerges from examining the Bagley Benchmarks is that programming languages are breaking out into 3 speed tiers for raw computing power:
1)compiled to native code languages are in the fastest tier.
The best and fastest appear to be: Intel C, Gcc C, Intel C++ but also GNAT Ada 95 and OCaml
2)byte code engines in a second tier averaging 7-12 times slower than the first tier.
The best of the second tier are in order: Java, Mono C#, Python among others
3)Interpreters in a third tier averaging averaging 100-200 times slower than the first tier.
the best of the third tier are in order: Ruby, JavaScript, PHP, Rexx among athers
Now again cautions are due as these tests are run on Linux only and on one machine. However, the results are indicative of where there might be difficulties in the performance of applications – or conversely where switching to a new language may get performance gains.

Other Guidelines

What makes the results even more helpful are measures on memory usage and lines of code required to implement the different programs. Again we are using these results only as guidelines or risk/opportunity indicators. But it is surely helpful to know that Java requires about 20 times the memory of C. Yes, this is the byte code engine overhead – but remember to factor that in. Fr Linux developers this source is just a gold mine of information. But in general, for x86 developers (and Intel +AMD know full well there a lot of those on the desktp and for servers) these are helpful results.

Congratulations are due to Doug for a tour de force display of data.

(c)JBSurveyer 2005