Ort: SinnerSchrader (Völckersstr. 38)
Zeit: 02.05.2017 18:30 Uhr
Kategorie: Web
Das war ein wirklich herausragendes Event in den frisch aufbereiteten Räumen von SinnerSchrader. Die Räumlichkeiten wurden gerade so pünktlich fertiggestellt. Ein Foto vom gleichen Tag aus der Mittagszeit zeigte die Räume noch im Bauzustand.
In Kooperation mit Mozilla wurden nicht nur die Räumlichkeiten zur Verfügung gestellt, sondern für eine sehr angenehme Atmosphäre gesorgt. Am Empfang wurde man mit Sekt und kühlen Getränken willkommen geheißen. Durch ein üppiges Buffet und sogar einem netten Herrn am Grill war außerdem für das leibliche Wohl gesorgt. Erwartet und gekommen waren viele Entwickler aus den unterschiedlichsten Bereichen, so dass die zunächst großzügig ausgelegt zu scheinenden Stuhlreihen am Start der Vortragsreihe gut gefüllt waren. Die Roadshow bestand aus drei Vorträgen, die ich aufgrund der Übersichtlichkeit in drei Beiträge geteilt habe - die anderen beiden werden noch folgen.
Mit dem kurzen Hinweis auf CSS Grid (hier ist ein empfehlenswerter Guide zu finden) und der Umfrage nach dessen Bekanntheitsgrad im Saal, begann Lin ihren Vortrag zu Web Assembly und ihren hervorragend im Comic-Stil aufbereiteten Folien. Große Teile ihres Vortrages sind hier und in den dort verlinkten Unterseiten zu finden. Wer mehr erfahren möchte ist eingeladen auf Ihre Seiten inklusive der Comic-Graphiken zu sehen. Ich werde hier einen Überblick vermitteln.
Lin leitete Ihren Vortrag mit einer ganz knappen historischen Sichtweise ein. Nachdem Javascript 1995 eingeführt wurde, entstand ihrer Ansicht nach im Jahr 2008 der "Performance War". Zur Entstehung von Javascript 1995 war Netscape der dominierende Browser und auch wenn man von Javascript und dessen Einsatzmöglichkeiten durchaus begeistert sein konnte, stand eher der Inhalt (HTML) im Vordergrund und weniger das dynamische Verhalten der Internetseiten. Im Laufe der Zeit wurde Javascript und damit auch dessen Performance jedoch immer wichtiger.
Mit dem in Firefox 3.1 integrierten ersten JIT-Compiler namens TraceMonkey konnte die Performance der Ausführung von Javascript bis um das zehnfache gesteigert werden. Fast zeitgleich wurde Googles V8 Javascript Engine (ebenfalls mit JIT-Compiler) veröffentlicht, so dass man vom Beginn des "Performance Wars" sprechen könnte. Die darauf folgenden Verbesserungen auf Firefox-Seite sind bspw. hier zu entnehmen.
Sehr interessant waren die Einblicke unter die Haube eines JIT-Compilers in dessen Verarbeitung von Javascript Code. Jede Ausführung einer Aufgabe erfolge in folgenden Tätigkeiten:
- Parse
- Compile + optimize
- Reoptimize
- Execute
- Garbage collection
Insbesondere Performance-kritische Teile ließen sich nun über Web Assembly in einen symbolischen Maschinencode (Intermediate Representation) kompilieren. So würde bspw. aus Sprachen wie C, C++ oder Rust in diese Intermediate Representation kompiliert, um sie später basierend auf dem verwendeten Prozessortypen (z. B. ARM oder x86) in Maschinencode zu übersetzen. Die hierfür mögliche Toolkette für die Programmiersprache C beinhalte clang und LLVM.
Auf diese Weise ließen sich die Tätigkeiten reoptimize und garbage collection eliminieren und alle weiteren Tätigkeiten des Compilers verkürzen. Ebenfalls würde die Fetch-Zeit (das Laden der Logik) verkürzt. Ein Wermutstropfen sei jedoch, dass man die Garbage Collection von Javascript verliere und sich somit selbst um die Speicherfreigabe der verwendeten Laufzeitdaten kümmern müsse.
Das Laden von entwickelten WebAssembly-Modulen sei derzeit noch etwas umständlich, aber man gehe davon aus, dass dies bald so einfach geschehen kann wie das Einbinden von Javascript-Modulen.
WebAssembly nutze einen ArrayBuffer, um den Heap zu simulieren. Die Positionen in diesem Array seien hierdurch sozusagen die Speicheradressen. Wahrscheinlich würde man sich für die Entwicklung von WebAssembly einen Wrapper bauen, der die Speicheradressen weitergebe. Der C-Code fülle dann den Heap mit kompiliertem Code.
Der initiale Aufruf von WebAssembly-Code sei langsamer, als Aufrufe eines Javascript-Codes, da der JIT-Compiler nicht von sich aus wüsste, wie er mit WebAssembly-Code umzugehen habe. Daher müsse der JIT-Compiler dies weiterreichen (in der Fachsprache nennt sich dies anscheinend "Trampolining"). Daher sollten zu häufige Wechsel zwischen Javascript und WebAssembly vermieden werden. Insbesondere, da WebAssembly derzeit über keine Möglichkeit zur DOM-Manipulation verfüge, ist dies derzeit nicht in allen Fällen verhinderbar. Dies würde in Zukunft jedoch ebenfalls ermöglicht.
Web Assembly unterstütze außerdem SIMD (Single Instruction Multiple Data), um eine Reihe von Daten parallel durch die gleiche Instruktion verarbeiten zu können, was speziell für Multimedia oder VR-Anwendungen wichtig werden könne.
