News for hackers. Stuff that matters.
Re:Faster interpreters in Go: Catching up with C++ by bddicken on Thursday March 20, 2025 @02:11PM (#43426818)
Hey, Ben here from planetscale. I'm happy to answer any questions about this, or route the appropriate engineer (like the incredible vmg).
Re:Faster interpreters in Go: Catching up with C++ by tmaly on Thursday March 20, 2025 @03:14PM (#43427657)
Ben, just curious if any of your engineers use AI for coding?

I was listening to an episode of Latent Space and they were interviewing Bret Taylor of Google Maps fame.

He made an interesting point, that you could just ask the AI to code in Rust instead of say Python and you would get the memory safety benefits by just compiling.

Re:Faster interpreters in Go: Catching up with C++ by uds5501 on Thursday March 20, 2025 @02:33PM (#43427134)
I noticed the de-optimization bits when the compiler handles corner cases. How often did Vitess notice that the VM had to switch back to the old AST implementation?
Re:Faster interpreters in Go: Catching up with C++ by tanoku on Thursday March 20, 2025 @03:16PM (#43427675)
Very very seldomly! Obviously we need to be correct in 100% of the cases, which is why the de-optimizer is there, but in practice it just never triggers. Right now the things that trigger a deopt are very limited — malformed time literals, oferflowing integer negations and very little else. The performance impact is essentially zero.
Re:Faster interpreters in Go: Catching up with C++ by celeritascelery on Thursday March 20, 2025 @07:39PM (#43430296)
Thanks for writing this. I am curious if you benchmarked the giant switch implementation? While the current VM has some benefits (no bytecode, easy to pass argument's, cleaner compiler, etc ) it also has some performance overhead. Some that I am thinking of:

1. Every instruction results in functional call overhead, which is something that tail calls (with protect_none) avoid.

2. Because you are using closures the next instruction has to be heap allocated. I don’t know what closures look like in Go, but there will involve some indirection.

3. Every iteration of the loop requires a bounds check on ip.

Now, none of these may matter for SQL because as the blog post said, the instructions are quite large. And it already shows huge improvements over the AST interpreter. I am just curious how the switch would benchmark.

On an unrelated note. Using closures to write an interpreter brought to mind this talk https://m.youtube.com/watch?v=V8dnIw3amLA&list=PLFTr8ChfQg9t...

Re:Faster interpreters in Go: Catching up with C++ by ncruces on Thursday March 20, 2025 @08:16PM (#43430565)
Not the author.

Each instruction is an heap allocated closure, but it's allocated at “compile” time (when you generate the instruction from the AST), not at runtime (every time you run the instruction): by then they're (preallocated) free standing functions that receive the VM.

Every iteration of the loop in a big switch bytecode interpreter also requires a bounds checks.