[Haskell-cafe] Haskell Speed Myth

[Isaac Gouy]

--- Don Stewart <dons at galois.com> 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?)