Wasmer 5.0 veröffentlicht

Neue experimentelle Backends

• Unterstützung für V8, Wasmi und WAMR wurde hinzugefügt
• Jetzt lässt sich jeder Interpreter oder jede Runtime, die die Wasm-C-API-Spezifikation unterstützt, einfach in Wasmer integrieren
• Durch die V8-Integration wird eine hervorragende Debugging-Erfahrung mit dem V8-Debugger und den Chrome Devtools geboten
• Die Nutzung von V8 als Backend bedeutet auch native Unterstützung für WebAssembly-Ausnahmen und Garbage Collection

iOS-Unterstützung (bereitgestellt über WAMR-, Wasmi- und V8-Bindings)

• Wasmer bringt WebAssembly mit einem neuen Interpreter-Modus auf iOS-Geräte
• Durch die Nutzung der Funktionen von V8, Wasmi und WebAssembly Micro Runtime (WAMR) können Entwickler nun WebAssembly-Module nahtlos unter iOS ausführen
• Es sind keine Änderungen an der Codebasis erforderlich, und es wird möglich, leistungsstarke Anwendungen im Apple-Ökosystem zu schreiben

Verschlankung der Codebasis

• Für die Veröffentlichung von Wasmer 5.0 lag der Fokus darauf, die Wasmer-Codebasis so schlank wie möglich zu machen
• Einige von Wasmer verwendete Abhängigkeiten wurden lange nicht gepflegt oder werden durch neuere und sicherere Crates ersetzt
• Da die Emscripten-Bindings in den letzten zwei Jahren größtenteils nicht genutzt wurden, wurde die Unterstützung eingestellt und Abhängigkeiten bereinigt, wodurch netto 20.000 Zeilen Code aus der Wasmer-Codebasis entfernt wurden

Leistungsverbesserungen

• Die Modul-Deserialisierung ist jetzt um bis zu 50 % schneller (also beim Aufruf von Module::deserialize oder beim Ausführen eines Moduls über wasmer run)
• Diese Verbesserungen nutzen ein wichtiges Update von rkyv, der Zero-Copy-Deserialisierungsbibliothek, die für die Modul-Deserialisierung verwendet wird

Aktualisierte Compiler: Cranelift und LLVM 18

• Durch die Integration des neuesten Cranelift wurde die Laufzeitgeschwindigkeit deutlich verbessert, sodass WebAssembly-Module schneller als je zuvor ausgeführt werden
• Wasmer 5.0 enthält jetzt die neueste Version von LLVM (18), wodurch Entwickler Zugriff auf die aktuellsten Optimierungen der Toolchain erhalten
• Das LLVM-Upgrade verbessert Kompatibilität und Leistung und schafft eine starke Grundlage für das Kompilieren und Ausführen komplexer WebAssembly-Module
• Wasmer 5.0 bringt außerdem experimentelle Unterstützung für LoongAarch64 mit
• Beim Benchmarking von coremark mit den neuesten Compilerversionen waren LLVM und Cranelift in Wasmer v5.0 etwa 8 % schneller als in v4.4.0

Meinung von GN⁺

• Die Veröffentlichung von Wasmer 5.0 scheint ein wichtiger Meilenstein für das WebAssembly-Ökosystem zu sein. Insbesondere die iOS-Unterstützung und die Bereitstellung verschiedener Backend-Optionen dürften den Einsatzbereich von WebAssembly deutlich bis hin zu mobilen Anwendungen erweitern
• Durch die Unterstützung verschiedener Runtimes wie V8, Wasmi und WAMR als Backends können Entwickler nun die Runtime wählen, die am besten zu ihren Anforderungen passt. Das dürfte wesentlich zur Flexibilität und Kompatibilität von WebAssembly beitragen
• Bemerkenswert sind auch die Bemühungen zur Leistungsoptimierung durch die Verschlankung der Codebasis und die Einführung aktueller Compiler. Das zeigt, dass Wasmer sich nicht nur auf neue Funktionen konzentriert, sondern auch kontinuierlich an der Qualitätsverbesserung arbeitet
• Andererseits ist das Ende der Unterstützung für Emscripten-Bindings bedauerlich, wirkt aber angesichts neuer Standards wie WASI und WASIX, die den Bedarf reduziert haben, wie eine nachvollziehbare Entscheidung
• Insgesamt ist Wasmer 5.0 eine Veröffentlichung, die den Fortschritt von WebAssembly gut zeigt, und es ist zu erwarten, dass Wasmer auch künftig eines der führenden Projekte im WebAssembly-Ökosystem bleiben wird. Allerdings scheinen weiterhin Anstrengungen nötig zu sein, um die Stabilität und Reife der noch experimentellen Funktionen zu erhöhen

[GN⁺]

Hacker-News-Kommentare

• Die Performance-Grafiken sind verwirrend und wirken wie verflucht. Teilweise werden sie auf einer logarithmischen Skala dargestellt, und in manchen Fällen ist schwer zu verstehen, was überhaupt ausgesagt werden soll. Zum Beispiel zeigt die Grafik „Argon 2“ fast alle Balken in derselben Länge, obwohl die einzelnen Balken in Millisekunden mit unterschiedlichen Zahlen beschriftet sind.
• Mit V8 als Backend wird Unterstützung für WebAssembly-Exception-Handling und Garbage Collection hinzugefügt. Ich freue mich auf weitere Neuigkeiten dazu. Ich frage mich, ob wasm-gc Host-Daten/Strings zwischen verschiedenen Modulen innerhalb derselben Runtime gemeinsam nutzen kann oder ob es auf ein einzelnes Modul beschränkt ist.
• Auf der Landingpage von Wasmer ist schwer zu verstehen, was das Produkt eigentlich macht. Es heißt, alles überall auszuführen, aber was konkret getan wird, bleibt unklar. Es wirkt wie ein entwicklerorientiertes Produkt, enthält aber mehr Buzzwords als technische Erklärungen.
• Ich bin mit Wasmtime zufrieden und bastle gerade am WASM-Component-Model und einem WASI-basierten Plugin-System. Macht Spaß, daran zu arbeiten.
• Ich habe noch keinen guten Anwendungsfall gefunden, um WASM in einem Projekt einzusetzen. Es ist ähnlich wie bei einem Raspberry Pi, bei dem man auch nicht weiß, wofür man ihn nutzen soll. Mir ist nicht klar, warum ich für ein asynchrones Rust-Projekt WASM wählen sollte.
• Ich wünschte, es gäbe eine Lösung, die keine Cross-Origin-Isolated-Header benötigt. Ich nutze immer noch die ältere Version.
• Ich frage mich, ob WASM als ressourcenschonendere Alternative für Electron-Apps funktionieren kann. WASM hat keinen DOM-Zugriff, aber ich frage mich, ob das durch Erweiterungen ergänzt werden könnte.
• Ich verstehe nicht, welches Problem diese Lösung eigentlich löst. Haben nicht alle JavaScript-Runtimes bereits eine WASM-Engine eingebaut?
• Ich frage mich, ob diese Lösung es ermöglicht, Node.js-Code sicher in einer Sandbox auszuwerten.
• Die Performance-Grafiken sind schwer zu lesen. Als Tausendertrennzeichen werden sowohl Kommas als auch Punkte verwendet, und die Genauigkeit wird willkürlich auf 1, 2 oder 3 Stellen gerundet.