5 ms·

I would expect this kind of article to start with numbers showing that Erlang's GC has shorter GC pauses than, say, Java or Go and then explain why this is so.

by kjksf 11y ago

I would expect this kind of article to start with numbers showing that Erlang's GC has shorter GC pauses than, say, Java or Go and then explain why this is so. Instead it merely states that Erlang GC has better latency than other system and we're supposed to just believe it. It's fine as a description of how Erlang GC works but totally useless as an argument that Erlang has short GC pauses.

oomkiller 11y ago
Here is a semi-recent benchmark for Phoenix, which is written in Elixir (runs on the Erlang VM, BEAM). I think it will give you a decent idea of the differences: https://gist.github.com/omnibs/e5e72b31e6bd25caf39a https://gist.github.com/omnibs/e5e72b31e6bd25caf39a I would like to see this run with the latest versions of the various platforms, as a lot has changed since Phoenix 0.13, and I'm sure it has for the other platforms that were benchmarked as well. Initially, it seems like there is not a lot of difference between most of the platforms, but when you're working with variances of 1-2 ms on 180k rps is pretty substantial.
- deleted 11y ago
  [deleted]
- kenOfYugen 11y ago
  Would it be possible to update node.js to v4.0.0 and rerun the Express Cluster benchmark? node.js v0.12.x was slower than v.0.10.x, while v4.0.0 is supposed to be faster than both. Sorry for making this request if it's out of your field of interest, but couldn't resist asking :) EDIT: My mistake, I thought you were the author of the benchmark
stingraycharles 11y ago
I think there is a bit of information left out here (presumably because it is assumed to be understood by the reader), but it is not uncommon for erlang applications to have millions of different processes active at the same time. As such, since memory management is (mostly) isolated within a single process, you have a de-facto sharded garbage collector. This, as the article explains, is a core trait that helps with the soft realtime guarantees erlang brings.

by kjksf 11y ago

oomkiller 11y ago

Here is a semi-recent benchmark for Phoenix, which is written in Elixir (runs on the Erlang VM, BEAM). I think it will give you a decent idea of the differences: https://gist.github.com/omnibs/e5e72b31e6bd25caf39a https://gist.github.com/omnibs/e5e72b31e6bd25caf39a I would like to see this run with the latest versions of the various platforms, as a lot has changed since Phoenix 0.13, and I'm sure it has for the other platforms that were benchmarked as well. Initially, it seems like there is not a lot of difference between most of the platforms, but when you're working with variances of 1-2 ms on 180k rps is pretty substantial.

deleted 11y ago
[deleted]
kenOfYugen 11y ago
Would it be possible to update node.js to v4.0.0 and rerun the Express Cluster benchmark? node.js v0.12.x was slower than v.0.10.x, while v4.0.0 is supposed to be faster than both. Sorry for making this request if it's out of your field of interest, but couldn't resist asking :) EDIT: My mistake, I thought you were the author of the benchmark

stingraycharles 11y ago

I think there is a bit of information left out here (presumably because it is assumed to be understood by the reader), but it is not uncommon for erlang applications to have millions of different processes active at the same time. As such, since memory management is (mostly) isolated within a single process, you have a de-facto sharded garbage collector. This, as the article explains, is a core trait that helps with the soft realtime guarantees erlang brings.