Thu Mar 5 03:48:31 CET 2009
On Mar 4, 2009, at 8:35 PM, Tony Arcieri wrote:
> And as a more general question, how could Erlang improve its
> performance on problems like chameneos-redux?
> This is a benchmark where Erlang's poor performance sticks out like a
> sore thumb. The frontrunners (on the quad-core benchmark) are
> Haskell, C++, Scala, C, and Java. Erlang comes in dead last.
> A school of thought seems to exist that because Erlang fares poorly on
> these sorts of problems that you shouldn't even try to use Erlang to
> address them, and that's not a school of thought I particularly like.
It may be worth noting that the Haskell entrants have apparently also
concluded that concurrency is of limited help to them in this benchmark:
collect1 <- run 1 n [Blue ..]
collect2 <- run 2 n [Blue, Red, Yellow, Red, Yellow, Blue, Red,
Yellow, Red, Blue]
The 1 and 2 are constraining the two computations to run on specific
CPUs for their entire lifetimes. So, they don't experience the
overhead of message passing between CPUs which the erlang solution
does, although naively they appear to be quite similar solutions.
The C++ entry is only able to get close by very carefully tuning their
pthreads and the linux scheduler. On a different kernel version or a
different number of CPUs, it might have decidedly different
performance. On a different OS, the code won't even compile. Despite
all this, they still can't quite beat Haskell on wall time, and chew
up twice the CPU time doing it.
No one else using concurrency is getting particularly close to Haskell
on either wall or CPU time.
I've said before, since this extreme level of tweaking is permitted on
the shootout, the Erlang community should at least request that this
benchmark be run with a only a single scheduler thread. It would at
least stop being embarrassing then.
More information about the erlang-questions