WebAssembly: Runtime Wasmer 2.0 bringt der Community Reference-Typen und SIMD

Inhaltsverzeichnis

Erst vor einem halben Jahr hatte das Wasmer-Team die erste Hauptversion vollendet, nun präsentiert es bereits Version 2.0. Die Runtime für WebAssembly (Wasm) hat zahlreiche Neuerungen erhalten mit Blick auf Stabilität, Sicherheit und Performance. Hervorzuheben ist die Einführung der Reference-Typen und des SIMD-Konzepts (Single Instruction, Multiple Data) für die parallele Verarbeitung von Datenströmen. Letzteres soll für Wasm durch die nun mögliche Parallelisierung von Aufgaben eine deutliche Beschleunigung bei geringerem Ressourcenbedarf bringen.

Breaking Change bei der Serialisierung von Modulen

Entwicklerinnen und Entwickler dürfte es freuen, dass die APIs überwiegend gleich geblieben sind. Nur einige wenige Änderungen bei den internen Schnittstellen hat das Entwicklungsteam vorgenommen. Einen Breaking Change gilt es dennoch im Auge zu behalten: Wasm-Module, die man mit Wasmer 1.0 serialisiert hatte, lassen sich mit Wasmer 2.0 nicht mehr deserialisieren. Speziell die Einführung von SIMD (Single Instruction, Multiple Data) zeichnet die neue Hauptversion den Herausgebern zufolge aus. Dahinter verbirgt sich eine Methode der parallelen Verarbeitung von Daten zur Unterteilung von Rechnerarchitekturen gemäß der Anzahl vorhandener Befehls- und Datenströme. Im Bereich der Prozessoren sollen sich SIMD-fähige Geräte besonders gut für die Verarbeitung von Bild-, Ton- und Videodaten eignen, die sich in der Regel problemlos parallelisieren lassen, ist der Release-Meldung im Wasmer-Blog zu entnehmen.

Reference-Typen vereinfachen Interaktion mit Wasm-Modulen

Die neu eingeführten Reference Types ermöglichen es Wasm-Modulen, bestimmte Typen von Information mit Host-Umgebungen oder auch zwischen weiteren Wasm-Modulen zu referenzieren sowie zu teilen. Die Interaktion zwischen WebAssembly-Modulen soll dadurch weniger Code benötigen, einfacher von der Hand gehen und weist bereits auf künftige Neuerungen wie die laut Blogeintrag geplanten Interface-Typen voraus.

Die Herausgeber heben Performancesteigerungen hervor, so soll Wasmer 2.0 mit LLVM um etwa 50 Prozent beschleunigt laufen und die Deserialisierung sogar um etwa 70 Prozent schneller funktionieren. Wie eingangs erwähnt gibt es hier jedoch einen Wermutstropfen, da für Wasmer 1.0 erstellte Programme sich unter Wasmer 2.0 nicht mehr deserialisieren lassen und somit offenbar der Performancegewinn solchen Programmen vorbehalten bleiben wird, die mit der neuen Laufzeitumgebung kompatibel sind.

Umbenannte Engines

Eine kleinere, aber nicht unbedeutsame Änderung betrifft das "Housekeeping" des Projekts: So haben die Engines neue Namen erhalten. Aus JIT wird Universal, aus Native Dylib (als Akronym zu Dynamic Library) und Object File heißt ab sofort StaticLib (von StaticLibrary). Hintergrund ist laut Wasmer-Team, dass die vorherigen Bezeichnungen unter der Haube für Verwirrung gesorgt hätten, die neuen Engine-Namen sollen nun Klarheit schaffen.

Ausblick und weiterführende Hinweise

Einen Ausblick auf kommende Neuerungen gibt es ebenfalls – so teilt das Entwicklungsteam mit, dass die Projekt-Roadmap unter anderem weitere Implementierungen der Reference-Typen und zusätzlichen Support für mehr Betriebssysteme und Hardware-Infrastrukturen vorsieht.

Wasmer 2.0 steht auf GitHub zum Download bereit und lässt sich am einfachsten mit dem Befehl curl https://get.wasmer.io -sSfL | sh installieren. Weitere Hinweise zum Release finden sich im Blogeintrag des Wasmer-Teams. Wem das Open-Source-Projekt zusagt, der kann es als Nutzer, Entwickler oder Sponsor unterstützen. Wer mag, kann auch einen vergleichenden Blick zurück auf das ebenfalls noch frische Wasmer 1.0 werfen.

(sih)