3 ms·

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

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.)
  - saurik 6y ago
    Clearly, Chris's thought process has to be correct to some real extent and mostly must be deferred to in the end; but, I was a grad student interested in the Low-Level Virtual Machine at the time, and I remember it was absolutely considered by everyone to be a runtime execution system with a JIT ;P and what made it unique vs. "high-level" virtual machines was that it was going to allow unsafe code, trusted by default, but otherwise work like any other virtual machine, allowing for JIT-like benefits (profile guided being one, as you mention)... I am totally willing to believe that everyone misunderstood the project at the time and the at the well over a decade since has corrupted what memory I have of the discussions.

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.)
- saurik 6y ago
  Clearly, Chris's thought process has to be correct to some real extent and mostly must be deferred to in the end; but, I was a grad student interested in the Low-Level Virtual Machine at the time, and I remember it was absolutely considered by everyone to be a runtime execution system with a JIT ;P and what made it unique vs. "high-level" virtual machines was that it was going to allow unsafe code, trusted by default, but otherwise work like any other virtual machine, allowing for JIT-like benefits (profile guided being one, as you mention)... I am totally willing to believe that everyone misunderstood the project at the time and the at the well over a decade since has corrupted what memory I have of the discussions.