Slashdot Mirror
The Great Computer Language Shootout
kato writes: "Doug Bagley has posted results from benchmarking of 29 different language implementations solving 25 different problems (he's written ~600 of the 725 programs so far). The languages include C/C++, Perl, Python, Eiffel, BASH, Tcl, and OCaml. The problems range in complexity from "Hello, World!" to the Sieve of Eratosthenes and Matrix Multiplication. The results can be sorted by speed, memory usage, or lines of code. You can also give one particular program more weight than another (if you are doing more client/server code than "Hello, World!") and find the faster/smallest/shortest language implementation. I can see many of my programs being written in OCaml from now on." Update: 07/04 12:42 PM by CT : The site is apparently now redirecting people back here. I guess technically thats an error message, just not a helpful one. Update: 07/05 8:40 PM by M : Please don't email. The link is broken. We know. The guy is running a server at home on a metered connection, and doesn't want any more traffic.
Personally I like C because I can shoot myself in the foot faster and with less effort with it.
... is my favorite language: Brainfuck.
Here
As pointed out by a previous poster, this author is a beginner in most of these languages. I had an interesting experience in a graduate level CS class here in Berkeley on optimizing a matrix-matrix multiply routine. (Interestingly enough, the class was on parallel computing -- the point of the exercise was to learn just HOW INCREDIBLY important the serial part of one's algorithm is, even when one has oodles of processors available).
The results are interesting for a number of reasons.
(1) The "naive" algorithm, even with optimization, performed at about 50 MFlops (the Suns we used had a theoretical peak of 333 MFlops).
(2) With excellent optimization, pulling out all the stops, and using all the tricks available (unrolling loops, deallocating pointers to local variables, etc.), teams of just two students working for a week could get EXCELLENT performances (ie, within 10-20% of theoretical peak), approaching those of Sun's built-in library, and exceeding those of some existing libraries (like PHiPAC).
(3) Different groups with different approaches got very widely disparate results -- some barely exceeding those of the naive algorithm.
In sum, how ones goes about coding an algorithm can make ENORMOUS differences in the performance of a code. This is particularly true with numerical algorithms in C and other languages with pointers, where some compilers have great trouble optimizing routines using pointers, since the values are not known at compilation time. Taking this into account, I wouldn't give this guy's results much credence at all.
However, with the help of a lot of experts in the various languages, it will be possible to get a much better appraisal of the relative performances of different languages. A close analogy exists with these benchmarks and the SPEC open standards evaluations for CPUs. The only fair way they found, to compare across all CPUs and compilers, was to allow a very strict non-optimal compilation, and no-holds barred compilation. The same is true here -- we need to get teams to go no-holds barred in the creation of the best possible codes for each language.
Bob
Science, like Nature, must also be tamed, with a view turned towards its preservation.
Hrm. Never even heard of Ocaml.
It's the Irish version of Perl. (ouch.)
--
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
...it sounds like the PL/I of the new millenium! (smirk)
"Rub her feet." -- L.L.
Because it has all the great functional features that can make Lisp programmers happy.
Because it has a wonderful OO model which can make all OO programmers happy.
Because it has super fast compilers that can make C and C++ programmers happy.
Because it is great for imperative programming and for functional programming.
Because it is great for procedural programming and for OO programming.
Because it is as multiplatform and portable as Java.
Because it is designed to please everyone without compromising on anything, and, put more simply, because it can reconciliate the C, Java, Lisp and C++ community.
Because it can even be used indifferently as a scripting or a system language.
Because it is great for teaching AND for the real world.
Because its compilers are libre software and its design and developement are made in a very open fashion.
I took the liberty of benchmarking 25 spoken languages by comparing their methods for expressing the phrase "Wuzzzzzzaaaaaah" from the budweiser commercial. Some of these may not be optimized as I am a bit of a newbie at some of these languages. Here is an excerpt:
American English: "Wuzzzzzzzzzzzzzahhh!"
British English: "What is up?"
Japanese: "Konichiwaaaaaaaaaaaaa!"
Spanish: "Holaaaaaaaaaaaaa!"
Welsh: "Wyffffffwyfffffffffffff!"
The binary language of water vaporators:
"0100000000000000000000000000000000"
Australian English: "I'm not saying any such thing. Give me a Fosters'."
Irish English: "I'm not saying any such thing. Give me another pint of Guiness."
Javanese: " I'm not saying any such thing. Give me another pint of Guiness. No, I'm not the Irish guy in Javanese traditional dress, I'm from Java!"
microsoftword.mp3 - it doesn't care that they're not words...
In other words, if engineers spent more time studying best practices and efficient algorithm design, that might well improve performance more than spending time in religious wars about the merits of pet languages.
In my experience, basic performance tuning can easily create an order of magnitude improvement regardless of the language. And in my experience, most engineers don't know how to do basic performance tuning. That's got to be more important than language selection in the average case.
Tim