5 ms·

Type-Based Optimizations in the JIT

137 points by seanclayton 4y ago

alberth 4y ago
Did WhatsApp/FB ever release their static type tool? All the FB blog posts from 2020 I find are broken links now.
- DylanSp 4y ago
  I'm also curious about this, I haven't heard anything in a while.
  - di4na 4y ago
    Maybe but they don't use it. Internal politics changed the track they used to something more sustainable. Kinda.
- ramchip 4y ago
  Yes, kinda: https://github.com/WhatsApp/erlt https://github.com/WhatsApp/erlt
spinningslate 4y ago
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
moelf 4y ago
every other week there's a post about JIT, LLVM, etc. (either like this or more commonly in Python where people show it improving 5x or whatever) whenever I see it, it makes me feel like Julia-lang really did a good job picking the approach and technology all the way back in 2010
- rad_gruchalski 4y ago
  First Erlang version was released in 1986, LLVM 2003.
  - chrisseaton 4y ago
    I don't think that's quite what they mean - Julia was specifically designed to be compiled. LLVM is a tech it uses, but it could use any compiler backend. It's the design that's amenable to compilation that's the important bit. https://dl.acm.org/doi/pdf/10.1145/3276490 https://dl.acm.org/doi/pdf/10.1145/3276490
    - deleted 4y ago
      [deleted]
    - ChrisRackauckas 4y ago
      Or more directly, the property of type groundedness + multiple dispatch allows for devirtualization of dispatches to get static-like performance in a dynamic language. That was the main design principle, which was a conjecture from Jeff's thesis later proven in a type-theoretic way by Jan Vitek's group. https://arxiv.org/pdf/2109.01950.pdf https://arxiv.org/pdf/2109.01950.pdf

137 points by seanclayton 4y ago

alberth 4y ago

Did WhatsApp/FB ever release their static type tool? All the FB blog posts from 2020 I find are broken links now.

DylanSp 4y ago
I'm also curious about this, I haven't heard anything in a while.
- di4na 4y ago
  Maybe but they don't use it. Internal politics changed the track they used to something more sustainable. Kinda.
ramchip 4y ago
Yes, kinda: https://github.com/WhatsApp/erlt https://github.com/WhatsApp/erlt

spinningslate 4y ago

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

moelf 4y ago

every other week there's a post about JIT, LLVM, etc. (either like this or more commonly in Python where people show it improving 5x or whatever) whenever I see it, it makes me feel like Julia-lang really did a good job picking the approach and technology all the way back in 2010

rad_gruchalski 4y ago
First Erlang version was released in 1986, LLVM 2003.
- chrisseaton 4y ago
  I don't think that's quite what they mean - Julia was specifically designed to be compiled. LLVM is a tech it uses, but it could use any compiler backend. It's the design that's amenable to compilation that's the important bit. https://dl.acm.org/doi/pdf/10.1145/3276490 https://dl.acm.org/doi/pdf/10.1145/3276490
  - deleted 4y ago
    [deleted]
  - ChrisRackauckas 4y ago
    Or more directly, the property of type groundedness + multiple dispatch allows for devirtualization of dispatches to get static-like performance in a dynamic language. That was the main design principle, which was a conjecture from Jeff's thesis later proven in a type-theoretic way by Jan Vitek's group. https://arxiv.org/pdf/2109.01950.pdf https://arxiv.org/pdf/2109.01950.pdf