[sfink]

It's interesting to see the parallels between this and an engine for a dynamic programming language. The one I'm most familiar with is JavaScript.

When you first need to run something, you run it on the interpreter (JS) / ubershader (Dolphin). But once you know it's going to be run repeatedly (rarely for JS, almost always for Dolphin), you kick off an async compilation to produce JIT code (JS) / a specialized shader (Dolphin). You continue running in the expensive mode (interpreter / ubershader) until the compilation is complete, then you switch over seamlessly.

[shepherdjerred]

While JS can be interpreted, V8 and SpiderMonkey (the two most common JS engines) will _always_ compile before execution -- JS is _never_ directly interpreted these days (aside from more niche engines).

https://v8.dev/blog/ignition-interpreter

https://firefox-source-docs.mozilla.org/js/index.html#javasc...

[sfink]

That's not exactly right. I believe you're mixing up bytecode generation with compilation. The source code will indeed be compiled down to bytecode, but that doesn't count since it does not change the generality. As in, bytecode is no more specialized than the original source code. It's the same with shaders — the ubershader does not interpret the original shader source text.

Both V8 and SM will interpret the bytecode until it warms up enough to be compiled to specialized machine code. ("Warms up" == "is observed to execute enough times".) There are some subtle distinctions about whether the interpreter is implemented in C++ or generated by a variant of the JIT code compiler, but as with the shaders the main point is whether it's executed in a way that works for everything or is specialized to a particular purpose (and varying degrees of specialization are implemented, with various mechanisms for falling back to a more general execution mechanism if the specialization assumptions no longer hold).

Your SpiderMonkey doc link points to a section named "JavaScript Interpreter". The title is correct, that section is indeed about the mechanisms for interpreting JavaScript [bytecode].

The V8 link is a little tricky, since it leads off with "Code is initially compiled by a baseline compiler", but if you read a little further, it says "...the V8 team has built a new JavaScript interpreter, called Ignition, which can replace V8’s baseline compiler". Basically, V8 experimented for a while with dropping the interpreter, but for the reasons described well in that document, they went back to initially running in an interpreter. The article is quite nice and describes quite a bit about the tradeoffs involved. It's 8 years old, but I believe the overall picture isn't that different today.

(Source: I am an engineer on the SpiderMonkey team.)

[shepherdjerred]

I don't think your reply conflicts with my comment. I was clarifying that modern JS engines do not directly interpret JS. JS is always compiled to bytecode which is then interpreted or compiled to machine code.

[mst]

I might have said "oh, _clever_" out loud when that first clicked as I read through the piece.