3 ms·
Nice article! I think this is an exciting approach to cross-platform support. I took a similar approach for Trealla Prolog's Go library: https://github.com/trea
by grose 4y ago
Nice article! I think this is an exciting approach to cross-platform support. I took a similar approach for Trealla Prolog's Go library: https://github.com/trealla-prolog/go https://github.com/trealla-prolog/go
The biggest roadblock at the moment is that Go WASM libraries are not in a very good state, except wazero. My assumption is that wazero will be slower than the cranelift-optimized wasmtime, etc. but I have not seen any benchmarks anywhere.
My impressions of the Go WASM libraries:
wazero: great Go-friendly API, not sure about performance, works on all OS (what the author chose)
wasmer: provides bare-minimum input and output for WASI, fast (it's what I chose for trealla-go). Doesn't work on Windows without significant pain, doesn't static compile the wasmer libraries so distribution is a pain. Seems essentially abandoned as its main contributor left the company.
wasmtime: basically impossible to get input and output in any reasonable way (unable to set stdin or read stdout; it can only inherit the FDs from the host), but might finally get buffers for I/O soon.
wasmedge: haven't investigated this yet, but it seems like it solves many of the problems above, promising
If anyone knows of a benchmark between these, I'd love to see it. I'm especially interested in wazero's execution speed. I think I'll try and run Trealla against it.
edit: I should also mention that wazero avoids the cgo overhead which could be a significant optimization for small functions as in this article, even if the runtime is slower. My use case is a long lived interpreter which is quite different.
- adrianfcole 4y ago(wazero contributor) thanks for the analysis. certainly dependency pain is something we hear about, as well as lack of maintenance on alternatives. Some don't release at all or rarely, and many break api constantly. We also break api, but then again we aren't 1.0 yet. wrt performance, we do watch it closely, but we've not done benchmarks vs non-default settings in other runtimes. It is the case that the tradeoff of avoiding dependencies means any optimizing JIT would have to be written to make long running things faster over time... no one has contributed this, yet, and more folks are looking at short lived despite it being the case interpreters are a great example of long lived. Concretely, we do keep track of relative performance (literally each commit in fact), and it isn't uncommon to find PRs including perf before/after. here are some pointers if interested in digging in! there are certainly some things we'd lose at. https://github.com/tetratelabs/wazero/actions/runs/3523069865/jobs/5906786822 https://github.com/tetratelabs/wazero/actions/runs/352306986... https://github.com/tetratelabs/wazero/tree/main/internal/integration_test/vs https://github.com/tetratelabs/wazero/tree/main/internal/int... https://github.com/tetratelabs/wazero/blob/main/Makefile#L32 https://github.com/tetratelabs/wazero/blob/main/Makefile#L32 Thanks for the analysis and good luck on things!
- ilyt 4y agoThanks for the comparison. I was looking to add plugin support for my toy project and having it just accept WASM binary seems like a way forward
- syrusakbary 4y agoHey, Syrus here from Wasmer. We just released Wasmer 3.0 with support for Windows. > doesn't static compile the wasmer libraries so distribution is a pain I'll chat with the team to see what we can do about this!
- grose 4y agoThank you Syrus, appreciate your work with Wasmer. Congrats on the 3.0 release and Windows support! I just fixed guregu/trealla on WAPM to work with the latest changes. I think WAPM is very cool and I hope more people start doing releases on it. These are the two issues I'm referring to: https://github.com/wasmerio/wasmer-go/pull/200 https://github.com/wasmerio/wasmer-go/pull/200 https://github.com/wasmerio/wasmer-go/pull/286 https://github.com/wasmerio/wasmer-go/pull/286