3 ms·

LLVM is a fairly heavyweight tool to use for simplistic or really frequent JIT use-cases. There is definitely room for smaller and simpler tools for that purpos

LLVM is a fairly heavyweight tool to use for simplistic or really frequent JIT use-cases. There is definitely room for smaller and simpler tools for that purpose, imo. Like, I'm pretty sure LuaJIT runs rings around LLVM in terms of how quickly it generates code, but at the cost of doing considerably less optimization. This is sometimes a useful tradeoff.

haberman 10y ago
> I'm pretty sure LuaJIT runs rings around LLVM in terms of how quickly it generates code, but at the cost of doing considerably less optimization. This is sometimes a useful tradeoff. You can't really compare LuaJIT and LLVM directly, because LuaJIT is a trace compiler. A LuaJIT trace is a linear sequence of instructions with no control flow, which makes optimization much easier. LLVM on the other hand is statically compiling code consisting of many basic blocks and potentially complicated control flow between them. So LLVM's job is much harder. LuaJIT's optimizer doesn't have to work nearly as hard to get a similar quality of code.
- sitkack 10y ago
  Because LLVM isn't a JIT in the sense of PyPy, the JVM or Lua. It is more in the sense of the CLR, a late bound AoT compiler. It doesn't watch data access patterns, it doesn't watch arms of a switch statement, there is no feedback.
RossBencina 10y ago
"but at the cost of doing considerably less optimization" That's arguable. Ravi[1] is a Lua implemented with an LLVM-based JIT. The benchmarks here[2] compare runtime performance of Ravi vs. LuaJIT. The Ravi timings don't include compilation time, the LuaJIT timings do. Sometimes LuaJIT siginficantly outperforms Ravi, sometimes it's on par, sometimes worse. But the results don't suggest that there is less (effective) optimisation going on. [1] https://github.com/dibyendumajumdar/ravi https://github.com/dibyendumajumdar/ravi [2] http://the-ravi-programming-language.readthedocs.io/en/latest/ravi-benchmarks.html http://the-ravi-programming-language.readthedocs.io/en/lates...
- chrisseaton 10y ago
  I think it's a bit more complex than that. I'm pretty sure that LLVM does use more optimisation passes and techniques than LuaJIT's backend, however LuaJIT optimises with knowledge of the semantics of Lua, whereas LLVM optimises as if it was optimising something like C.
- pcwalton 10y ago
  The parent post is correct. LLVM's optimizations are low-level optimizations tuned for C and C++. By contrast, the optimizations you want to do for dynamic languages (and high-level languages in general) are high-level optimizations that are better done on language-specific IRs. Moreover, dynamic languages need dynamic optimizations such as polymorphic inline caching, speculation and bailouts with on stack replacement, etc. Optimization pipelines are invariably language-specific. If you were to somehow make LuaJIT into a C/C++ compiler without doing any work on its optimizer, you would get similarly poor results.
  - gliptic 10y ago
    True. Although, LuaJIT does pretty well on C-style code using its FFI library. But that's something it's designed for, so not really surprising.
  - ihnorton 10y ago
    > If you were to somehow make LuaJIT into a C/C++ compiler Clang -> Sulong -> Java bytecode -> Luje [1]? May need more turtles :) Technically, one reason -of several- this probably wouldn't work without significant effort is that Sulong relies on Graal's FFI intrinsics. But those should be convertible to LuaJIT FFI calls (in theory). [1] https://cowlark.com/luje/ https://cowlark.com/luje/

haberman 10y ago

> I'm pretty sure LuaJIT runs rings around LLVM in terms of how quickly it generates code, but at the cost of doing considerably less optimization. This is sometimes a useful tradeoff. You can't really compare LuaJIT and LLVM directly, because LuaJIT is a trace compiler. A LuaJIT trace is a linear sequence of instructions with no control flow, which makes optimization much easier. LLVM on the other hand is statically compiling code consisting of many basic blocks and potentially complicated control flow between them. So LLVM's job is much harder. LuaJIT's optimizer doesn't have to work nearly as hard to get a similar quality of code.

sitkack 10y ago
Because LLVM isn't a JIT in the sense of PyPy, the JVM or Lua. It is more in the sense of the CLR, a late bound AoT compiler. It doesn't watch data access patterns, it doesn't watch arms of a switch statement, there is no feedback.

RossBencina 10y ago

"but at the cost of doing considerably less optimization" That's arguable. Ravi[1] is a Lua implemented with an LLVM-based JIT. The benchmarks here[2] compare runtime performance of Ravi vs. LuaJIT. The Ravi timings don't include compilation time, the LuaJIT timings do. Sometimes LuaJIT siginficantly outperforms Ravi, sometimes it's on par, sometimes worse. But the results don't suggest that there is less (effective) optimisation going on. [1] https://github.com/dibyendumajumdar/ravi https://github.com/dibyendumajumdar/ravi [2] http://the-ravi-programming-language.readthedocs.io/en/latest/ravi-benchmarks.html http://the-ravi-programming-language.readthedocs.io/en/lates...

chrisseaton 10y ago
I think it's a bit more complex than that. I'm pretty sure that LLVM does use more optimisation passes and techniques than LuaJIT's backend, however LuaJIT optimises with knowledge of the semantics of Lua, whereas LLVM optimises as if it was optimising something like C.
pcwalton 10y ago
The parent post is correct. LLVM's optimizations are low-level optimizations tuned for C and C++. By contrast, the optimizations you want to do for dynamic languages (and high-level languages in general) are high-level optimizations that are better done on language-specific IRs. Moreover, dynamic languages need dynamic optimizations such as polymorphic inline caching, speculation and bailouts with on stack replacement, etc. Optimization pipelines are invariably language-specific. If you were to somehow make LuaJIT into a C/C++ compiler without doing any work on its optimizer, you would get similarly poor results.
- gliptic 10y ago
  True. Although, LuaJIT does pretty well on C-style code using its FFI library. But that's something it's designed for, so not really surprising.
- ihnorton 10y ago
  > If you were to somehow make LuaJIT into a C/C++ compiler Clang -> Sulong -> Java bytecode -> Luje [1]? May need more turtles :) Technically, one reason -of several- this probably wouldn't work without significant effort is that Sulong relies on Graal's FFI intrinsics. But those should be convertible to LuaJIT FFI calls (in theory). [1] https://cowlark.com/luje/ https://cowlark.com/luje/