I'm not sure how you came up with those numbers but I disagree.
A while back I made a python module for libjit and during experimentation I easily got more than 10x speedups by simply translating the python code to the jit. Dusted off the code and ran the test on two different gcd algorithms (time in seconds for 100000 iterations):
I am working on interpreters and compilers for dynamic languages for my PHD. I'm spitballing the numbers a bit but in my experience the exact speedups vary a lot depending on the particular choice of language and benchmark. I have more experience with Lua, for which I wrote a bytecode-to-C compiler once (gcc can do wonderful things if you throw some C code at it...). Most of my benchmarks got a speedup between 2x to 3x but some of them got up to 9x.
BTW, "number crunchy" benchmarks like GCD are the best case scenario for ahead of time compilation because the interpretation overhead for them is very high. The interpreter is running lots of bytecodes, and each bytecode is only doing one or two machine instructions of actual work. Did you happen to compare your results against a C implementation of the program (or PyPy JIT)? My experience with Lua was that despite the high speedups compared to the interpreter, the numeric benchmarks still ran much slower than something an AOT compiler for a statically-typed language (or a speculative JIT for a dynamic one) can produce. There is a high cost to the dynamic typing, as variables have to be stored in the interpreter stack instead of in machine registers, and the diamond-shaped control flow gets in the way of optimizations, etc. Getting a 10x speedup in a benchmark that runs 100x slower than C might mean that there is still a lot of fat left to cut :)
So you did a wrapper around libjit and generated functions on-the-fly?
I am not sure it counts as a full bytecode jit. :-)
I did a very stupid jit for the PigletVM thing while working on the article and the difference was more like 1.2-1.5 compared to the first naive interpreter.
> Did you find any use for the libjit wrapper? is it usable practically?
Other than it starting me off on a multi-year dive down the compiler/interpreter rabbit hole I didn't do too much with it since I didn't really have the knowledge to use it at the time. I also want to rewrite it because the C++ libjit API is kind of wonky and it really should be using the C-API but haven't gotten around to it yet.
Someday I'll get motivated and work on it again, have a couple half finished projects that could use it as a back end if I ever get around to finishing them.
A while back I made a python module for libjit and during experimentation I easily got more than 10x speedups by simply translating the python code to the jit. Dusted off the code and ran the test on two different gcd algorithms (time in seconds for 100000 iterations):
The jitted functions would probably be a small bit faster if I did any sort of optimations other than a simple algorithmic translation.