WebAssembly: Runtime Wasmer 2.0 brings the Community Reference Types and SIMD

Published by: MRT

Published on:

WebAssembly: Runtime Wasmer 2.0 brings the Community Reference Types and SIMD

The Wasmer team had only completed the first main version six months ago, and now it is already presenting version 2.0. The runtime for WebAssembly (Wasm) has received numerous innovations with a view to stability, security and performance. The introduction of the reference types and the SIMD concept (Single Instruction, Multiple Data) for the parallel processing of data streams should be emphasized. The latter should bring a significant acceleration for Wasm through the now possible parallelization of tasks with lower resource requirements.

Developers should be pleased that the APIs have largely remained the same. The development team only made a few changes to the internal interfaces. However, there is a breaking change to keep in mind: Wasm modules that were serialized with Wasmer 1.0 can no longer be deserialized with Wasmer 2.0. According to the editors, the new main version is particularly characterized by the introduction of SIMD (Single Instruction, Multiple Data). This is a method of parallel processing of data to subdivide computer architectures according to the number of existing command and data streams. In the area of ​​processors, SIMD-capable devices should be particularly suitable for processing image, sound and video data, which can usually be parallelized without any problems, according to the release message in the Wasmer blog.

The newly introduced reference types enable Wasm modules to reference and share certain types of information with host environments or between other Wasm modules. The interaction between WebAssembly modules should therefore require less code, be easier to handle and already indicate future innovations such as the interface types planned according to the blog entry.

The editors highlight performance increases, for example Wasmer 2.0 with LLVM should run around 50 percent faster and deserialization should even work around 70 percent faster. As mentioned at the beginning, there is a downer, however, since programs created for Wasmer 1.0 can no longer be deserialized under Wasmer 2.0 and thus the performance gain will obviously be reserved for programs that are compatible with the new runtime environment.

A minor, but not insignificant change affects the “housekeeping” of the project: The engines have been given new names. JIT becomes Universal, Native Dylib (as an acronym for Dynamic Library) and Object File is now called StaticLib (from StaticLibrary). According to the Wasmer team, the background is that the previous names under the hood had caused confusion, the new engine names should now provide clarity.

There is also a preview of upcoming innovations – the development team announced that the project roadmap includes further implementations of the reference types and additional support for more operating systems and hardware infrastructures.

Wasmer 2.0 is on GitHub The easiest way to download it is to use the command curl https://get.wasmer.io -sSfL | sh to install. Further information on the release can be found in the blog entry of the Wasmer team. Anyone who likes the open source project can do it support as a user, developer or sponsor. If you like, you can also take a comparative look back at the still fresh Wasmer 1.0.


(yeah)

Disclaimer: This article is generated from the feed and not edited by our team.