3 ms·

> I assume you mean the comment that links here You assume incorrectly. I'm referring to the version where Scala was 44% faster than Akka: https://plus.google.

> I assume you mean the comment that links here You assume incorrectly. I'm referring to the version where Scala was 44% faster than Akka: https://plus.google.com/112820434312193778084/posts/HdKFx4VQtJj https://plus.google.com/112820434312193778084/posts/HdKFx4VQ... In any event the application logic in Java will likely outperform erlang. See: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=hipe&lang2=java http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... where Java outperforms Erlang by 3-30x in most cases and uses significantly less memory in most cases. > Many Erlang processes fit onto an OS-level thread or process, so passing messages is very fast ("copying" shouldn't be equated with context switching OS threads). Many Akka actors fit into a single process and there are many actors per OS level thread, so this isn't really a useful point for comparison. > Akka is a library and can't make guarantees about how the JVM will perform garbage collection of actors while Erlang has it built into its VM. No amount of creating new JVM instances will change that. The JVM does the GC, not the library. Is 100 microseconds not short enough for your application? http://mechanical-sympathy.blogspot.com/2012/03/fun-with-my-channels-nirvana-and-azul.html http://mechanical-sympathy.blogspot.com/2012/03/fun-with-my-...

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 ago
  The 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.

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 ago
The 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.