Computer Language Shootout - concurrency
Tue Dec 6 11:20:49 CET 2005
Peter-Henry Mander writes:
> persuade the benchmark designers to add better and wider-ranging
> concurrency tests, since concurrency is becomming a hot topic these
> days with multicore and cell processors.
Is this a finger-burning recipe? Or, can I make Erlang look bad?
Example: a one-dimensional parallel sort on a 4-CPU shared-memory
machine. You break the data into four pieces and have each core sort
one If you did that in C, you'd expect a speedup of about* 4x
over a single CPU, for many useful datasets. If you did it in Erlang,
you'll get a huge slowdown. The overhead of sending the data around
between 4 nodes+ will overwhelm the concurrency win.
Maybe concurrency benchmarks are pointless. The choice of concurrency
granularity has more effect on the outcome than anything else.
Footnotes for the pedantic:
@ I am aware that there are other parallel sorting algorithms.
* This test can be subverted by choosing the data/hardware such
that it's limited by memory bandwidth. And in other ways.
+ A future, multithreaded VM might have better characteristics. Then
again, the improvement might still not be enough.
More information about the erlang-questions