Re:Faster interpreters in Go: Catching up with C++
by cosmos0072 on Sunday April 06, 2025 @06:30AM
(#43600398)
The core idea is simple:
do a type analysis on each expression you want to "compile" to a closure, and instantiate the correct closure for each type combination.
Here is a pseudocode example, adapted from gomacro sources:
https://gist.github.com/cosmos72/f971c172e71d08030f92a1fc5fa...
This works best for "compiling" statically typed languages, and while much faster than an AST interpreter, the "tree of closures" above is still ~10 times slower that natively compiled code. And it's usually also slower than JIT-compiled code
Re:Faster interpreters in Go: Catching up with C++
by stevekemp on Sunday April 06, 2025 @02:39PM
(#43603803)
I put together this example after reading the article:
https://github.com/skx/simple-vm
Simpler than the full gomacro codebase, but perhaps helpful.
Re:Faster interpreters in Go: Catching up with C++
by cosmos0072 on Sunday April 06, 2025 @03:03PM
(#43604018)
For optimal speed, you should move as much code as possible outside the closures.
In particular, you should do the `switch op` at https://github.com/skx/simple-vm/blob/b3917aef0bd6c4178eed0c... outside the closure, and create a different, specialised closure for each case. Otherwise the "fast interpreter" may be almost as slow as a vanilla AST walker.
I'd love to see, if it's possible to create a libc-free, dependency-free executable without Nim (https://nim-lang.org/).