--- Don Stewart <[EMAIL PROTECTED]> 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?) _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
