Die zweite bedeutende Veröffentlichung des Wasmer-Projekts ist erfolgt, das eine Runtime für die Ausführung von WebAssembly-Modulen entwickelt. Diese Runtime ermöglicht die Erstellung universeller Anwendungen, die auf verschiedenen Betriebssystemen ausgeführt werden können, sowie die isolierte Ausführung von unsicherem Code. Der Code des Projekts wurde in der Programmiersprache Rust geschrieben und steht unter der MIT-Lizenz.
Die Portabilität wird durch die Kompilierung des Anwendungs Codes in niedrigstufigen WebAssembly-Zwischencode gewährleistet, der auf allen Betriebssystemen ausgeführt oder in Programme anderer Programmiersprachen integriert werden kann. Die Anwendungen bestehen aus leichten Containern, in denen Pseudocode von WebAssembly ausgeführt wird. Diese Container sind nicht an ein bestimmtes Betriebssystem gebunden und können Code enthalten, der ursprünglich in jeder Programmiersprache geschrieben wurde. Für die Kompilierung in WebAssembly kann das Emscripten-Toolkit verwendet werden. Zur Übersetzung von WebAssembly in den Maschinen Code der aktuellen Plattform wird die Verbindung zu verschiedenen Kompilierungs-Backends (Singlepass, Cranelift, LLVM) und -Engines unterstützt (einschließlich JIT-Nutzung oder Generierung von Maschinen Code).
Die Verwaltung des Zugriffs und die Interaktion mit dem System erfolgt über die API WASI (WebAssembly System Interface), die Schnittstellen für die Arbeit mit Dateien, Sockets und anderen von der Betriebssystem bereitgestellten Funktionen bereitstellt. Anwendungen sind von der Hauptsystem in einer Sandbox-Umgebung isoliert und haben nur Zugriff auf die angegebenen Funktionen (Sicherheitsmechanismus auf Basis von Capability Management – für Aktionen mit jedem der Ressourcen (Dateien, Verzeichnisse, Sockets, Systemaufrufe usw.) muss der Anwendung die entsprechenden Berechtigungen erteilt werden).
Um einen WebAssembly-Container zu starten, genügt es, das Runtime Wasmer im System zu installieren, das ohne externe Abhängigkeiten geliefert wird ("curl https://get.wasmer.io -sSfL | sh") , und die benötigte Datei auszuführen ("wasmer test.wasm"). Programme werden als reguläre WebAssembly-Module verteilt, die mit dem Paketmanager WAPM verwaltet werden können. Wasmer ist auch als Bibliothek erhältlich, die zur Integration von WebAssembly-Code in Programme in den Sprachen Rust, C/C++, C#, D, Python, JavaScript, Go, PHP, Ruby, Elixir und Java verwendet werden kann.
Die Plattform ermöglicht eine Anwendungsleistung, die nahezu der Ausführung nativer Builds entspricht. Mit der Native Object Engine für das WebAssembly-Modul kann maschineller Code generiert werden („wasmer compile —native“ zum Erzeugen vorcompilierter Objektdateien .so, .dylib und .dll), dessen Ausführung einen minimalen Runtime erfordert, dabei aber alle Möglichkeiten der Sandbox-Isolierung erhält. Die Bereitstellung von vorcompilierten Programmen mit integriertem Wasmer ist möglich. Rust API und Wasm-C-API stehen zur Verfügung, um Add-ons und Erweiterungen zu erstellen.
Die signifikante Versionsänderung von Wasmer ist auf inkompatible Änderungen im internen API zurückzuführen, die, so die Entwickler, keine Auswirkungen auf 99 % der Benutzer der Plattform haben werden. Zu den inkompatiblen Änderungen gehört auch die Anpassung des Formats der serialisierten Wasm-Module (Module, die in Wasmer 1.0 serialisiert wurden, können nicht in Wasmer 2.0 verwendet werden). Weitere Änderungen:
- Unterstützung von SIMD-Anweisungen (Single Instruction, Multiple Data), die eine Parallelisierung von Datenoperationen ermöglichen. Bereiche, in denen der Einsatz von SIMD die Leistung erheblich steigern kann, sind maschinelles Lernen, Video-Encoding und -Dekodierung, Bildverarbeitung, Simulation physikalischer Prozesse und Grafikmanipulation.
- Unterstützung von Referenztypen, die es Wasm-Modulen ermöglichen, auf Informationen in anderen Modulen oder der grundlegenden Umgebung zuzugreifen.
- Es wurde eine erhebliche Leistungsoptimierung durchgeführt. Die Geschwindigkeit des LLVM-Laufzeitumgebungen mit Fließkommazahlen wurde um etwa 50 % erhöht. Der Funktionsaufruf wurde durch die Reduzierung der Situationen, die einen Zugriff auf den Kern erfordern, deutlich beschleunigt. Die Leistung des Codegenerators Cranelift wurde um 40 % erhöht. Die Zeit für die Deserialisierung von Daten wurde verringert.
- Um die Essenz besser widerzuspiegeln, wurden die Namen der Engines geändert: JIT → Universal, Native → Dylib (Dynamische Bibliothek), Object File → StaticLib (Statische Bibliothek).
Quelle: opennet.ru
