🎅 Ho Ho Ho, WasmEdge 0.9.0 is here!

WasmEdge 0.9.0 is released just in time for the holidays. It is time for you to check out the bells and whistles, and unlock a new skill for 2022!

This release of WasmEdge is focused on performance, stability, and interoperability with cloud native infrastructure. Specifically, WasmEdge now supports

SIMD and other WebAssembly proposals

WasmEdge has supported the WebAssembly SIMD (Single instruction, multiple data) proposal since version 0.7.0. From WasmEdge 0.9.0, it has enabled SIMD by default.

For modern devices with multiple CPU cores, the SIMD allows data processing programs to utilize the CPUs fully. SIMD could greatly enhance the performance of data applications.

Besides the SIMD spec, WasmEdge 0.9.0 also added support for a number of WebAssembly proposals currently under consideration by the W3C, including the Import/Export mutable globals proposal, the Non-trapping float-to-int conversions proposal, the Sign-extension operators proposal, and the Multi-value proposal. Those proposed features are turned on by default in WasmEdge.

If you want to disable some of those features, you could use the --disable-proposal-name in wasmedge and wasmedgec.

Enhanced JavaScript support

There are compelling reasons to run JavaScript programs inside a WebAssembly runtime. WasmEdge could act as a secure application container that runs side by side with Linux application containers, but consumes a fraction of resources and provides better portability and security.

WasmEdge has always supported JavaScript applications. It also supports mixing JavaScript with high performance languages such as Rust. With the WasmEdge 0.9.0 release, we have enhanced JavaScript ecosystem support. WasmEdge now supports reusing ES6 modules, CommonJS (CJS) modules, and NPM modules. An example of running a React SSR JavaScript function is provided.

With continued enhancements to both the WasmEdge networking socket API and its JavaScript runtime, we aim to support complex use cases such as React SSR Streaming in the near future.

Improved performance

While WasmEdge is already one of the fastest WebAssembly runtimes available, we have also known that in some special cases, WasmEdge could under-perform. One of such cases was when running a JavaScript interpreter inside WasmEdge. Not any more! WasmEdge 0.9.0 has special optimization for the QuickJS interpreter engine, resulting in 20x performance gain in some cases.

Another performance-related change is that we made the runtime statistics metrics collection and reporting optional in WasmEdge 0.9.0. If you do want to see performance statistics of WasmEdge at runtime, you could use the following command line options.

Use --enable-time-measuring to show the execution time.
Use --enable-gas-measuring to show the amount of gas used.
Use --enable-instruction-count to display the number of executed instructions.
Or use --enable-all-statistics to enable all of the statistics options.

Improved C API

TheC API saw many changes and improvements in WasmEdge 0.9.0. We updated the host functions related APIs, the Wasm type contexts, and instances creation APIs. We renamed the Interpreter API and simplified WASI creation and initialization. We also refactored the C API’s internal implementation extensively to boost performance.

There are new features in the C API. There is a new WasmEdge C API for listing imports and exports from AST module contexts. Developers could get query WASI and AOT compiler related configurations.

For a detailed description of what's changed in the C API, please check out the changelog.

Universal wasm binary

Much of WasmEdge’s raw performance comes from its highly optimized AOT compiler. Developers could use the wasmedgec XYZ.wasm XYZ.so command or use SDKs to create a Linux native .so file from the AOT compiler. However, while the .so file is vastly more performant, it is not portable. Since 0.9.0, the WasmEdge AOT compiler tool wraps the native binary into a custom section in the origin wasm file. It allows the Wasm application to gracefully degrade from AOT compiled to interpreter execution on unsupported OSes or platforms. Developers could use wasmedgec XYZ.wasm XYZ.wasm to create a universal wasm binary.

With this feature, you could run the wasm file generated by WasmEdge AOT compiler in other wasm runtimes like a regular wasm file. But if you use WasmEdge to run the wasm file, WasmEdge will extract the native binary from the custom section and execute it.

Container and k8s tooling

Cloud-native WebAssembly applications could be managed by container tools, and runs side by side with Linux container applications in a k8s cluster. As one of the most popular OCI runtime projects, crun, adds built-in WasmEdge 0.9.0 support, the cloud-native WebAssembly vision has finally become a reality.

To learn how to leverage container tools such as Kubernetes, Docker, containerd and CRI-O to orchestrate, manage, and run lightweight WebAssembly applications, please refer to Manage WebAssembly Apps Using Container and Kubernetes Tools.

To learn more about WasmEdge 0.9.0, check out our changelog.

Finally, we want to acknowledge contributions from our community members, including @q82419, @ibmibmibm, @hydai, @SAtacker, @juntao, @LFsWang, @yanganto, @apepkuss, @alabulei1, @dm4, @0yi0, @nhynes, @eee4017, @LuiHsu, @avinal, @MileyFu, @O3OI, @vss96, @kenvifire, @ZhangHanDong, @CaptainVincent, @slidoooor, @robnanarivo, @Peter-Chang, @PsiACE, @spider0061, @Jayita10, @actly, @William-Mou, @L-jasmine, @chenyukang, @Yoname, @MaaKhan711635, @tpmccallum.

Join us in the WebAssembly revolution!

👉 Slack Channel: #wasmedge on CNCF slack channel

👉 Mailing list: Send an email to WasmEdge@googlegroups.com

👉 Twitter: @realwasmedge

👉 Be a contributor: checkout our wish list to start contributing!