Another really interesting way to approach this problem would be to adapt wasm2c to emit Go output. It should result in better performance than wazero.
One of the problems of the modernc approach (IMO) is that they're not just transpiling CPU/compute stuff, but entirely OS/platform stuff.
Each Go file of theirs is a xxx_os_arch.go that starts with 100s of OS-#defines-as-consts, and goes on to transpile fully #ifdefed code.
It also implements antithetical (in Go) stuff like goroutine local storage, because libc pthreads can't live without it.
And all IO is via direct syscalls that will never play nice with the Go scheduler, because again, this is OS level stuff.
WASM defines a cross platform CPU and an ABI, and using that for compute and the bottom OS layer in Go you get (IMO) a nicer end result.
Given the hard task of generating decent code from WASM at load time (wazero's compiler is pretty naive, a better one is being developed, but it will take seconds to generate good code for anything non trivial like SQLite) I wouldn't mind having a solution that translated to Go, or Go ASM, at build time.
Comments
Another really interesting way to approach this problem would be to adapt wasm2c to emit Go output. It should result in better performance than wazero.
You mean this? https://github.com/WebAssembly/wabt/blob/main/wasm2c/README....
That seems like quite an undertaking. But at that point, It would make sense to cut out WASM entirely like https://datastation.multiprocess.io/blog/2022-05-12-sqlite-i...
Disclosure: I'm working on alternative Cgo-less bindings for SQLite, using wazero.
https://github.com/ncruces/go-sqlite3
One of the problems of the modernc approach (IMO) is that they're not just transpiling CPU/compute stuff, but entirely OS/platform stuff.
Each Go file of theirs is a xxx_os_arch.go that starts with 100s of OS-#defines-as-consts, and goes on to transpile fully #ifdefed code.
It also implements antithetical (in Go) stuff like goroutine local storage, because libc pthreads can't live without it.
And all IO is via direct syscalls that will never play nice with the Go scheduler, because again, this is OS level stuff.
WASM defines a cross platform CPU and an ABI, and using that for compute and the bottom OS layer in Go you get (IMO) a nicer end result.
Given the hard task of generating decent code from WASM at load time (wazero's compiler is pretty naive, a better one is being developed, but it will take seconds to generate good code for anything non trivial like SQLite) I wouldn't mind having a solution that translated to Go, or Go ASM, at build time.