5 ms·

The performance work in Erlang at the moment is really exciting. It's easy to get sniffy about it and say the JVM/CLR/whatever has has JITing for years. True.

The performance work in Erlang at the moment is really exciting. It's easy to get sniffy about it and say the JVM/CLR/whatever has has JITing for years. True. But then performance has never been the Erlang standout: that would be concurrency and robustness. The JIT is bringing BEAM languages up the rankings on performance. It may have a way to go to get to JVM level, and might not ever get there. But it's on a really encouraging trajectory. And none of that compromises the concurrency and robustness story, where it still stands at the forefront of production-quality capability with a single, well-designed approach that's well-implemented and impressively scalable. The care that has gone into Erlang's evolution (including the BEAM VM) is nicely illustrated by this para in the blog: > The embedded type information is versioned so that we can continue to improve the type-based optimizations in every OTP release. The loader will ignore versions it does not recognize so that the module can still be loaded without the type-based optimizations. I'm not claiming that's unique among VMs (don't know, probably not) but it does nicely illustrate diligence on the part of the core team. With Elixir adding some sparkle as an alternative BEAM language, it's a great time to be part of the Erlang community. Chapeau to the core team and community.

tiffanyh 4y ago
I don't want this to come across as snarky or unappreciative but note that JIT work on Erlang has been under active develop since at least 2014 (8 years) [0] if not earlier. The current JIT provides about 25% improvement while other languages like PHP have sen a near 200% improvement during that same timeframe. I also realize that Erlang is extremely difficult to increase performance of due to the very nature of it vs other languages. [0] https://llvm.org/devmtg/2014-04/PDFs/Talks/drejhammar.pdf https://llvm.org/devmtg/2014-04/PDFs/Talks/drejhammar.pdf
- jlouis 4y ago
  PHP is the language which would implement a loop by pushing a byte offset to a stack and seek in the file at the end of the loop. Massive improvement if you had a disk cache. It's all relative to where you come from. The byte code interpreter of BEAM is very close to a poor man's JIT. It has some op-fusion, and uses threaded code. So gaining efficiency will require lot of work.
  - nickjj 4y ago
    Is the BEAM's byte code interpreter comparable to something like opcache with PHP? [0]: https://www.php.net/manual/en/intro.opcache.php https://www.php.net/manual/en/intro.opcache.php
    - jlouis 4y ago
      BEAM is precompiled bytecode. The loader will peephole optimize the byte code replacing some instruction sequences with optimized variants. Bytecode resides in memory already, and there is no disk seeking.
  - dgb23 4y ago
    Also the languages are almost extreme opposites in terms of how they execute as they make entirely different tradeoffs.
  - ReactiveJelly 4y ago
    > PHP is the language which would implement a loop by pushing a byte offset to a stack and seek in the file at the end of the loop. I didn't quite understand this. Is it some famous PHP implementation thing?
    - jlouis 4y ago
      It's from one of the first implementations of the language. If you want to move fast, and you have no ambition about execution speed, this is a solution to the problem of implementing loops. PHP worked by parsing code directly from the file for every executed statement. So you ran the full lex->parse->interpret path for each statement. A loop need to jump back, which can be tracked by the file offset position, so you can redo the lex->parse->interpret step for the loops statements again. Modern PHP will not do this, because it's highly inefficient. I'm not even sure it survived into the 2000's.
- kaba0 4y ago
  Adding to that, wouldn’t adding Erlang’s unique features to the JVM be easier than the other way around? Especially with GraalVM’s unique approach that manages to elevate Ruby’s performance far higher than any other runtime?
  - asabil 4y ago
    You could, and in fact there has been Erlang implementations on top of the JVM[1][2], however you will never be able to get the same runtime characteristics of Erlang running on BEAM due to the fundamental differences in memory management: BEAM is first and foremost designed for reliability, predictability and soft real-time behaviour. [1] https://github.com/trifork/erjang/ https://github.com/trifork/erjang/ [2] https://github.com/jerlang/jerlang https://github.com/jerlang/jerlang
    - h0l0cube 4y ago
      That's correct. Java's threading and memory model is very different. You could emulate that model on top of the JVM, but that layer of abstraction would be an unacceptable performance penalty.
  - toast0 4y ago
    Erjang exists, but it seems pretty dormant. JVM and BEAM have pretty different philosophies, so while you could probably add messaging and distribution to JVM, I don't think it would be the same. I think it would be hard to get one thread-like thing per connection and millions of connections per OS process to work on the JVM, unless you can get OS threads to scale that high (which seems unlikely?).
    - the_only_law 4y ago
      > but it seems pretty dormant. It’s been getting an RC for the newest version like monthly?
      - toast0 4y ago
- derefr 4y ago
  > but note that JIT work on Erlang has been under active develop since at least 2014 Kind of, but that work (BEAM JIT, HiPE, etc.) was done by third-party academic researchers and then contributed to Erlang, where it languished, because none of the core developers were academic researchers with the knowledge to improve or even really change what had been contributed. HiPE was disabled in Erlang 22 simply because some new instructions were added and nobody knew how to extend HiPE with support for them. You might call this previous work "false starts" at optimization. The work going on since Erlang 24, however, is being done in-tree by the core maintainers themselves. It will stick around, and be gradually improved upon. Alongside this work, comes a number of recent features in the last few Erlang releases, all with the specific aim of supporting performance-oriented code — e.g. atomic counters, persistent_term, ETS high-read-concurrency improvements, etc. Basically, the Erlang devs have seemingly shifted from their previous "enterprise embedded use-case enablement" posture, more toward a "high-performance OLTP use-case enablement" posture.
  - tiffanyh 4y ago
    > Kind of, but that work (BEAM JIT, HiPE, etc.) was done by third-party academic researchers and then contributed to Erlang Is that correct? Lukas Larsson is a core developer and he's been working on JIT since 2012. (While yes, I agree academics have also worked on it - the core team has as well for equally amount of time) https://www.erlang-factory.com/conference/SFBay2012/speakers/LukasLarsson https://www.erlang-factory.com/conference/SFBay2012/speakers...
    - derefr 4y ago
      My understanding is that the integration work for these huge academic patchsets, took up the lion's share of any time the maintainers booked as "working on JIT." If not, these patchsets at least got in the way of useful progress in JIT work, redirecting "work on JIT" into themselves; where progress gradually slowed due to the "big ball of mud" that each of these patchsets were; and then all such progress was lost when the patchsets were given up on altogether.
- jjtheblunt 4y ago
  > PHP have <seen> a near 200% improvement perhaps because PHP's implementation was grotesquely wasteful?

tiffanyh 4y ago

I don't want this to come across as snarky or unappreciative but note that JIT work on Erlang has been under active develop since at least 2014 (8 years) [0] if not earlier. The current JIT provides about 25% improvement while other languages like PHP have sen a near 200% improvement during that same timeframe. I also realize that Erlang is extremely difficult to increase performance of due to the very nature of it vs other languages. [0] https://llvm.org/devmtg/2014-04/PDFs/Talks/drejhammar.pdf https://llvm.org/devmtg/2014-04/PDFs/Talks/drejhammar.pdf

jlouis 4y ago
PHP is the language which would implement a loop by pushing a byte offset to a stack and seek in the file at the end of the loop. Massive improvement if you had a disk cache. It's all relative to where you come from. The byte code interpreter of BEAM is very close to a poor man's JIT. It has some op-fusion, and uses threaded code. So gaining efficiency will require lot of work.
- nickjj 4y ago
  Is the BEAM's byte code interpreter comparable to something like opcache with PHP? [0]: https://www.php.net/manual/en/intro.opcache.php https://www.php.net/manual/en/intro.opcache.php
  - jlouis 4y ago
    BEAM is precompiled bytecode. The loader will peephole optimize the byte code replacing some instruction sequences with optimized variants. Bytecode resides in memory already, and there is no disk seeking.
- dgb23 4y ago
  Also the languages are almost extreme opposites in terms of how they execute as they make entirely different tradeoffs.
- ReactiveJelly 4y ago
  > PHP is the language which would implement a loop by pushing a byte offset to a stack and seek in the file at the end of the loop. I didn't quite understand this. Is it some famous PHP implementation thing?
  - jlouis 4y ago
    It's from one of the first implementations of the language. If you want to move fast, and you have no ambition about execution speed, this is a solution to the problem of implementing loops. PHP worked by parsing code directly from the file for every executed statement. So you ran the full lex->parse->interpret path for each statement. A loop need to jump back, which can be tracked by the file offset position, so you can redo the lex->parse->interpret step for the loops statements again. Modern PHP will not do this, because it's highly inefficient. I'm not even sure it survived into the 2000's.
kaba0 4y ago
Adding to that, wouldn’t adding Erlang’s unique features to the JVM be easier than the other way around? Especially with GraalVM’s unique approach that manages to elevate Ruby’s performance far higher than any other runtime?
- asabil 4y ago
  You could, and in fact there has been Erlang implementations on top of the JVM[1][2], however you will never be able to get the same runtime characteristics of Erlang running on BEAM due to the fundamental differences in memory management: BEAM is first and foremost designed for reliability, predictability and soft real-time behaviour. [1] https://github.com/trifork/erjang/ https://github.com/trifork/erjang/ [2] https://github.com/jerlang/jerlang https://github.com/jerlang/jerlang
  - h0l0cube 4y ago
    That's correct. Java's threading and memory model is very different. You could emulate that model on top of the JVM, but that layer of abstraction would be an unacceptable performance penalty.
- toast0 4y ago
  Erjang exists, but it seems pretty dormant. JVM and BEAM have pretty different philosophies, so while you could probably add messaging and distribution to JVM, I don't think it would be the same. I think it would be hard to get one thread-like thing per connection and millions of connections per OS process to work on the JVM, unless you can get OS threads to scale that high (which seems unlikely?).
  - the_only_law 4y ago
    > but it seems pretty dormant. It’s been getting an RC for the newest version like monthly?
    - toast0 4y ago
derefr 4y ago
> but note that JIT work on Erlang has been under active develop since at least 2014 Kind of, but that work (BEAM JIT, HiPE, etc.) was done by third-party academic researchers and then contributed to Erlang, where it languished, because none of the core developers were academic researchers with the knowledge to improve or even really change what had been contributed. HiPE was disabled in Erlang 22 simply because some new instructions were added and nobody knew how to extend HiPE with support for them. You might call this previous work "false starts" at optimization. The work going on since Erlang 24, however, is being done in-tree by the core maintainers themselves. It will stick around, and be gradually improved upon. Alongside this work, comes a number of recent features in the last few Erlang releases, all with the specific aim of supporting performance-oriented code — e.g. atomic counters, persistent_term, ETS high-read-concurrency improvements, etc. Basically, the Erlang devs have seemingly shifted from their previous "enterprise embedded use-case enablement" posture, more toward a "high-performance OLTP use-case enablement" posture.
- tiffanyh 4y ago
  > Kind of, but that work (BEAM JIT, HiPE, etc.) was done by third-party academic researchers and then contributed to Erlang Is that correct? Lukas Larsson is a core developer and he's been working on JIT since 2012. (While yes, I agree academics have also worked on it - the core team has as well for equally amount of time) https://www.erlang-factory.com/conference/SFBay2012/speakers/LukasLarsson https://www.erlang-factory.com/conference/SFBay2012/speakers...
  - derefr 4y ago
    My understanding is that the integration work for these huge academic patchsets, took up the lion's share of any time the maintainers booked as "working on JIT." If not, these patchsets at least got in the way of useful progress in JIT work, redirecting "work on JIT" into themselves; where progress gradually slowed due to the "big ball of mud" that each of these patchsets were; and then all such progress was lost when the patchsets were given up on altogether.
jjtheblunt 4y ago
> PHP have <seen> a near 200% improvement perhaps because PHP's implementation was grotesquely wasteful?