--- Don Stewart wrote: -snip-

So still consolidating the system.

Pretty much.

Do I understand though, that if we submit, say, a quad-core version of binary-trees, for example, using `par` and -N4, it'll go live on the benchmark page?

That's an open question - should it? How should the benchmarks game approach multicore?

--- Don Stewart wrote: -snip

...

How should the benchmarks game approach multicore?

Well, there's a famous paper,

Algorithm + Strategy = Parallelism

I'd imagine we use the benchmark game's algorithms, but let submitters determine the strategy. Then the results would show

a) how well you utilize the cores, and b) overall wall clock results.

otoh I see the attraction of showing parallelised versions alongside existing programs; otoh that adds yet another layer of confusion about why the measurements differ (and another level of quarreling about whether even vaguely the same thing is being measured); otoh some existing programs already use more cores when they can ... The Scala threadring program shows 524s cpu but 157s elapsed: http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all

I'm keen to get going on this, if only because I think we can turn out parallelised versions of many of the existing programs, fairly cheaply.

I'm always delighted that you're keen to get going on things like this! The benchmarks game always seems to demand somewhat unnatural acts and here's another - is there an effective way to /prevent/ ghc using multiple cores when multiple cores are available? Can we force ghc to only use one core on the quadcore machine? (Moreover can we do the same trick for other languages?)

igouy2:

otoh I see the attraction of showing parallelised versions alongside existing programs; otoh that adds yet another layer of confusion about why the measurements differ (and another level of quarreling about whether even vaguely the same thing is being measured); otoh some existing programs already use more cores when they can ...

The Scala threadring program shows 524s cpu but 157s elapsed:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all

Very cool!

...

I'm keen to get going on this, if only because I think we can turn out parallelised versions of many of the existing programs, fairly cheaply.

I'm always delighted that you're keen to get going on things like this!

The benchmarks game always seems to demand somewhat unnatural acts and here's another - is there an effective way to /prevent/ ghc using multiple cores when multiple cores are available? Can we force ghc to only use one core on the quadcore machine? (Moreover can we do the same trick for other languages?)

Certainly, for the quad core, to get all 4 cores in play: * compile with -threaded * run with +RTS -N4 to force single core, we'll: * compile normally * run normally -- Don