[derefr]

> While BeamASM (JIT) is very exciting, the reality is that the Erlang runtime has only speed up by ~25% over the last decade

Yes... because perf hasn't really been a focus for Erlang until about 1.5 years ago. Various (usually academic) third parties have contributed big performance-enhancing patchsets (the earlier JIT; Dialyzer and then HiPE based on Dialyzer analysis; etc.) but these have then languished, with attempts to further development on them slowing to a crawl over time. The patchsets were just "too big to be digested properly"† by a team of core maintainers who 1. didn't write the code, and don't fully understand it, and 2. who aren't CS academics themselves.

Each of these indigestible patchsets was eventually dropped, throwing away any follow-on in-tree work done to it, and dropping perf back to where it was before said patchset was introduced.

The new work is in-tree, done ground-up by the core maintainers themselves, and so is actually showing linear improvements in speed. This not only includes runtime speed, but also the batteries-included addition of long-ignored performance-oriented features, like atomic counters and fast global readonly modules (and the runtime itself being gradually rewritten in terms of these!)

† This is exactly why, in the Linux kernel, big patchsets aren't accepted as-is, but rather are required to be broken down into small changes that 1. can add value on their own, and 2. can be molded to fit the design philosophy of the kernel on their own. This is why e.g. the "containers" patch from OpenVZ was never pulled in; but instead, each bit of it was gradually reworked into the cgroups + namespaces code that powers Linux containers today.

[alberth]

> perf hasn't really been a focus for Erlang until about 1.5 years ago.

The core maintainers have been working on JIT/perf for 10-years.

You can see Lukas own described 10-year journey documented below.

https://drive.google.com/file/d/1hHCs90kDX_wJ9AbLzGNu5bZKdIV...

[derefr]

I've had this conversation on HN three times now, and I'm misunderstood each time I say it. It's getting a bit frustrating.

I'm not saying that the Erlang maintainers haven't been trying to work on perf. I'm saying that their approach to working on perf has, until recently, been to focus on building on top of large blobs of relatively-opaque third-party code — either in-tree code, like HiPE; or library code, like LLVM. These approaches haven't been maintainable, and have eventually been dropped.

The difference in the last 1.5 years is that the perf enhancement this time is purely due to optimizations to the emulator and runtime — and improvements to the way the compiler works enabling better runtime insight into the code — with no big blobs of opaque code being relied upon. There's nothing extra to maintain; no big experimental perf-hack to enable with a feature flag. It's just the runtime itself being improved.

With previous attempts, the perf improvement was a sigmoid sawtooth: perf increased, levelled off, and then dropped back down. This time, the perf improvement is a linear ratchet function.

---

My other point, is that until fairly recently, most of Erlang's biggest users were "enterprise" customers with embedded use-cases, whose #1 concern was stability — they didn't care about perf-enhancing new language features, because they weren't about to rewrite their working+tested+certified code just to get better perf. They were only interested in "transparent" perf enhancements.

More recently, though, large non-"enterprise" corporate users of the Erlang runtime, like WhatsApp and Discord, have been migrating their work developing third-party perf-enhancing feature modules upstream as language features, because they are interested in rewriting code to increase perf — as long as that rewritten code is also just as maintainable (if not moreso.)

[alberth]

> I'm saying that their approach to working on perf has, until recently, been to focus on building on top of large blobs

Totally agree.

Off topic: I really love Erlang/Elixir - but I'm beginning to losing hope in being able to see a path where it can 3x improve performance. There has be a lot of people for a very long time been hoping this major improvement will come "soon". I'm unfortunately just not seeing it happening or a path to it ever happening. I hope I'm wrong.

[MrWiffles]

As an Elixir noob, I'm reading these comments about performance and coming to some conclusions that I'd like to ask ya'll to idiot-check me on.

First, let me establish that there are at least two ways of thinking about performance in the context of a server-side HTTP application:

1) Per-request speed ("from receiving the request to response, single-threaded, X ms") 2) Throughput-based metrics ("We can serve X requests per second with Y cores spread across Z nodes")

I think both ways of measurement have value, but in this context I'm operating under the assumption that we're focused on option 2. Correct me if I'm wrong.

Now, with that understanding in place, it sounds to me like Elixir/Erlang performs "pretty good" in terms of that overall throughput if you leverage the multithreading capabilities in building your apps and thread scheduling isn't terribly contentious (hopefully not a lot of other processes/threads competing for execution time on the same machine as your Elixir app), but measured on a raw per-operation speed metric it doesn't quite stack up to other non-compiled languages like PHP or maybe even Ruby (which would shock me but let's just poke that bear anyway, see what kinda growl we get...).

So if indeed my understanding is right, my next question is: "how much of a performance reduction would we realistically see with an Elixir app that's otherwise well built and doing the same thing?" Issues of misconfiguration, bad deployment architecture, etc. withstanding.

And if that question is indeed valid/not-batshit-crazy, my next would be: "does that degredation matter or scale in a multi-node/clustered deployment context?" In other words, if you have a say 50-node (be they VMs or containers) Elixir app, built well, properly configured and deployed, load balanced etc., is it going to have significantly/noticeably slower throughput than an equivalent PHP/Java/Ruby/$OTHERLANG app when compared as close to apples-to-apples as you can get that sort of thing?

(Maybe take Ruby out of the equation here with issues of GIL/threading being what they are over there. Haven't had the chance to work with recent Ruby though so if threading is a valid comparison nowadays, by all means keep it in mind!)

I'm just trying to get a sense for whether or not I'm barkin' up the wrong tree with my recent interest in Elixir. Am I wasting my time right now and maybe should wait a few years before really tearing into it, or is it effectively in a real-world, non-academic scenario, going to perform "close enough" in the real world in a multi-core, multi-node load balanced context?