4 ms·
That’s awesome, I didn’t know SQLite had a bytecode. Based on my experience writing interpreters, I know that bytecode is faster to interpret. (Source: I wrot
by pizlonator 3y ago
That’s awesome, I didn’t know SQLite had a bytecode.
Based on my experience writing interpreters, I know that bytecode is faster to interpret.
(Source: I wrote JavaScriptCore’s interpreter and it’s optimizing JITs. I’ve also worked on other language implementations. I’ve seen the AST vs bytecode thing play out more than once.)
- andruc 3y agoFaster to interpret than what?
- jjice 3y agoI assume they meant faster to interpret than a tree of objects, since that's the other concept discussed in the article.
- pizlonator 3y agoYes
- iainmerrick 3y agoMaybe I'm missing something, but the bytecode approach seems really obviously better, just from a memory usage and locality point of view. Scanning an array of bytes or words is obviously going to be faster than traversing a tree of pointers. So I'd be surprised to find a serious language implementation using a pure AST in its interpreter, without at the very least flattening it to an array! Edit to add: of course there are some cases where you might actually want the AST approach, as the Sqlite doc is careful to point out. But not very many.
- pizlonator 3y agoIt’s fine to use an AST interpreter if you pair it with really great JITs. That has its own problems though - using an AST as a shared source of truth for your JIT compilers is cumbersome for implementing stuff like OSR. But from a perf standpoint, it’s probably fine. Also - say you want to optimize just for startup time, like if the code you’re running has minimal looping or reexecution. Then AST is better because you skip a step before first execution.