3 ms·

Recent benchmarks and related responses resulted in Akka out-performing Erlang (read the full post): https://plus.google.com/112820434312193778084/posts/HdKFx4V

Recent benchmarks and related responses resulted in Akka out-performing Erlang (read the full post): https://plus.google.com/112820434312193778084/posts/HdKFx4VQtJj https://plus.google.com/112820434312193778084/posts/HdKFx4VQ... Shared memory when running on the same machine is actually more efficient since there is no need to copy immutable objects. If the sophisticated low-latency GC options available on the JVM are not sufficient for you feel free to fire up more JVM instances on the same machine or on other machines.

waffle_ss 14y ago
I assume you mean the comment that links here, with Akka getting 2.1M messages/sec? http://uberblo.gs/2011/12/scala-akka-and-erlang-actor-benchmarks http://uberblo.gs/2011/12/scala-akka-and-erlang-actor-benchm... If you follow the comments there, someone improved the Erlang benchmark to 3M messages/sec, beating Akka once again: http://musings-of-an-erlang-priest.blogspot.dk/2012/07/i-only-trust-benchmarks-i-have-rigged.html http://musings-of-an-erlang-priest.blogspot.dk/2012/07/i-onl... > Shared memory when running on the same machine is actually more efficient since there is no need to copy immutable objects. 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). > If the sophisticated low-latency GC options available on the JVM are not sufficient for you feel free to fire up more JVM instances on the same machine or on other machines. 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.
- trailfox 14y ago
  > 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

I assume you mean the comment that links here, with Akka getting 2.1M messages/sec? http://uberblo.gs/2011/12/scala-akka-and-erlang-actor-benchmarks http://uberblo.gs/2011/12/scala-akka-and-erlang-actor-benchm... If you follow the comments there, someone improved the Erlang benchmark to 3M messages/sec, beating Akka once again: http://musings-of-an-erlang-priest.blogspot.dk/2012/07/i-only-trust-benchmarks-i-have-rigged.html http://musings-of-an-erlang-priest.blogspot.dk/2012/07/i-onl... > Shared memory when running on the same machine is actually more efficient since there is no need to copy immutable objects. 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). > If the sophisticated low-latency GC options available on the JVM are not sufficient for you feel free to fire up more JVM instances on the same machine or on other machines. 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.

trailfox 14y ago
> 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.