Comment by simonask
5 days ago
The simplest JIT just generates the machine code instructions that the interpreter loop would execute anyway. It’s not an extremely difficult thing, but it also doesn’t give you much benefit.
A worthwhile JIT is a fully optimizing compiler, and that is the hard part. Language semantics are much less important - dynamic languages aren’t particularly harder here, but the performance roof is obviously just much lower.
Agree re: different types of JITs producing wildly different results but don't agree about language semantics - even a Java JIT has to give up speed due to certain seemingly minor language and JVM issues. So both matter - no matter how good of a compiler engineer you are, some semantics are just not optimizable. Indeed, the use of a "trace JITs" is a proof of that.
This is orthogonal to the difficulty of actually implementing a JIT compiler.
It’s very much possible to make something less advanced than JVM or CLR, or even V8, that will still outperform an interpreter, even for an extremely dynamic language like Python.
As others have mentioned, the roadblock here is that interpreter internals are too public, so doing it without breaking the C API that extensions use is really hard.