v1.6.0
Hey, gophers! Do you know what time it is? It is that time of the year again! That time when we all gather together to share our time with friends and family to celebrate ANOTHER AWESOME WAZERO RELEASE!
Notably, this release includes the first public experimental release of the long-awaited, highly-requested multi-pass optimizing compiler! Keep reading for more details!
A huge thanks to all the contributors, old and new, and always remember that all the developers hang out at the Gophers Slack in the #wazero channel; and if you haven’t already you can star our repo. You know, Santa is making a list, and checking it twice.
It’s been a while since v1.5.0, but we promise v1.6.0 was worth the wait! Fun facts about v1.6.0:
- This is the best release since the last one.
- This release is 100% richer in holiday cheer. ❄️🎄
- Mulled wine is a fantastic developer productivity boost.
The Optimizing Compiler
Jokes aside, we have a lot to cheer about! The lion share of this release is obviously our brand new optimizing compiler (codename “wazevo”) now available as an experimental feature for arm64 (#1496)!
@mathetake led the design and implementation. Work started this summer, and it has evolved in a few iterations over the last months. Initial focus has been on general abstract infrastructure and support to the arm64 instruction set as our first compilation target. @evacchi contributed to the arm64 backend with special focus on the SIMD instructions, and @achille-roussel helped improve the initial register allocator (this was then further evolved and eventually overhauled again by @mathetake). @ncruces contributed with suggestions and testing.
We held off a few releases to polish this new compiler and gain more confidence in the implementation. In this first public release, the optimizing compiler is only available for arm64. The journey to supporting amd64 is set to begin soon with @evacchi leading the effort.
The new compiler has been, as usual, extensively tested against the Wasm spec, our own unit tests, and against the standard libraries of TinyGo, Go and Zig; and of course it has also been hardened through hours-long fuzzing.
You can enable the optimizing compiler by replacing wazero.NewRuntimeConfigCompiler() or wazero.NewRuntimeConfig() with the new experimental API as follows:
- c := wazero.NewRuntimeConfigCompiler()
+ c := opt.NewRuntimeConfigOptimizingCompiler()
- c := wazero.NewRuntimeConfig()
+ c := opt.NewRuntimeConfigOptimizingCompiler()The CLI is now also exposing an experimental flag -optimizing-compiler:
wazero run -optimizing-compiler myapp.wasm
The optimizing compiler is an experimental feature so we welcome your input. It is also a work in progress: we implemented only a few optimization passes, guiding our choices through testing and benchmarking.
It is worth noting that WebAssembly is an interesting beast: since it is a compilation target, most compilers generate pre-optimized output; therefore, some traditional optimization passes may surprisingly only add build-time overhead and produce no observable improvement. However, our work there is far from being done: more optimization passes can be added; we invite you to do your experiments and bring your own suggestions. For instance, among others, we currently implement forms of dead-code elimination, and bounds-checking eliminations.
In your experiments, you should also expect the CompileModule phase to take a while longer than the old compiler: the difference may be noticeable with large modules; but you can still cache the result, so you can pay this cost only once. The good news is that, in our tests, the run-time should always visibly improve. Interestingly enough, there are also some cases where both compile-time and run-time have improved: this might be the case when the input module is not pre-optimized, and the dead-code elimination procedures kick in.
For instance, the Zig standard library is about 2x quicker to compile and 4x faster to run than the old compiler. However, a pre-optimized test binary (e.g. pre-processed using Binaryen’s wasm-opt) will be much faster to build on the old compiler, but the new compiler will still produce 2x faster code. This is fully expected because the old compiler does a straightforward translation from input Wasm to native code: therefore, processing time tends to be low; but if the input is large, the generated output will be large. The new compiler is smarter, in that it is able to drop all the irrelevant code sections; in fact, processing time is about the same on both an optimized and unoptimized binary.
The bottom line is: if you control the Wasm binary, run it through wasm-opt and compare the result for your workload!
Deprecations
- @mathetake removed the Parameters API from StackIterator (#1716) as this feature hasn't been used in practice, and it is also difficult to implement in the optimizing compiler.
- @Danlock contributed (#1782) some deprecation warnings to
emscripten.Instantiateand related functions in favor ofemscripten.InstantiateForModule. Examples have been updated accordingly. This is also @Danlock’s first contribution! Cheers!
Other Contributions
Speaking of first-timers, let’s welcome them all:
- @Danlock’s contributed the
emscriptendeprecation warnings mentioned above. - @valpackett contributed performance and reliability improvements, solving a potential memory leak and a crash when caching is enabled (#1815, #1816).
- @yagehu contributed a few important fixes to our WASI implementation, especially regarding parameter types and error values (#1863, #1866, #1871).
Cheers to all of you! You are helping make wazero awesome!
Now onto the veterans!
- @anuraaga contributed a fix to our CI (#1711), but he is also continuing his work improving wazero on his friendly fork wazerox. Keep an eye on it for some bleeding edge features that might eventually end up upstream!
- @ncruces made sure that wazero builds successfully when GOOS=aix (#1723) for all you mainframe lovers
- Zig is now pinned to version 0.11 and we are testing against TinyGo 0.30 on CI (@mathetake, #1729 and #1745)
- golangci-lint has been updated to v1.55.2 for compatibility with the latest Go point release (@evacchi, #1879)
Finally, we also welcome to the community pages:
