3 ms·
Regarding your Ruby example and the tracing JIT VM. I think the efforts of Mozilla regarding the TraceMonkey/JaegerMonkey efforts show that while tracing is ind
by sb 16y ago
Regarding your Ruby example and the tracing JIT VM. I think the efforts of Mozilla regarding the TraceMonkey/JaegerMonkey efforts show that while tracing is indeed a very good optimization technique, it is not by all means clear that it performs well on all benchmarks, particularly when compared to V8, which is a traditional method-at-a-time JIT compiler.
While I agree that there is nothing special about bytecode, interpreting it is regarded to be faster than AST interpreters. AFAIR, I read a paper about that, too, but cannot for the love of god remember its name/authors; also my impression is that Ruby 1.9 uses a bytecode interpreter (with some optimizations, such as direct threaded code interpreter).
- lemming 16y ago...particularly when compared to V8, which is a traditional method-at-a-time JIT compiler. Actually, my understanding is that V8 automatically compiles all JS code on load, it has no interpreter. So in a sense it's "method at a time" (i.e. its methods are compiled as units, it's not a trace system) but it's not traditional, and you could make an argument that it's not even a JIT.
- sb 16y agoYou are right, V8 does not have an interpreter. However, I think it is fairly accurately desribed as a JIT, because it compiles methods to native code when needed, i.e., before the first invocation/execution of any specific piece of code. Other approaches, like JVM, are more accurately described as "dynamic compilation" sub-systems of the virtual machine. At least that's my understanding of things, and I used to lump everything in that area into the "JIT" category, until (quite recently, actually) someone brought this small but important distinction to my attention. I don't see how one could make an argument not classifying V8 as a JIT compilation virtual machine, though...