[eru]

The quality of the individual programs plays a large role. E.g. GHC (Haskell) has made huge strides in the past thanks to better libraries and implementations for the benchmark, despite nearly the same compiler.

On a side note, a lot of the benchmarks had to be reformulated after lazy languages got fast. As far as I know, a benchmark at this side prescribes which algorithm you should use. Haskell (and e.g. Clean) just ignored a lot of the baggage because it was not used any further.

[igouy]

> despite nearly the same compiler

As you don't say how far "in the past" maybe that's nonsense or maybe that's true.

> a lot of the benchmarks had to be reformulated after lazy languages got fast

That's nonsense.

Programs for one benchmark - binary-trees - had to be rewritten because "this is an adaptation of a benchmark for testing GC so we are interested in the whole tree being allocated before any nodes are GC'd" and with lazy evaluation GC gobbles up nodes before the whole tree's allocated -

http://shootout.alioth.debian.org/u32q/benchmark.php?test=bi...

[eru]

Thanks for clearing that up. I wrote from my unreliable memory.

[jcl]

I love the shootout, by the way. Thanks for maintaining it.

[igouy]

Thanks to those who contribute programs.

Every week there are new programs, often from people who haven't contributed a program before.

One of these days someone will find a way to make effective use of all the cores for n-body, maybe.