> So no, using the form of my argument, it is NOT possible to prove
anything about Haskell -vs- C. It is ONLY possible to make claims
about Haskell *libraries* -vs- C *libraries*.
You can claim anything you like, but if you want people to believe it you'd be best providing the code used so that others can reproduce the tests, comment, optimize ;-)
I've done some simple benchmarks between C#/Java/C++ before. Here are two, one for a prime number algorithm, one for OpenGl, which is more of a "real world" situation, and entirely relevant to the original thread, which was talking about performance for games programming.
I havent run the same benchmarks in Haskell, because I'm not experienced enough to be able to write an optimized Haskell solution to either problem, but I'm sure I've come to the right place to find someone who can do this ;-)
Algorithms
========
For algorithms, the results are so close that simple compiler switch changes can make the difference between C++ or Java or C# being the fastest.
Here's a prime-number benchmark between C++ and C# (along with code):
http://spring.clan-sy.com/phpbb/viewtopic.php?t=7634&postdays=0&postorder=asc&start=60 post
Thu Nov 02, 2006 3:18 am
"
C++ version:
H:\dev\test\CSharpAI>H:\dev\test\testperf\prime.exe
number of primes: 664579
elapsed time: 2.265
C# version:
H:\dev\test\CSharpAI>H:\dev\test\testperf\primecs.exe
number of primes: 664579
elapsed time: 2.03125
Admittedly, optimizations are turned off by default in cl, and turned
on by default in C#. Nevertheless, these execution times are clearly
not miles apart."
OpenGl
======
Here's an OpenGl benchmark between C# vertex3f and C# drawArrays, and between C# and Java.
http://spring.clan-sy.com/phpbb/viewtopic.php?t=7634&postdays=0&postorder=asc&start=100
OpenGl C#: post of Sun Dec 03, 2006 5:54 am
OpenGl Java: post of Mon Dec 18, 2006 12:35 pm
I used a simple OpenGl application to benchmark Java and C#, because my target was to write an OpenGl application. You have to benchmark the things that you will be doing with your final application ;-)
OpenGl is very stressful for anything other than C/C++, because it involves a lot of calls across the C / <other-language> interface, along with associated marshalling costs and so on.
By comparing the time to run with using a brute-force Vertex3f call per vertex, with the time to call DrawArrays, after pushing everything to a vertex array, you can get a measure of the inter-language boundary overhead involved. (DrawArrays runs either in the graphics card, or in the graphics card driver, or both, but either way it's happening on the native side of the native/<other-language> boundary)
I was going to run the same benchmark on Haskell, but I gave up on seeing Haskell opengl doesnt support alpha-blending yet, so I'm guessing Haskell opengl has not been used very much just yet ;-)
If someone can provide an optimized version of the prime number algorithm in Haskell, I'll run it in both Haskell and C# and print the results. The algorithm is a simple sieve of Eratosthenes (I think). This is basically the kind of algorithm Haskell is built for ;-) so if it doesn't win this it's go-home time ;-)
Well, until automatic threading arrives of course.