3 ms·

The idea of generating an interpreter from the compiler is really neat. What I missed in this article is why the Baseline Interpreter is faster than the C++ in

The idea of generating an interpreter from the compiler is really neat. What I missed in this article is why the Baseline Interpreter is faster than the C++ interpreter. The code snippet for the load zero instruction looks like what a compiler should produce for a straightforward C++ switch case for that instruction. Except that the code uses a push instruction to store the value directly on the system stack, whereas the C++ interpreter would presumably use a more general store instruction into an array (in the heap, maybe) treated as the interpreter stack. Is that the difference, or am I missing something else?

mattnewport 7y ago
The article called it a threaded interpreter, the answer to this question explains what that usually means and why it it faster: https://stackoverflow.com/questions/3848343/decode-and-dispatch-interpretation-vs-threaded-interpretation https://stackoverflow.com/questions/3848343/decode-and-dispa... I found the explanation of what they're doing a little unclear though and it seems they might not be doing exactly what is described in the answer above.
- tom_mellior 7y ago
  The dispatch part of the code snippet looks to me like what you would also get with computed gotos. Something like goto instruction_labels[++pc]. So that shouldn't be the difference, compilers can compile this well. As for whether this is "threaded", and exactly what kind of threading it is, there is widespread confusion and abuse of terminology. https://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Threaded_code
jandem 7y ago
> Is that the difference, or am I missing something else? That's part of it. The generated interpreter should be a bit faster for simple instructions because of the reason you give (also: things like debugger breakpoints have more overhead in the C++ Interpreter). However, the bigger speedups are because the generated interpreter can use Inline Caches like the Baseline JIT. The C++ Interpreter does not have ICs.
- tom_mellior 7y ago
  Ah, yes, inline caching probably explains it. Thanks!

mattnewport 7y ago

The article called it a threaded interpreter, the answer to this question explains what that usually means and why it it faster: https://stackoverflow.com/questions/3848343/decode-and-dispatch-interpretation-vs-threaded-interpretation https://stackoverflow.com/questions/3848343/decode-and-dispa... I found the explanation of what they're doing a little unclear though and it seems they might not be doing exactly what is described in the answer above.

tom_mellior 7y ago
The dispatch part of the code snippet looks to me like what you would also get with computed gotos. Something like goto instruction_labels[++pc]. So that shouldn't be the difference, compilers can compile this well. As for whether this is "threaded", and exactly what kind of threading it is, there is widespread confusion and abuse of terminology. https://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Threaded_code

jandem 7y ago

> Is that the difference, or am I missing something else? That's part of it. The generated interpreter should be a bit faster for simple instructions because of the reason you give (also: things like debugger breakpoints have more overhead in the C++ Interpreter). However, the bigger speedups are because the generated interpreter can use Inline Caches like the Baseline JIT. The C++ Interpreter does not have ICs.

tom_mellior 7y ago
Ah, yes, inline caching probably explains it. Thanks!