4 ms·
Your 44% link is after crippling the benchmark by de-parallelizing it on top of using a poorly written Erlang implementation. I suggest you read the actual blo
by waffle_ss 14y ago
Your 44% link is after crippling the benchmark by de-parallelizing it on top of using a poorly written Erlang implementation. I suggest you read the actual blog post that your Google+ post links to, including its comment section and the links posted therein (which is how I arrived at my links): http://www.krazykoding.com/2011/07/scala-actor-v-erlang-genserver.html http://www.krazykoding.com/2011/07/scala-actor-v-erlang-gens...
> Is 100 microseconds not short enough for your application?
GC time is not a useful benchmark by itself. The important thing with the JVM is that you can't predictably reason about when the global GC will happen (global GC pause). Your JVM actors aren't shielded from these global GC events so building a soft real-time system is less practical under the JVM than the Erlang VM IMHO.
- trailfox 14y agoThe benchmark doesn't "cripple" by de-parallelizing. Execution is already in parallel, it just uses regular collections as the concurrent ones weren't worth the performance overhead and in the end Akka ran 44% faster than Erlang. In the comments you refer to having 50% Erlang is roughly the same as 44%, so I don't thing there is much performance difference even though Java/Scala is faster than Erlang in general. Regarding soft realtime requirements Erlang may be a better choice, but I doubt there are too many use cases where it will make much difference.