5 ms·

Interesting. Here is also a podcast about the topic: https://thinkingelixir.com/podcast-episodes/017-jit-compiler-for-beam-with-lukas-larsson-and-john-hogberg/

by Rochus 6y ago

Interesting. Here is also a podcast about the topic: https://thinkingelixir.com/podcast-episodes/017-jit-compiler-for-beam-with-lukas-larsson-and-john-hogberg/ https://thinkingelixir.com/podcast-episodes/017-jit-compiler... Had a brief look at asmjit; as it seems it only supports x86 and x86_64 and is not really an abstraction (i.e. a platform independent IR). I will try to find out why they didn't use e.g. LLVM or sljit. EDIT: according to this article (https://www.erlang-solutions.com/blog/performance-testing-the-jit-compiler-for-the-beam-vm.html https://www.erlang-solutions.com/blog/performance-testing-th...) the speed-up factor caused by the JIT is about 1.3 to 2.3 (as a comparison the speed-up between the PUC Lua 5.1 interpreter and LuaJIT 2.0 is about factor 15 in geometric mean over all benchmarks, see http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html).

alberth 6y ago
Re: “it seems it only support x86 and x86_64” Probably because it uses DynASM and I believe only those platforms are supported. https://luajit.org/dynasm.html https://luajit.org/dynasm.html
- Rochus 6y ago
  > Probably because it uses DynASM I had a look at https://github.com/asmjit/asmjit/tree/master/src/asmjit https://github.com/asmjit/asmjit/tree/master/src/asmjit and didn't find any indication that DynASM is used. Anyway, DynASM and LuaJIT are available for many different architectures, not only x86 and x86_64.
  - alberth 6y ago
    This link has more detail https://github.com/erlang/otp/pull/2745#issuecomment-691482132 https://github.com/erlang/otp/pull/2745#issuecomment-6914821... “ LLVM is much slower at generating code when compared to asmjit. LLVM can do a lot more, but it's main purpose is not to be a JIT compiler. With asmjit we get full control over all the register allocation and can do a lot of simplifications when generating code. On the downside we don't get any of LLVMs built-in optimizations. We also considered using dynasm, but found the tooling that comes with asmjit to be better. “
    - Rochus 6y ago
      This quote from your reference gives the answer: We also considered using dynasm, but found the tooling that comes with asmjit to be better. EDIT: But it still gives no answer why they preferred asmjit in favour of other solutions than LLVM or DynASM (where the latter is just an assembler which helps to integrate with C code, not a platform abstraction like LLVM or others).
tachyonbeam 6y ago
LLVM is much too heavyweight for a JIT. It's slow at generating code, and makes it difficult to implement common JIT optimizations such as inline caches, which rely on code-patching.
- Rochus 6y ago
  Yes, LLVM is huge, but there are a couple of interesting alternatives such as sljit, see e.g. https://github.com/wdv4758h/awesome-jit https://github.com/wdv4758h/awesome-jit Even LuaJIT can be used as a backend for other languages than Lua, see e.g. https://github.com/rochus-keller/oberon/ https://github.com/rochus-keller/oberon/.
  - kzrdude 6y ago
    Makes me wonder if Python implemented in lua wouldn't just win over CPython
    - Rochus 6y ago
      If using LuaJIT it would be faster than CPython for sure, maybe even as fast as PyPy. Here are some measurement results comparing the C++ SOM interpreter with a LuaJIT bytecode compiler: https://github.com/rochus-keller/Som#a-som-to-luajit-bytecode-compiler-and-debugger https://github.com/rochus-keller/Som#a-som-to-luajit-bytecod.... The bytecode version of the SOM benchmark running on LuaJIT is about factor 24 faster than the C++ based interpreter. But the Gral implementation of SOM is even faster.
- saurik 6y ago
  (Which is, of course, ironic given that the entire original goal of LLVM was only to build a JIT; it was too slow, but made an OK enough compiler backend ;P.)
  - jcranmer 6y ago
    > the entire original goal of LLVM was only to build a JIT That's not exactly true from what I recall of speaking with Vikram and Chris. The idea was to build a compiler framework that could support profile-guided optimization (and other then-advanced JIT techniques) for idle-time or install-time optimization of C/C++ codes. Chris's original thesis doesn't even mention JIT compilers, except as comparison point for techniques, and instead focuses on things like link-time optimization. (Indeed, Chris offered LLVM to replace gcc's then-broken LTO infrastructure, but this was turned down.)
dnautics 6y ago
Also keep in mind that the lua speedup is in interpreted vs compiled, and erlang is already a compiled language that had a fairly performant intermediate bytecode.
- deleted 6y ago
  [deleted]
- Rochus 6y ago
  But the bytecode is interpreted, isn't it? The PUC Lua VM is a bytecode interpreter as well.
Asm2D 6y ago
There is an aarch64 branch in AsmJit project that provides an experimental AArch64 backend. It's pretty complete. Having a platform independent IR in AsmJit is not planned. AsmJit is more about control and ISA completeness. IR could of course be implemented on top of AsmJit, but it seems nobody really needed that so far - users that need complex IR can use LLVM and users that want something really simple can use SLJIT. AsmJit is just in a different category and it has a lot of useful features considering its size.

by Rochus 6y ago

alberth 6y ago

Re: “it seems it only support x86 and x86_64” Probably because it uses DynASM and I believe only those platforms are supported. https://luajit.org/dynasm.html https://luajit.org/dynasm.html

Rochus 6y ago
> Probably because it uses DynASM I had a look at https://github.com/asmjit/asmjit/tree/master/src/asmjit https://github.com/asmjit/asmjit/tree/master/src/asmjit and didn't find any indication that DynASM is used. Anyway, DynASM and LuaJIT are available for many different architectures, not only x86 and x86_64.
- alberth 6y ago
  This link has more detail https://github.com/erlang/otp/pull/2745#issuecomment-691482132 https://github.com/erlang/otp/pull/2745#issuecomment-6914821... “ LLVM is much slower at generating code when compared to asmjit. LLVM can do a lot more, but it's main purpose is not to be a JIT compiler. With asmjit we get full control over all the register allocation and can do a lot of simplifications when generating code. On the downside we don't get any of LLVMs built-in optimizations. We also considered using dynasm, but found the tooling that comes with asmjit to be better. “
  - Rochus 6y ago
    This quote from your reference gives the answer: We also considered using dynasm, but found the tooling that comes with asmjit to be better. EDIT: But it still gives no answer why they preferred asmjit in favour of other solutions than LLVM or DynASM (where the latter is just an assembler which helps to integrate with C code, not a platform abstraction like LLVM or others).

tachyonbeam 6y ago

LLVM is much too heavyweight for a JIT. It's slow at generating code, and makes it difficult to implement common JIT optimizations such as inline caches, which rely on code-patching.

Rochus 6y ago
Yes, LLVM is huge, but there are a couple of interesting alternatives such as sljit, see e.g. https://github.com/wdv4758h/awesome-jit https://github.com/wdv4758h/awesome-jit Even LuaJIT can be used as a backend for other languages than Lua, see e.g. https://github.com/rochus-keller/oberon/ https://github.com/rochus-keller/oberon/.
- kzrdude 6y ago
  Makes me wonder if Python implemented in lua wouldn't just win over CPython
  - Rochus 6y ago
    If using LuaJIT it would be faster than CPython for sure, maybe even as fast as PyPy. Here are some measurement results comparing the C++ SOM interpreter with a LuaJIT bytecode compiler: https://github.com/rochus-keller/Som#a-som-to-luajit-bytecode-compiler-and-debugger https://github.com/rochus-keller/Som#a-som-to-luajit-bytecod.... The bytecode version of the SOM benchmark running on LuaJIT is about factor 24 faster than the C++ based interpreter. But the Gral implementation of SOM is even faster.
saurik 6y ago
(Which is, of course, ironic given that the entire original goal of LLVM was only to build a JIT; it was too slow, but made an OK enough compiler backend ;P.)
- jcranmer 6y ago
  > the entire original goal of LLVM was only to build a JIT That's not exactly true from what I recall of speaking with Vikram and Chris. The idea was to build a compiler framework that could support profile-guided optimization (and other then-advanced JIT techniques) for idle-time or install-time optimization of C/C++ codes. Chris's original thesis doesn't even mention JIT compilers, except as comparison point for techniques, and instead focuses on things like link-time optimization. (Indeed, Chris offered LLVM to replace gcc's then-broken LTO infrastructure, but this was turned down.)

dnautics 6y ago

Also keep in mind that the lua speedup is in interpreted vs compiled, and erlang is already a compiled language that had a fairly performant intermediate bytecode.

deleted 6y ago
[deleted]
Rochus 6y ago
But the bytecode is interpreted, isn't it? The PUC Lua VM is a bytecode interpreter as well.

Asm2D 6y ago

There is an aarch64 branch in AsmJit project that provides an experimental AArch64 backend. It's pretty complete. Having a platform independent IR in AsmJit is not planned. AsmJit is more about control and ISA completeness. IR could of course be implemented on top of AsmJit, but it seems nobody really needed that so far - users that need complex IR can use LLVM and users that want something really simple can use SLJIT. AsmJit is just in a different category and it has a lot of useful features considering its size.