Hacker News Reader

I can't speak to the non-technical reasons mentioned in the post, but there's good reason to believe that LLVM is in a very different state than the time that Reid wrote this, particularly wrt JIT support: the JIT engine has been completely replaced. Both of the things that he mentions (lack of back-patching, lack of gdb support) have been added to LLVM mainline.

View on HN

LLVM's JIT support has changed a lot, but one thing didn't change: "LLVM code generation and optimization is good but expensive."

Even LLVM's "fast" code generator is slower than most JITs' code generators.

Definitely true; there are some overheads that could be low-hanging fruit to optimize, but the real solution is most likely to use a tiered-compilation system. ie only invoke the full LLVM code generator once a function has been called 10,000 times. It's definitely an open question as to how to get faster compilation times out of it; we have a simple LLVM interpreter but since LLVM isn't designed for interpretation it's pretty slow.

I think you can look at the people who are interested in adding LLVM tiers to their JITs (ex Apple, Facebook) to see that we're not the only ones that think there can be a place for "good but expensive" code generation in a JIT.

Like this?

https://github.com/dropbox/pyston#compilation-tiers

Reply on news.ycombinator.com