4 ms·

Shameless plug… compiling it to Go is a great option too: https://github.com/ncruces/wasm2go https://github.com/ncruces/wasm2go I've used it to translate SQLit

by ncruces 6mo ago

Shameless plug… compiling it to Go is a great option too: https://github.com/ncruces/wasm2go https://github.com/ncruces/wasm2go I've used it to translate SQLite (with a few extensions) and, that I know of, it's been used (to varying degrees of success) to translate the MARISA trie library (C++), libghostty (Zig), zlib, Perl, and QuickJS. More on-topic, I use a mix of an unevaluated expression stack and a stack-to-locals approach to translate Wasm.

lukevp 6mo ago
Does that mean you could compile a wasm program to go, then run it with wazero? How many levels deep can it go?? Might be a fun blog topic :)
- ncruces 5mo ago
  Not very deep. Go generates large Wasm modules, because it bundles its goroutine scheduler, garbage collector and standard library into the module. Translating that back to Go will give you a pretty big Go file. Go is "known" for being fast to compile, but that huge Go file will take (at least?) as long to compile as compiling the Go toolchain does. wasm2go is best used on moderately sized modules (like SQLite). Last I heard, the person who tried to translate Perl got a 80MB Go file that was taking them 20min to compile. https://github.com/ncruces/wasm2go/discussions/15 https://github.com/ncruces/wasm2go/discussions/15
nu11ptr 6mo ago
Interesting. I started working on this same idea a couple of years ago as a way to bypass CGo. Eventually I moved on to something else. Glad someone else is working on this. How does the generated Go performance compare to the original WASM performance?
- ncruces 6mo ago
  That's going to depend on what you mean for "original Wasm performance". What were you using to run Wasm instead of this? I can compare with wazero, which I was previously using, and say performance stayed mostly in the same ballpark. Things that crossed the Go-to-Wasm boundary very often became much faster, things that stayed mostly in Wasm became slightly slower, as the wazero compiler is pretty good. wasm2go also does not support SIMD, so if your Wasm module uses/benefits from SIMD, you'll notice.

by ncruces 6mo ago

lukevp 6mo ago

Does that mean you could compile a wasm program to go, then run it with wazero? How many levels deep can it go?? Might be a fun blog topic :)

ncruces 5mo ago
Not very deep. Go generates large Wasm modules, because it bundles its goroutine scheduler, garbage collector and standard library into the module. Translating that back to Go will give you a pretty big Go file. Go is "known" for being fast to compile, but that huge Go file will take (at least?) as long to compile as compiling the Go toolchain does. wasm2go is best used on moderately sized modules (like SQLite). Last I heard, the person who tried to translate Perl got a 80MB Go file that was taking them 20min to compile. https://github.com/ncruces/wasm2go/discussions/15 https://github.com/ncruces/wasm2go/discussions/15

nu11ptr 6mo ago

Interesting. I started working on this same idea a couple of years ago as a way to bypass CGo. Eventually I moved on to something else. Glad someone else is working on this. How does the generated Go performance compare to the original WASM performance?

ncruces 6mo ago
That's going to depend on what you mean for "original Wasm performance". What were you using to run Wasm instead of this? I can compare with wazero, which I was previously using, and say performance stayed mostly in the same ballpark. Things that crossed the Go-to-Wasm boundary very often became much faster, things that stayed mostly in Wasm became slightly slower, as the wazero compiler is pretty good. wasm2go also does not support SIMD, so if your Wasm module uses/benefits from SIMD, you'll notice.