The decision to avoid LLVM (for JIT) due to its lack of age/maturity strikes me as extremely odd. I can't think of a piece of technology that has as much universality, buy-in, functionality, and compatibility.
We tried to implement an LLVM based JIT compiler for PHP. There's basically two problems: First, LLVM is excruciatingly slow. If I remember correctly, it took more than a minute to compile all the WP functions for a front-page access (this is something like 100k VM instructions translated to LLVM bitcode). Second, LLVM is not great at optimizing the kind of IR that a JIT compiler for a dynamic language emits. It is much more important to perform language-specific optimizations prior to lowering. HHVM basically came to the same conclusion [1]. They lowered vasm to LLVM IR and let LLVM perform additional optimizations and native codegen. The difference was basically noise.
On the other hand, there are projects that do successfully use LLVM for JIT. We now experiment with dynasm, which doesn't optimize, but is fast and much more pleasant to use. libjit looks like another popular option.
[1]: http://hhvm.com/blog/10205/llvm-code-generation-in-hhvm
The only viable options are dynasm, a simple selfmade jit as in potion/tinyrb or rpython. perl6 went with dynasm.
rujit looked good to me, but the tracing overhead was too much. They should really analyze why it was so big, even as tracing jit.
And the datastructures need to be slimmed down, as in potion/tinyrb or php7 or lua/lisps. Only tagging schemes lead to performance. This has nothing to do with the jit. size matters.
There are some JITs that used (tried to use) LLVM but eventually stopped using it, see HHVM or Apples JavaScriptCore (despite that Apple is heavily involved in LLVM). LLVM is great as a AOT-compiler, but JITs seem to need faster compilation-times for some benchmarks. See this blog for some numbers from Apple: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...
But yeah, their reasoning for avoiding it was a bit strange. Although I understand them when they say that LLVM as a dependency may be to huge for Ruby. LLVM is huge and the bigger project compared to Ruby with major backers (Apple, Google, etc.). What is important for Ruby may not be what has high-priority for the LLVM project. IMHO Ruby is big enough to warrant its own JIT.
I'm not disputing that. But stuff like hot patching, profiling, etc is in beta or missing. Just compiling on demand is not enough for make dynamic languages fast.
Comments
The decision to avoid LLVM (for JIT) due to its lack of age/maturity strikes me as extremely odd. I can't think of a piece of technology that has as much universality, buy-in, functionality, and compatibility.
We tried to implement an LLVM based JIT compiler for PHP. There's basically two problems: First, LLVM is excruciatingly slow. If I remember correctly, it took more than a minute to compile all the WP functions for a front-page access (this is something like 100k VM instructions translated to LLVM bitcode). Second, LLVM is not great at optimizing the kind of IR that a JIT compiler for a dynamic language emits. It is much more important to perform language-specific optimizations prior to lowering. HHVM basically came to the same conclusion [1]. They lowered vasm to LLVM IR and let LLVM perform additional optimizations and native codegen. The difference was basically noise.
On the other hand, there are projects that do successfully use LLVM for JIT. We now experiment with dynasm, which doesn't optimize, but is fast and much more pleasant to use. libjit looks like another popular option. [1]: http://hhvm.com/blog/10205/llvm-code-generation-in-hhvm
LLVM is too big and not good enough.
The only viable options are dynasm, a simple selfmade jit as in potion/tinyrb or rpython. perl6 went with dynasm.
rujit looked good to me, but the tracing overhead was too much. They should really analyze why it was so big, even as tracing jit.
And the datastructures need to be slimmed down, as in potion/tinyrb or php7 or lua/lisps. Only tagging schemes lead to performance. This has nothing to do with the jit. size matters.
This is a really nice read by RuJIT's creator - Masahiro Ide (his Doctoral Thesis [0]).
[0] - http://kamome.lib.ynu.ac.jp/dspace/bitstream/10131/9368/1/id...
P.S. this is available via google results, I'm assuming it's public domain
There are some JITs that used (tried to use) LLVM but eventually stopped using it, see HHVM or Apples JavaScriptCore (despite that Apple is heavily involved in LLVM). LLVM is great as a AOT-compiler, but JITs seem to need faster compilation-times for some benchmarks. See this blog for some numbers from Apple: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...
But yeah, their reasoning for avoiding it was a bit strange. Although I understand them when they say that LLVM as a dependency may be to huge for Ruby. LLVM is huge and the bigger project compared to Ruby with major backers (Apple, Google, etc.). What is important for Ruby may not be what has high-priority for the LLVM project. IMHO Ruby is big enough to warrant its own JIT.
IIRC LLVM's functionality for JIT is new and/or experimental (patchpoints).
Sure, LLVM can literally compile just in time, but JITs need much more than that.
LLVM has been able to JIT for years. Some fancy stuff might be WIP but the basic support has been there for ages.
I'm not disputing that. But stuff like hot patching, profiling, etc is in beta or missing. Just compiling on demand is not enough for make dynamic languages fast.