[erlang-questions] STM

[Kevin Scaldeferri]

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?
>
> http://shootout.alioth.debian.org/u32q/benchmark.php?test=chameneosredux&lang=hipe&id=1
>
> 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.

-k