Shared publicly  - 
Scala Erlang Message Passing Benchmark

According to the message passing benchmark posted at erlang is about 6x scala in a message passing benchmark.

1. However converting from a loop to a recursive react shaved almost 40% off the scala time. (that would make erlang about 3.5x faster)

2. Replacing scala actors with akka actors makes Erlang only 8% faster than scala akka. (4.647 seconds for erlang vs. 4.687 seconds for scala on my machine).

3. Converting both to non-parallel computations (ie. remove .par from scala client and replacing plists with lists in erlang code) results in scala (1.874 seconds) being faster than erlang (2.705 seconds) by 44%

Thus presumably the fork join mechanism in scala/akka is still a lot slower than erlang, even as the message passing apparently is faster.

The final akka code for the parallel version (sorry appending a png due to formatting constraints) is below.
Harshad RJ's profile photoDhananjay Nene's profile photoDustin Whitney's profile photoSundar Srinivasan's profile photo
Good analysis. But when you say: "even as the message passing apparently is faster", is it a generic statement or something you measured?
There are many considerations here. eg. whether the erlang server is OTP or a raw actor. If it is a raw actor it will still outperform scala / akka. But given that the equivalent of akka is OTP, under non parallel scenarios akka is faster than erlang by 44%. So to answer your question, yes that was measured.

Would I read too much into it - not yet. Remember erlang always copies data (and with OTP it will copy at least a couple of tuples even if no actual user data is passed in the message). I think akka actors would share the same reference across both the actors. I would still want to rerun this benchmark by making the client and server separate processes (or separate nodes in case of erlang). Message passing performance over the network is as important as intra process message passing performance and that still remains to be seen.
Good explanation. Thanks. If you rerun benchmarks under other circumstances, please post the results. It's interesting.
Some interesting results coming up in multi node performance. Will post later tonight / tomorrow with details.
While I am not getting a chance to detail out further due to constraints of time, here's a very brief summary of additional findings on a quad core machine.

a. Erlang thruput is about 10 times more than Scala akka thruput when actors need to communicate across OS processes (ie. across erlang nodes or scala processes). There was a marginal positive difference when the serialisation mechanism in scala was changed from java serialisation to protobuf. In this case the message size was extremely small. It remains to be seen whether the difference is much more if the message sizes are substantial

b. Erlang thruput is only 3 (instead of 10) times scala akka when the scala code is run in a non parallel mode (ie. the messages are sent only sequentially). There's clearly some things that deserve investigation here .. things beyond my immediate ability to delve into. (I'm sure I'll get back to it some time soon).

c. Someone suggested using Java 7 due to its improved fork-join mechanism. That again remains an unexplored path.
Interesting results. Why would fork-join be at issue here? Is Akka using fork-join under the hood? Also, in my own testing fork-join only really begins to pay-off if the work performed per task is much greater than the F-J scheduling overhead.
Any updates with Java 7 (using the parallel collections)?
Add a comment...