Comment by ncruces
5 hours ago
If you build flattened a vector of them (as they argue), it can approach a byte code interpreter, though it won't be a very dense vector, if it holds "pointers" (that you need to chase) to the instructions instead of the instructions themselves.
A lot of the slowness of interpreters (and why JITs work) comes from the fact that you're executing (and trying to predict) the interpreter's branches - not the branches in the interpreted code.
This doesn't move the needle there, at all.
So…you can transform it into a threaded interpreter?
This seems like a ton of LLM verbiage making two simple and very standard techniques sound artificially profound.
> If you build flattened a vector of them
Well, yes, it's an old way to represent ASTs: allocate them all sequentially from a huge arena (worked especially nicely for BCPL). Except the author actually uses their home-grown vecte<Element*> which, as far as I can tell, uses malloc/realloc. And there are several pointer indirections inside the liste/ITEM/LIST classes so... yeah.