[HN Gopher] Faster interpreters in Go: Catching up with C++
       ___________________________________________________________________
        
       Faster interpreters in Go: Catching up with C++
        
       Author : ksec
       Score  : 72 points
       Date   : 2025-04-05 17:59 UTC (5 hours ago)
        
 (HTM) web link (planetscale.com)
 (TXT) w3m dump (planetscale.com)
        
       | hinkley wrote:
       | Compiling queries is one of those things that is both Make it
       | Right and Make it Fast.
       | 
       | Because bind variables and Prepared Statements go hand in hand,
       | you want to do everything you can to coax your users into doing
       | the right thing. If each unique query has to be compiled before
       | first use, that's an extra inducement to using prepared
       | statements properly.
        
       | rockwotj wrote:
       | The resulting VM implementation reminds me of this post from
       | cloudflare where they similarly use closures to build their
       | interpreter.
       | 
       | https://blog.cloudflare.com/building-fast-interpreters-in-ru...
        
       | cosmos0072 wrote:
       | Compiling an expression to a tree of closures, and a list of
       | statements to a slice of closures, is exactly how I optimized
       | [gomacro](https://github.com/cosmos72/gomacro) my Go interpreter
       | written in go.
       | 
       | There are more tricks available there, as for example unrolling
       | the loop that calls the list of closures, and having a `nop`
       | closure that is executed when there's nothing to run but
       | execution is not yet at the end of the the unrolled loop.
        
       | MatthiasPortzel wrote:
       | It's crazy that this post seems to have stumbled across an
       | equivalent to the Copy-and-Patch technique[0] used to create a
       | Lua interpreter faster than LuaJit[1]
       | 
       | [0]: https://sillycross.github.io/2023/05/12/2023-05-12/ [1]:
       | https://sillycross.github.io/2022/11/22/2022-11-22/
       | 
       | The major difference is that LuaJIT Remake's Copy-and-Patch
       | requires "manually" copying blocks of assembly code and patching
       | values, while this post relies on the Go compiler's closures to
       | create copies of the functions with runtime-known values.
       | 
       | I think there's fascinating processing being made in this area--I
       | think in the future this technique (in some form) will be the go-
       | to way to create new interpreted languages, and AST interpreters,
       | switch-based bytecode VMs, and JIT compilation will be things of
       | the past.
        
       | politician wrote:
       | It would be ideal if Go would add support for computed goto, so
       | that we could build direct threaded interpreters.
        
         | zabzonk wrote:
         | I don't think "ideal" would be the exact word - I used to
         | shudder at it in FORTRAN.
        
         | kiitos wrote:
         | hard no - goto is a feature for code generators, not anything
         | meant for human use
        
         | 9dev wrote:
         | Go to goto, go!
        
         | pklausler wrote:
         | Did you mean "assigned GOTO", not computed GOTO? Because that's
         | just a switch list.
        
       | kiitos wrote:
       | vitess is not the answer
        
       ___________________________________________________________________
       (page generated 2025-04-05 23:00 UTC)