© zstockphotos, 123RF

Das Webassembly-Projekt zimmert ein portables Binärformat für Browser mit Fokus auf Größe und Ladezeit. Als Quelle dienen unter anderem C- und C++-Programme, was es ermöglicht, nahezu beliebige Applikationen für das Web zu übersetzen. Die schlüsselfertigen Produkte sind dabei effizient konstruiert.

Applikationen in den Browser zu verlagern ist wahrlich keine neue Erfindung. Mit Webassembly [2] kündigt sich jedoch ein Format an, das den Desktop und das Web intelligent miteinander verbindet. Eine tragende Rolle spielt dabei das Emscripten-SDK [3]. Es bietet einen LLVM-basierten Compiler [4] an, der C- und C++-Programme in handelsübliches Javascript übersetzt. Diese Möglichkeit soll eine aufwändige Portierung überflüssig machen und so eine einfache Brücke ins Web bauen.

Abbildung 1 verdeutlicht den Zusammenhang zwischen den beteiligten Tools und Toolchains. Sie zeigt auch, dass sich Webassembly nicht auf Anwendungen im Browser beschränkt, sondern auch lokal ausgeführte Programme unterstützt.

Abbildung 1: Verschiedene Tools und Toolchains helfen beim Übersetzen von C und C++ nach Webassembly.

Asm trifft Wasm

Ursprünglich hatten die Emscripten-Entwickler Asm.js [5] als Zielobjekt im Auge. Inzwischen kommt das SDK auch für Webassembly zum Einsatz. Asm.js und Webassembly verfolgen durchaus ähnliche Ideen und Ziele. Einige der Entwickler haben bei beiden Projekten ihre Finger im Spiel. Dennoch hebt sich das Design von Asm.js deutlich von dem von Webassembly ab.

Asm.js will ein formal festgelegtes Subset von Javascript definieren, das ein Compiler wie Emcc [4] von Emscripten dann erzeugt. Die Einschränkung im Sprachumfang erlaubt es, Optimierungen wie Type-Checks und Array-Handling zu garantieren. Das verbessert die Laufzeit gegenüber händisch implementiertem Javascript-Code. Ein weiterer Vorteil von Asm.js: Fast alle Browser interpretieren Javascript. Entwickler brauchen für den Code keine neue virtuelle Maschine, alle nötigen Erweiterungen lassen sich in existierende Javascript-Engines (etwa in Googles V8) einbauen.

Auch Webassembly soll nativen Code im Browser ausführen, geht aber noch einen Schritt weiter, denn es bezieht auch Anwendungen außerhalb des Browsers mit ein. Die Unterschiede manifestieren sich unter anderem in der eingesetzten Sprache. Während Asm.js immer Javascript-Code erzeugt, kompiliert Webassembly C- und C++-Programme in ein eigenes Binärformat (Wasm). Dabei kann Javascript mit im Spiel sein, muss aber nicht, wenn der Code nicht im Browser laufen soll.

Die weiter unten erwähnten Benchmarks zeigen, dass das neue Binärformat effizienter läuft als der Asm.js-optimierte Javascript-Code. Auch laden es (Browser-)Anwendungen schneller. Einige weitere Gründe, die für Webassembly sprechen, und Informationen zu den Unterschieden zu Asm.js liefert [6].

Übersetzungswunder

In der Regel dauert es nicht nur länger, wenn Entwickler ihre C- und C++-Programme selbst nach Javascript portieren, Emscripten erzeugt auch gleich optimierten Javascript-Code, den Browser effizient ausführen. Weil es LLVM als Grundlage verwendet, besteht auch die Möglichkeit, nicht nur C- und C++-Programme zu kompilieren, sondern beliebigen Code, solange er sich zuvor in LLVM-Bitcode übersetzen lässt [7]. Die Dokumentation [8] zählt noch weitere Vorteile auf, die das Projekt für Webassembly beansprucht:

• Webassembly definiert eine eigene Sandbox pro Modul, also einen eigenen Speicherbereich, den es nicht mit anderen Modulen teilt.
• Als Modul im Browser kann Webassembly mit Javascript interagieren und Funktionen des Browsers über ein Javascript-API nutzen. In der Folge nutzen Webassembly und Javascript bestimmten Code gemeinsam.
• Wie schon angedeutet, laufen Webassembly-Module nicht nur im Browser, sondern lassen sich auch außerhalb als nativer Code einsetzen.

Stand der Dinge

Webassembly ist keine Luftnummer, die nur auf dem Papier existiert. Die Webseite bietet eine Demo [9] an. Laut Roadmap [10] arbeiten Entwickler von vier Browserherstellern (Firefox, Chrome, Edge und Webkit) am Projekt mit, das die W3C Community Group zudem als offenen Standard entwickelt [11], unabhängig von einzelnen Herstellern. Seit Kurzem gibt es zudem ein MVP, ein Minimum Viable Product, also eine Art Basisprodukt. Einige Features befinden sich zwar noch in der Designphase, aber alle wichtigen Designentscheidungen über das Webassembly-API und das Binärformat sind getroffen, implementiert und lassen sich testen [12].

Apropos Test

Wer Programme ins Webassembly-Format übersetzen möchte, braucht zunächst einen Compiler. Anstelle von GCC und G++ kommt das erwähnte Emcc [3] zum Einsatz, der Compiler aus der Emscripten-Toolchain. Ihn checken Entwickler zusammen mit dem Emscripten-SDK aus Git aus und installieren die Software gemäß Anleitung [13]. Da das Projekt anfangs nur Asm.js unterstützte, müssen sie Emccs Linker über die Kommandozeile die Flag »-s WASM=1« mitgeben, um Wasm-Binärcode zu erzeugen. Die Standard-Endung für Webassembly-Programme lautet »wasm«. Der Aufruf

emcc hello.c -s WASM=1 -o hello.html

übersetzt zum Beispiel das Hello-World-Programm aus Listing 1. Mit diesen Argumenten aufgerufen, erzeugt Emcc drei Dateien: »hello.wasm«, »hello.js« und »hello.html«. Die Wasm- und Javascript-Dateien enthalten den Webassembly-Binärcode sowie das Webassembly-Javascript-Modul, wobei Emcc die HTML-Datei nur generiert, wenn das Argument zur Option »-o« mit ».html« endet. Mit der so angefertigten HTML-Seite testet der Entwickler das Webassembly-Modul im Browser. Abbildung 2 zeigt das (schlichte) Ergebnis.

01 #include <stdio.h>
02
03 int main()
04 {
05         printf("Hello, world\n");
06
07         return 0;
08 }

Abbildung 2: Bei Bedarf generiert Emcc eine HTML-Seite für den Browser, der hier die Ausgabe des aus C übersetzten Programms “Hello World” anzeigt.

Zum Hosten solcher HTML-Seiten bringt das SDK gleich ein eigenes Tool mit: Emrun [14]. Es stellt einen simplen HTTP-Server bereit, der mit Hilfe des Kommandos »emrun –no_browser –port 8080 .« alle Dateien im aktuellen Verzeichnis via HTTP serviert.

Abbildung 3 zeigt ein weiteres Beispiel. Es verwendet »scanf()«, um Benutzereingaben abzufragen. Das zugehörige Listing wartet unter [1].

Abbildung 3: Das Dialogfeld zur Benutzereingabe erzeugt eine »scanf()«-Anweisung im C-Programm.

Die Liste an Projekten, die Emscripten bereits erfolgreich übersetzt und für Browser verfügbar gemacht hat, ist umfangreich [15]: Von Spielen mit Grafik-Rendering und Audio-Ausgabe über Frameworks wie Qt oder Unity bis hin zu C- und C++-Laufzeitumgebungen für Lua und Python, die den indirekten Python-Einsatz im Browser ermöglichen. Neben den Standardbibliotheken von C und C++ kommt Emscripten auch mit SDL- und Open-GL-Bibliotheken zurecht, was zusätzliche Bibliotheken für den übersetzten Webassembly- und Javascript-Code überflüssig macht.

Zwar verwandelt Emscripten fast jeden nativen C- und C++-Code in Javascript, doch die Runtime unterscheidet sich in einigen Punkten von ihren nativen Geschwistern. Sie erfordert vereinzelt Anpassungen am Code, bevor sie ihn übersetzt. Diese beschränken sich jedoch in der Regel auf die »main()«-Loop und Zugriffe auf das Dateisystem.

Schleifen lassen

Normalerweise laufen grafische C++-Anwendungen in einer Endlosschleife. Sie reagieren bei jedem Schleifendurchlauf auf Events und verarbeiten sie. Zugleich erfolgt das Rendering und ist eine Wartezeit eingebaut, um etwa die Bildrate (FPS) konstant zu halten.

Für Browser eignet sich dieses Verhalten weniger. Die Endlosschleife macht es unmöglich, die Kontrolle an den Browser zurückzugeben. Das Emscripten-SDK stellt daher für C++-Code eine Funktion bereit, um die »main()«-Schleife für den Einsatz in Javascript aufzubereiten. Die garantiert, dass die Webseite nicht in einer Endlosschleife hängen bleibt. Mehr dazu verrät die Emscripten-API-Referenz [16] und dort besonders die Passage zur Funktion »emscripten_set_main_loop()«.

Passende Dateisysteme

Native Programmiersprachen nutzen häufig direkten, synchronen Zugriff auf das Dateisystem. Browser greifen hingegen nicht direkt auf das Dateisystem zu, zudem führt Javascript Datei-Operationen üblicherweise asynchron aus. Emscripten bringt daher ein virtuelles Dateisystem, mit dem Browser native Anwendungen ohne große Änderungen ausführen. Anwendungen, die synchrone Dateizugriffe verwenden, greifen über ein Filesystem-API auf das virtuelle Dateisystem zu (Abbildung 4).

Abbildung 4: Emscripten stellt Dateisysteme im RAM bereit, die sich auch für synchrone Zugriffe eignen.

Standardmäßig setzt Emscripten hierbei auf Mem-FS [17], ein Dateisystem, das im Arbeitsspeicher residiert und das Emscripten bei Bedarf (wenn Code Datei-Operationen anfordert) automatisch nach »/« mountet. Benutzer von Mem-FS holen über Emcc Dateien und Verzeichnisse in das Dateisystem, die später beim Ausführen des Programms im Browser bereitstehen.

Eine Webseite mit Zugriff auf Mem-FS lädt die Dateien beim Laden über Javascript und erlaubt synchrone Dateizugriffe erst, wenn das komplette Dateisystem im Speicher zur Verfügung steht. Da Mem-FS nur im Speicher existiert, gehen Schreibzugriffe beim Neuladen der Webseite verloren.

Listing 2 zeigt ein simples C-Programm, das eine Datei »passwd« aus dem aktuellen Verzeichnis liest und den ersten Eintrag jeder Zeile ausgibt. Mem-FS muss die erforderliche Textdatei beim Übersetzen anbieten. Emcc bringt dafür zwei Möglichkeiten mit, die Optionen »preload-file« und »embed-file«.

01 #include <stdio.h>
02 #include <string.h>
03
04 int main()
05 {
06         FILE *fp;
07         char buf[200], *tok;
08
09         fp = fopen("./passwd", "r");
10         if (fp == NULL) {
11                 printf("Cannot open file\n");
12                 return 1;
13         }
14
15         while (fgets(buf, 200, fp) != NULL) {
16                 tok = strtok(buf, ":");
17                 if (tok == NULL) {
18                         continue;
19                 }
20
21                 printf("%s ", tok);
22         }
23
24         fclose(fp);
25         return 0;
26 }

Während »preload-file« Javascript instruiert, die übergebenen Dateien beim Aufruf der Webseite zu laden, integriert »embed-file« die Dateien direkt in die produzierte Javascript-Datei. Ruft der Entwickler Emcc nun mittels

emcc vfs.c -s WASM=1 -o vfs.html  --preload-file passwd

auf, erzeugt der Compiler zusätzlich zu den Wasm-, Javascript- und HTML-Dateien auch eine Datei namens »vfs.data«, in der die übergebene Datei steckt. Auf diese greift das Programm dann beim Ausführen zu.

Um Daten auch zu speichern, stellt Emscripten je nach Anwendungsfall zwei Mem-FS-Alternativen bereit: Node-FS [18] und IDB-FS [19]. Ersteres kommt nur dann zum Einsatz, wenn die Anwendung innerhalb einer Node.js-Umgebung läuft. Dank Node-FS greifen Anwendungen dann über das Node.js-API auf das gesamte lokale Dateisystem zu. Soll die Browseranwendung persistente Dateien schreiben, bietet IDB-FS eine synchronisierte Index-DB an.

Weitere Einschränkungen zur Portierbarkeit beschreibt [20], sie umfassen vor allem das Multithreading von Anwendungen und Programmen, das Low-Level-Hardware-Features und native Assembler-Anweisungen involviert.

Chain of Tools

Während Emscripten eine generische Toolchain bereitstellt, die auch Asm.js-Code erzeugt, hat Webassembly auch eigene Tools im Gepäck, um direkt Wasm-Dateien zu lesen und zu bearbeiten. Dabei existieren zwei Sets von Tools, das Webassembly Binary Toolkit (WABT, [21]) und Binaryen [22].

WABT stellt Tools bereit, die beim Übersetzen zwischen dem Binär- und Textformat von Webassembly helfen, zudem eine »objdump«-Version für Wasm-Dateien sowie einen Wasm-Interpreter. Binaryen bietet hingegen primär eine Bibliothek an, um das Kompilieren von Code in das Webassembly-Format innerhalb anderer Toolchains zu erleichtern. Es bringt aber auch einige weitere Hilfsmittel mit, um zwischen dem Binär- und Textformat von Webassembly und zwischen Asm.js und Wasm zu konvertieren, sowie einen Wasm-Interpreter. Nicht zuletzt verfügt Binaryen über eine Javascript-Bibliothek der bereitgestellten Werkzeuge.

Queue, Module, Layer

Die Projektseite beschreibt Webassembly als ein “neues, portables, auf Größe und Laufzeit optimiertes Format, lauffähig im Browser”. Die Features ergeben sich aufgrund einiger Designentscheidungen, die im Folgenden eine Rolle spielen.

Webassembly erzeugt Code als Stack Machine, die eine LIFO-Queue verwendet, um einzelne Instruktionen abzuarbeiten. Die Anweisungen in Webassembly, das den Programmablauf als Folge von Blöcken betrachtet, verwenden diesen Wertestack. Die Blöcke bestehen zum Beispiel aus If-Bedingungen und For-Schleifen. Diese formale Definition erlaubt es, den resultierenden Code effizient als Binärrepräsentation zu behandeln, während Asm.js ein Javascript-Subset als Ausgabeformat verwendet.

Das Binärformat lässt es zu, den übersetzten Code schneller zu speichern und im Vergleich zur Quellcode-Interpretation auch schneller zu prozessieren. Verglichen mit reinem Javascript-Code gibt es zudem mehr Möglichkeiten, den Code zu optimieren.

Die Javascript-Engine verwaltet den Speicherbereich, der einer Webassembly-Instanz (Modul) zur Verfügung steht. Jedes Modul läuft in einer eigenen Sandbox und hat somit keine Möglichkeit, nicht zugängliche Adressbereiche zu manipulieren. Während das MVP nur diese Möglichkeit bereitstellt, wollen die Entwickler künftig mehr Wege zu Speicherverwaltung und -Einsatz anbieten. So sollen mehrere Threads einen Speicherbereich gemeinsam verwenden.

Das von Webassembly definierte Binärformat sieht ein Encoding in drei Schichten vor. Layer 0 kodiert in einer simplen binären Form die Bytecode-Instruktionen sowie die dazugehörigen Datenstrukturen. Die Kodierung eignet sich für einfache Interaktionen und damit für JiT-Szenarios, Instrumentierungs-Tools und Debugging.

Layer 1 baut auf Layer 0 auf und nutzt spezifisches Wissen über die Art des Syntax-Trees und seiner Nodes, um eine strukturelle Kompression aufzubauen. Letztere erlaubt ein effizienteres Kodieren von Werten, ordnet Werte im Modul neu an und reduziert strukturell ähnliche Tree-Nodes. Layer 2 wendet schließlich bekannte Kompressionsalgorithmen an, etwa Gzip und Brotli, die bereits in Browsern zur Verfügung stehen. Kurzum: Die Schichten 1 und 2 sorgen für kleinere Dateigrößen, schnellere Ladezeiten und einen effizienteren Einsatz existierender Technologien.

Neben dem Binärformat definiert Webassembly auch ein Textformat, das sich für Tests und Debugging eignet, in dem Entwickler aber auf Wunsch auch direkt programmieren. Das macht es unter anderem möglich, den Quellcode eines Webassembly-Moduls, das im Browser läuft, anzuzeigen. Dieses Feature ist in Browsern bereits allgegenwärtig und lässt sich zum Beispiel über die Javascript-Console nutzen.

Als Syntax verwendet das Webassembly Text Format (Wat, [23]), so genannte S-Expressions, die hauptsächlich aus Listen und Klammern bestehen. Dieses Format kommt unter anderem bei Programmiersprachen wie Lisp zum Einsatz.

Wasm Explorer

Mozilla entwickelt zurzeit den Wasm Explorer [24]. Er bietet die Möglichkeit, C- und C++-Code im Browser zu schreiben und direkt in Webassembly zu verwandeln (Abbildung 6). Dadurch sehen und analysieren Entwickler den eigenen Code im Textformat, laden aber zugleich den daraus resultierenden Webassembly-Code im Text- oder Binärformat herunter.

Abbildung 6: Der Wasm Explorer erlaubt es, reinen C- und C++-Code direkt ins Webassembly-Format zu übersetzen.

Höchst effizient

Wie erwähnt soll Webassembly nicht nur in, sondern auch außerhalb von Browserumgebungen laufen. Das geschieht aktuell mittels Node.js, soll jedoch in Zukunft unabhängig von einer Javascript-Engine als Stand-alone-Modul klappen. Als Browser-Modul ist Webassembly Teil der Open Web Platform [25], daher stehen alle Features zur Verfügung, die bereits Teil des Web-API von Javascript sind. Webassembly versteht sich dabei keinesfalls als Ersatz für Javascript in Browser-Umgebungen, sondern will es ergänzen und die Möglichkeit bieten, weitere Features und Anwendungen in den Browser zu portieren.

Laut Entwurf stellt das Binärformat eine möglichst effiziente Ausführung sicher, und zwar unabhängig von Betriebssystem und Architektur. Dabei setzt es einige Features der zugrunde liegenden Hardware und des Betriebssystems voraus. Bietet die Javascript-Engine diese Features jedoch nicht an, kann sie den Webassembly-Code dennoch ausführen. Sie muss in diesem Fall das erwünschte Verhalten emulieren, was die Ausführungsgeschwindigkeit einschränken kann.

APIs und Syscall

Darüber hinaus definiert Webassembly jedoch keine APIs oder Systemaufrufe oder setzt solche voraus. Vielmehr entscheidet die zugrunde liegende Plattform darüber, welche APIs bereitstehen und wie diese implementiert sind, seien es Web-APIs im Browser oder Posix in nativen Umgebungen.

Auf dem Source-Code-Level bereitet die Emscripten-Toolchain die API-Aufrufe für die entsprechenden Schnittstellen der verwendeten Maschine auf. Dies kann beim Übersetzen oder dynamisch zur Laufzeit passieren.

Javascript-API

In Zukunft sollen Browser Webassembly-Module über ein eigenes HTML-Attribut (»<script type=”module”>«) automatisch laden. Im Moment klappt das noch nicht, daher gibt es zwei Möglichkeiten: Setzt der Entwickler auf Emcc, erzeugt der Compiler neben der Wasm-Binärdatei auch eine Javascript-Datei, die das Webassembly-Modul bereitstellt, den Wasm-Code lädt und die der HTML-Code über »<script src=”mymodule.js”>« einbindet.

Wer hingegen das Wasm-Modul in der Textrepräsentation selbst erzeugt hat oder den von Emcc generierten Javascript-Code nicht verwenden möchte, muss den Webassembly-Code (die Wasm-Datei) per Javascript händisch in einen Buffer laden, kompilieren und instanzieren, was das Beispiel aus den Listings 3 und 4 demonstriert.

Listing 3 zeigt auszugsweise ein in S-Expressions implementiertes Programm, das die Fakultät einer übergebenen Zahl berechnet. Wer das nicht händisch abtippen möchte, für den verwandelt der Webassembly-Explorer den C- oder C++-Code in das Wa(s)t-Format.

01 (module
02   (table 0 anyfunc)
03   (memory $0 1)
04   (export "memory" (memory $0))
05   (export "fact" (func $fact))
06   (func $fact (param $0 i32) (result f64)
07     [...]
08   )
09 )

Beim Kompilieren der »wast«-Datei ins Webassembly-Binärformat (»wasm«) hilft das Tool »wast2wasm« aus dem WABT-Toolkit [21]. Ein beherztes

wast2wasm fact.wast -o fact.wasm

generiert die Datei. Die lädt der Browser per Javascript und führt die Funktion »$fact()« aus. Listing 4 zeigt im Auszug die HTML-Datei samt Javascript-Teil, der den Webassembly-Code einbindet.

01 [...]
02         <body>
03                 <script>
04                         var importObject = { };
05
06                         fetch('fact.wasm').then (response =>
07                         response.arrayBuffer()).then(bytes =>
08                         Webassembly.instantiate (bytes, importObject)).then(results => {
09                                 console.log(results.instance.exports.fact(5));
10                         });
11                 </script>
12         </body>
13 [...]

Abbildung 5 bildet die Ausgabe der Fakultät aus der Browserkonsole (Chrome Developer Tools) ab. Das Ergebnis lautet »120«, da in Listing 4 der Parameter beim Funktionsaufruf von »results.instance.exports.fact«»5« ist. Das Javascript-Objekt »importObject« exportiert Funktionen von Javascript nach Wast. Auf sie greifen dann die S-Expressions im Webassembly-Code zu [26].

Abbildung 5: Die eher spartanische Ausgabe von Listing 4 lässt sich auf der Browserkonsole bewundern.

Benchmarking

Stefan Krause testete im Februar 2017 die Performance von Webassembly mit verschiedenen Browsern [27] und verglich diese [28] mit den schnellsten C- und Java-Implementierung des Benchmark. Die Performance von Webassembly bewegt sich hierbei je nach Browser zwischen 130 und 190 Prozent – verglichen mit der nativen C-Implementierung.

Einen Browser-Benchmark für Webassembly, der auch Asm.js testet, bietet Massive unter [29]. Er vergleicht vier Metriken:

• Die “Main Thread Responsiveness” misst die Verfügbarkeit des Browsers (»main()«-Thread) beim Laden großer Codestücke.
• “Throughput” ist ein typischer Benchmark, der die Geschwindigkeit der Ausführung misst.
• Mit “Preparation” misst der Test, wie viel Zeit vergeht, bis der Browser den Code ausführen kann, also die Ladezeiten.
• Die Variable “Variance” beschreibt die Abweichungen in der Bildrate, was vor allem für grafische Anwendungen wie Spiele relevant ist.

Verglichen mit Asm.js schneidet Webassembly besser ab, was unter anderem am Binärformat liegt. Während Asm.js optimiertes Javascript (»gzip« und »minified«) liefert, ist der Code im Webassembly-Binärformat nochmals um 10 bis 20 Prozent schlanker.

Nach dem Laden des Binärcodes dekodieren und parsen die Browser diesen auch schneller als mit dem Javascript von Asm.js. Beim Ausnutzen und Optimieren von CPU-Features beschränkt sich Webassembly anders als Asm.js nicht auf Javascript. Hier ergeben sich weitere Geschwindigkeitsvorteile ([30], [31]).

Fazit

Schon einigermaßen integriert und entwickelt, doch befindet sich Webassembly noch in einem relativ frühen Stadium seiner Laufbahn. Einige der Features, welche die Designdokumente beschreiben, fehlen derzeit noch [32]. Auch auf die Hersteller von Browsern und Javascript-Engines kommt noch einiges an Arbeit zu. Dennoch zeichnet sich bereits ab, wohin die Reise gehen könnte und welche Pläne die Entwickler von Webassembly schmieden.

Vor allem das Binärformat kombiniert mit der Möglichkeit, nahezu beliebigen C- und C++-Code nach Webassembly zu kompilieren (wenn dieser portierbar ist), bietet viele Vorteile. Zum einen ermöglicht es effizientere Ladezeiten als mit Javascript (inklusive Asm.js). Zum anderen führt Webassembly Anwendungen unabhängig von der eingesetzten Plattform, dem Browser und dem Betriebssystem online aus.

Wer die laufende Entwicklung verfolgen möchte, besucht am besten die offizielle Webseite des Projekts [1], schaut hin und wieder auf die Mozilla-Developer-Seite [33] oder durchforstet die Artikel auf Mozilla Hacks [30].