[Haskell-cafe] In-place modification

[Hugh Perkins]

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070714/7ae8aa2f/attachment.htm