5 ms·

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

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 5y 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 5y 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 5y 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 5y ago
  Also the languages are almost extreme opposites in terms of how they execute as they make entirely different tradeoffs.
- ReactiveJelly 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago
    > but it seems pretty dormant. It’s been getting an RC for the newest version like monthly?
    - toast0 5y ago
derefr 5y 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 5y 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 5y 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 5y ago
> PHP have <seen> a near 200% improvement perhaps because PHP's implementation was grotesquely wasteful?

jlouis 5y 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 5y 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 5y 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 5y ago
Also the languages are almost extreme opposites in terms of how they execute as they make entirely different tradeoffs.
ReactiveJelly 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago
  > but it seems pretty dormant. It’s been getting an RC for the newest version like monthly?
  - toast0 5y ago

derefr 5y 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 5y 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 5y 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 5y ago

> PHP have <seen> a near 200% improvement perhaps because PHP's implementation was grotesquely wasteful?