logoalt Hacker News

ncrucesyesterday at 2:35 PM3 repliesview on HN

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.


Replies

wrsyesterday at 4:17 PM

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.

Joker_vDyesterday at 3:35 PM

> 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.