Die zweite bedeutende Version des Wasmer-Projekts, das ein Runtime für die Ausführung von WebAssembly-Modulen entwickelt, die zur Erstellung universeller Anwendungen verwendet werden können, die auf verschiedenen Betriebssystemen laufen, sowie zur isolierten Ausführung von nicht vertrauenswürdigem Code, ist erschienen. Der Code des Projekts ist in Rust geschrieben und steht unter der MIT-Lizenz.
Die Portabilität wird durch die Kompilierung des Anwendungs-Codes in einen niedrigstufigen WebAssembly-Intermediate-Code gewährleistet, der in allen Betriebssystemen ausgeführt oder in Programme in anderen Programmiersprachen eingebettet werden kann. Die Programme sind leichtgewichtige Container, in denen der Pseudocode von WebAssembly ausgeführt wird. Diese Container sind nicht an ein 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. Für die Übersetzung von WebAssembly in Maschinen-Code der aktuellen Plattform wird die Unterstützung verschiedener Backend-Kompilierungen (Singlepass, Cranelift, LLVM) und Engines (Einsatz von JIT oder Generierung von Maschinen-Code) gewährleistet.
Der Zugriff und die Interaktion mit dem System erfolgt über die WASI (WebAssembly System Interface)-API, die Software-Schnittstellen für die Arbeit mit Dateien, Sockets und anderen Funktionen bereitstellt, die vom Betriebssystem bereitgestellt werden. Die Anwendungen sind von der Hauptanlage in einer Sandbox-Umgebung isoliert und haben nur Zugriff auf die deklarierte Funktionalität (ein Sicherheitsmechanismus auf der Grundlage einer Berechtigungsverwaltung — für Aktionen mit jedem der Ressourcen (Dateien, Verzeichnisse, Sockets, Systemaufrufe usw.) müssen der Anwendung die entsprechenden Befugnisse erteilt werden).
Um einen WebAssembly-Container auszuführen, genügt es, das Wasmer-Runtime auf dem System zu installieren, das ohne externe Abhängigkeiten geliefert wird („curl https://get.wasmer.io -sSfL | sh“), und die erforderliche Datei auszuführen („wasmer test.wasm“). Programme werden in Form gewöhnlicher WebAssembly-Module verbreitet, deren Verwaltung über den Paketmanager WAPM erfolgen kann. Wasmer ist auch als Bibliothek verfügbar, die zur Einbindung 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 Ausführungsgeschwindigkeit von Anwendungen, die der von nativen Builds nahekommt. Mithilfe des Native Object Engine für das WebAssembly-Modul kann maschinenlesbarer Code generiert werden („wasmer compile —native“ zur Erstellung vorkompilierter Objektdateien .so, .dylib und .dll), für dessen Ausführung ein minimaler Runtime erforderlich ist, jedoch werden alle Möglichkeiten der Sandbox-Isolierung beibehalten. Es können vorkompilierte Programme mit integriertem Wasmer bereitgestellt werden. Für die Erstellung von Erweiterungen und Ergänzungen stehen Rust API und Wasm-C-API zur Verfügung.
Der signifikante Versionswechsel von Wasmer ist auf nicht abwärtskompatible Änderungen des internen APIs zurückzuführen, die, so die Entwickler, keine Auswirkungen auf 99 % der Nutzer der Plattform haben werden. Zu den nicht abwärtskompatiblen Änderungen gehört auch die Änderung des Formats der serialisierten Wasm-Module (Module, die in Wasmer 1.0 serialisiert wurden, können in Wasmer 2.0 nicht verwendet werden). Weitere Änderungen:
- Unterstützung von SIMD-Instruktionen (Single Instruction, Multiple Data), die die Parallelisierung von Datenoperationen ermöglichen. Zu den Bereichen, in denen SIMD die Leistung erheblich steigern kann, gehören maschinelles Lernen, Video- und Audiocodierung und -decodierung, Bildverarbeitung, Simulation physikalischer Prozesse und Grafikmanipulation.
- Unterstützung von Referenztypen, die es Wasm-Modulen ermöglichen, auf Informationen in anderen Modulen oder in der zugrunde liegenden Umgebung zuzugreifen.
- Es wurde eine erhebliche Leistungsoptimierung vorgenommen. Die Geschwindigkeit der LLVM-Runtime bei Gleitkommazahlen wurde um etwa 50 % erhöht. Der Funktionsaufruf wurde erheblich beschleunigt, indem Situationen, die einen Zugriff auf den Kernel erforderten, reduziert wurden. Die Leistung des Cranelift-Codegenerators wurde um 40 % gesteigert. Die Zeit für die Deserialisierung von Daten wurde verkürzt.
- Um die Essenz genauer abzubilden, wurden die Bezeichnungen der Engines geändert: JIT → Universal, Native → Dylib (Dynamic Library), Object File → StaticLib (Static Library).
Quelle: opennet.ru
