4 ms·

Akka is also a viable Erlang alternative.

by trailfox 14y ago

davidw 14y ago
Good point; I wonder what kind of memory usage you could squeeze that in to.
- trailfox 14y ago
  It should run comfortably on any modern server, might be tricky if you have severe memory constraints though.
- JulianMorrison 14y ago
  https://code.google.com/p/jetlang/ https://code.google.com/p/jetlang/ is a rather Go-like model, with lightweight processes (optionally backed by a thread pool) and typed channels. Much less functionality than Akka but if you want low memory overhead, it's hard to beat.
waffle_ss 14y ago
Looks like a nice library but I don't think it's a serious contender to replace Erlang because the JVM just isn't made for the level of concurrency that Erlang's VM is. Off the top of my head as an Erlang newbie: * You're still using Java threads, so the potential to access [shared memory][1] is there (i.e. "shared nothing" can't be guaranteed). * You're still subject to global GC pauses, whereas the Erlang VM has per-process GC. [1]: http://doc.akka.io/docs/akka/snapshot/general/jmm.html http://doc.akka.io/docs/akka/snapshot/general/jmm.html
- trailfox 14y ago
  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-...
- abraininavat 14y ago
  Both of your points apply just as well to Go as they do to JVM/Akka, making JVM/Akka just as serious a contender as Go by those standards.

Akka is also a viable Erlang alternative.

davidw 14y ago

Good point; I wonder what kind of memory usage you could squeeze that in to.

trailfox 14y ago
It should run comfortably on any modern server, might be tricky if you have severe memory constraints though.
JulianMorrison 14y ago
https://code.google.com/p/jetlang/ https://code.google.com/p/jetlang/ is a rather Go-like model, with lightweight processes (optionally backed by a thread pool) and typed channels. Much less functionality than Akka but if you want low memory overhead, it's hard to beat.

waffle_ss 14y ago

Looks like a nice library but I don't think it's a serious contender to replace Erlang because the JVM just isn't made for the level of concurrency that Erlang's VM is. Off the top of my head as an Erlang newbie: * You're still using Java threads, so the potential to access [shared memory][1] is there (i.e. "shared nothing" can't be guaranteed). * You're still subject to global GC pauses, whereas the Erlang VM has per-process GC. [1]: http://doc.akka.io/docs/akka/snapshot/general/jmm.html http://doc.akka.io/docs/akka/snapshot/general/jmm.html

trailfox 14y ago
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-...
abraininavat 14y ago
Both of your points apply just as well to Go as they do to JVM/Akka, making JVM/Akka just as serious a contender as Go by those standards.