Die JavaScript Promise Integration (JSPI) API ermöglicht es WebAssembly-Anwendungen, die für synchronen Zugriff auf externe Funktionen geschrieben wurden, reibungslos in einer Umgebung zu arbeiten, in der diese Funktionen tatsächlich asynchron sind.
Die JavaScript Promise Integration (JSPI) API von WebAssembly hat eine neue API, verfügbar ab der Chrome-Version M126. Wir sprechen über die Änderungen, wie man sie mit Emscripten verwendet und was der Fahrplan für JSPI ist.
JSPI ist eine API, die es Anwendungen, die sequentielle APIs verwenden, ermöglicht, auf asynchrone Web-APIs zuzugreifen. Viele Web-APIs arbeiten mit JavaScript-Promise-Objekten: Statt die angeforderte Operation sofort auszuführen, geben sie ein Promise zur Ausführung zurück. Andererseits stammen viele Anwendungen, die in WebAssembly kompiliert wurden, aus der C/C++-Welt, die von APIs dominiert wird, bei denen der Aufrufer blockiert, bis die Operation abgeschlossen ist.
Die JavaScript Promise Integration (JSPI) API von WebAssembly tritt mit der Chrome-Version M123 in einen Origin Trial ein. Das bedeutet, dass Sie testen können, ob Sie und Ihre Nutzer von dieser neuen API profitieren können.
JSPI ist eine API, die es ermöglicht, sogenannten sequenziellen Code – der in WebAssembly kompiliert wurde – auf Web-APIs zuzugreifen, die asynchron sind. Viele Web-APIs sind in Bezug auf JavaScript Promises gestaltet: Anstatt die angeforderte Operation sofort auszuführen, geben sie ein Promise zurück, das dies tun wird. Wenn die Aktion schließlich ausgeführt wird, ruft der Task-Runner des Browsers alle Callbacks mit dem Promise auf. JSPI bindet sich in diese Architektur ein und ermöglicht einer WebAssembly-Anwendung, angehalten zu werden, wenn das Promise zurückgegeben wird, und wieder aufgenommen zu werden, wenn das Promise erfüllt wird.
Willkommen in der spannenden Welt von V8, wo Geschwindigkeit nicht nur ein Feature, sondern eine Lebensweise ist. Während wir uns von 2023 verabschieden, ist es Zeit, die beeindruckenden Errungenschaften zu feiern, die V8 in diesem Jahr erreicht hat.
Durch innovative Leistungsoptimierungen erweitert V8 weiterhin die Grenzen des Möglichen in der sich ständig weiterentwickelnden Weblandschaft. Wir haben einen neuen Mitteltier-Compiler eingeführt und mehrere Verbesserungen an der Top-Tier-Compiler-Infrastruktur, der Laufzeitumgebung und dem Garbage Collector implementiert, was zu signifikanten Geschwindigkeitsgewinnen auf allen Ebenen geführt hat.
Ein kürzlich erschienener Artikel über WebAssembly Garbage Collection (WasmGC) erklärt auf hoher Ebene, wie der Garbage Collection (GC) Vorschlag darauf abzielt, die Unterstützung von Programmiersprachen mit Garbage Collection in Wasm zu verbessern, was angesichts ihrer Beliebtheit sehr wichtig ist. In diesem Artikel werden wir uns mit den technischen Details befassen, wie GC-Sprachen wie Java, Kotlin, Dart, Python und C# nach Wasm portiert werden können. Es gibt tatsächlich zwei Hauptansätze:
Wir veröffentlichen WebAssembly-Tail-Calls in V8 v11.2! In diesem Beitrag geben wir einen kurzen Überblick über diesen Vorschlag, demonstrieren einen interessanten Anwendungsfall für C++-Koroutinen mit Emscripten und zeigen, wie V8 Tail Calls intern behandelt.
Ein Aufruf befindet sich in Tail-Position, wenn er die letzte Anweisung ist, die vor der Rückkehr aus der aktuellen Funktion ausgeführt wird. Compiler können solche Aufrufe optimieren, indem sie den Aufrufer-Frame verwerfen und den Aufruf durch einen Sprung ersetzen.
Dies ist besonders nützlich für rekursive Funktionen. Betrachten Sie beispielsweise diese C-Funktion, die die Elemente einer verketteten Liste summiert:
int sum(List* list, int acc) {
if (list == nullptr) return acc;
return sum(list->next, acc + list->val);
}
Mit einem regulären Aufruf verbraucht dies 𝒪(n) Stapelspeicherplatz: Jedes Element der Liste fügt einen neuen Frame auf dem Aufrufstapel hinzu. Mit einer ausreichend langen Liste könnte dies sehr schnell den Stapel überlaufen lassen. Durch den Ersatz des Aufrufs durch einen Sprung verwandelt die Tail-Call-Optimierung diese rekursive Funktion effektiv in eine Schleife, die 𝒪(1) Stapelspeicherplatz verwendet:
V8 hat zwei Compiler, um WebAssembly-Code in Maschinen-Code zu übersetzen, der dann ausgeführt werden kann: den Baseline-Compiler Liftoff und den optimierenden Compiler TurboFan. Liftoff kann Code viel schneller generieren als TurboFan, was schnelle Startzeiten ermöglicht. TurboFan hingegen kann schnelleren Code generieren, was hohe Spitzenleistung ermöglicht.
Dank der jüngsten Arbeit in Chrome und Emscripten können Sie jetzt bis zu 4 GB Speicher in WebAssembly-Anwendungen nutzen. Das ist eine Steigerung gegenüber dem vorherigen Limit von 2 GB. Es mag seltsam erscheinen, dass es jemals ein Limit gab – schließlich war keine Arbeit notwendig, damit Menschen 512 MB oder 1 GB Speicher nutzen konnten! – aber es stellt sich heraus, dass beim Sprung von 2 GB auf 4 GB sowohl im Browser als auch in der Werkzeugkette einige besondere Dinge geschehen, die wir in diesem Beitrag beschreiben werden.
Wir haben eine wachsende Anzahl von Compilern und anderen Werkzeugen, die .wasm-Dateien erzeugen oder bearbeiten, und manchmal möchte man hineinschauen. Vielleicht sind Sie Entwickler eines solchen Werkzeugs oder direkt Programmierer, der auf Wasm abzielt und darüber nachdenkt, wie der erzeugte Code aussieht - aus Leistungsgründen oder anderen Gründen.
Emscripten hat sich immer zuerst auf das Kompilieren für das Web und andere JavaScript-Umgebungen wie Node.js konzentriert. Aber da WebAssembly beginnt, ohne JavaScript verwendet zu werden, entstehen neue Anwendungsfälle, und deshalb haben wir daran gearbeitet, eigenständige Wasm-Dateien aus Emscripten zu generieren, die nicht auf die Emscripten-JavaScript-Laufzeit angewiesen sind! Dieser Beitrag erklärt, warum das interessant ist.