4 ms·

Hey, Ben here from planetscale. I'm happy to answer any questions about this, or route the appropriate engineer (like the incredible vmg).

uds5501 2y ago
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?
- tanoku 2y ago
  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.
tmaly 2y ago
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.
celeritascelery 2y ago
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=PLFTr8ChfQg9t9quFJNSoRwVHQhLFfTYnV https://m.youtube.com/watch?v=V8dnIw3amLA&list=PLFTr8ChfQg9t...
- ncruces 2y ago
  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.

uds5501 2y ago

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?

tanoku 2y ago
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.

tmaly 2y ago

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.

celeritascelery 2y ago

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=PLFTr8ChfQg9t9quFJNSoRwVHQhLFfTYnV https://m.youtube.com/watch?v=V8dnIw3amLA&list=PLFTr8ChfQg9t...

ncruces 2y ago
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.