Rok / Year: Svazek / Volume: Číslo / Number: Jazyk / Language 2020 22 1 SK
WebAssembly – vývoj a budúcnosť
WebAssembly – development and future
Patrik Švikruha [email protected]
Fakulta elektrotechniky a komunikačních technologií VUT v Brně
DOI: -
Abstract: In nowadays the web platform is specific with a low diversity of technology for the deve- lopment of client applications. A synonym for the target platform of client applications has become JavaScript, which is standardized under the name ECMAScript and is a W3C (World Wide Web Consortium) standard. However, JavaScript was not intended to be the target platform, and despite advanced optimizations of runtime environments, it does not achieve native performance. These issues will help create the WebAssembly specification, which represents a joint effort by the web community to create a new, secure, platform-neutral code representation that will achieve native performance. This review article describes the WebAssembly standard and the Portable Native Client and asm.js techno- logies on which WebAssembly is based. WebAssembly is often mistaken for a JavaScript replacement. Comparing WebAssembly and JavaScript will allow the reader to distinguish between different uses for the two technologies. Finally, the article evaluates the state of the W3C standard and the functionality, which will be added to the standard. This developed functionality aims to extend WebAssembly to a non-web platform. VOL.22, NO.1, FEBRUARY 2020
WebAssembly – vývoj a budúcnosť
Patrik Švikruha
Fakulta elektrotechniky a komunikačních technologií VUT v Brně Email: [email protected]
Abstrakt – V dnešnej dobe je webová platforma špe- JavaScriptom má za cieľ ukázať výkonnostné a koncepčné cifická malou diverzitou technológii pre vývoj klientskych rozdiely medzi týmito dvoma technológiami. Popis aktu- aplikácií. Synonymom pre cieľovú platformu klientských álneho stavu W3C štandardu priblíži čitateľovi možnosti aplikácií sa stal JavaScript, ktorý je štandardizovaný využitia WebAssembly. Posledná kapitola sa zaoberá bud- pod názvom ECMAScript a je štandardom W3C (World úcnosťou a rozpracovanou funkcionalitou, ktorá má za cieľ Wide Web Consortium). JavaScript však nebol určený rozšíriť tento WebAssembly ako univerzálny, platformovo ako cieľová platforma, a aj napriek pokročilým optimalizá- nezávislý formát. ciam behových prostredí nedosahuje natívny výkon. Tieto problémy pomohli vzniku špecifikácie WebAssembly, ktorá predstavuje spoločné úsilie webovej komunity na vznik 2 Predstavenie WebAssembly novej, bezpečnej a platformovo neutrálnej reprezentácie WebAssembly je binárny inštrukčný formát pre zásobní- kódu, ktorá bude dosahovať natívny výkon. Tento prehľa- kový virtuálny počítač. WebAssembly je dizajnovaný ako dový článok popisuje štandard WebAssembly, technológiu portable compilation target pre vysokoúrovňové jazyky ako Portable Native Client a asm.js z ktorých WebAssem- C, C++, Rust a umožňuje vývoj pre webové a serverové bly vychádza. WebAssembly sa často mylne označuje aplikácie. Portable compilation target znamená, že skom- ako náhrada JavaScriptu. Porovnanie WebAssembly a pilovaný kód nie je určený pre fyzickú platformu, ale pre JavaScriptu umožní čitateľovi rozlíšiť rôzne použitia virtuálnu, ktorá vytvára abstrakciu nad fyzickou platfor- týchto dvoch technológií. Na záver článok hodnotí stav mou. W3C štandardu a rozpracovanú funkcionalitu, ktorá bude do štandardu pridaná. Táto rozpracovaná funkcionalita má • Oficiálna stránka [31]. za cieľ rozšíriť WebAssembly aj mimo webovú platformu. • Oficiálny repozitár [32]. • W3C pracovná skupina [25]. 1 Úvod Táto technológia reprezentuje dôležitý vývojový stu- Malú diverzitu technológií a slabú podporu na poli vývoja peň evolúcie vývoja webových aplikácii. Umožňuje spúšťať klientskych webových aplikácií sa snažila vyriešiť webová skompilovaný a optimalizovaný kód v prostredí webového komunita rôznymi spôsobmi. Okrem štandardizovaného prehliadača bez nutnosti inštalácie externého pluginu. JavaScriptu sa pre klientské aplikácie používali rôzne pro- WebAssembly teda umožňuje zmeniť prístup k vývoju prietárne riešenia, ktoré riešili výkonnostné problémy Ja- webových aplikácií. Do uvedenia WebAssembly bol jediný vaScriptu. Medzi najznámenjšie technológie patria Java programovací jazyk schválený konzorciom W3C ako štan- Applet, Silverlight a FlashPlayer. Tieto technológie boli dard ECMAScript 1. zavrhnuté na jednej strane kvôli bezpečnostným problé- Nevýhody JavaScriptu ako assembly jazyka je jeho tex- mom a na strane druhej kvôli tomu, že neboli štandardi- tová forma a nedeterministická optimalizácia kódu na zované konzorciom W3C (World Wide Web Consortium). strane JavaScriptových enginov. Táto nedeterministickosť V roku 2015 W3C predstavila novú pracovnú skupinu s ná- je spôsobená rôznymi implementáciami JavaScriptových zvom WebAssembly Working Group, ktorá začala pracovať enginov a spôsobom distribúcie JavaScritpového kódu. na vytvorení univerzálnej, jazykovo a platformovo neut- Pre spustenie JavaScriptového kódu v prehliadači je nutné rálnej reprezentácie kódu. Táto reprezentácia dostala ná- stiahnuť celý textový súbor s kódom, sparsovať kód a vy- zov WebAssembly a jej 1. verzia vyšla ako W3C štandard tvoriť z kódu syntaktický strom (AST - Abstract syntax 5. decembra 2019. V tomto článku budú predstavené zá- tree). Na základe syntaktického stromu sa vytvorí byte- kladné koncepty štandardu WebAseembly a dôvody jeho code, ktorý následne JIT (Just in Time) infraštruktúra vzniku. Nasledujúce kapitoly budú popisovať technológie dokáže optimalizovať a reoptimalizovať. Portable Native Client a asm.js, z ktorých WebAssembly Spôsob akým sa dnes spúšťa JavaScript má nevýhody, vychádza. Dôležitú úlohu pri implementácii tohoto štan- ktoré pochádzajú z jeho vlastnosti – textová reprezentácia dardu zohrala aj sada kompilátorov LLVM, ktorá je popí- saná v kapitole 3.1. Popis rozdielov medzi WebAseembly a 1V praxi sa stretávame s názvom JavaScript.
34 VOL.22, NO.1, FEBRUARY 2020 a hlavne dynamická typovosť. JavaScript bol pôvodne na- HTTP spojenia. Druhé vylepšenie vo verzii HTTP/2 je vrhnutý ako doplnkový jazyk k Jave [21] a jeho úlohou ne- multiplex viacerých požiadaviek skrz jedno HTTP spoje- bolo poskytnutie vysokého výkonu. WebAssembly je oproti nie. Ani tieto vylepšenia však neriešia najväčší problém JavaScriptu navrhnutá od začiatku s dôrazom na výkon a JavaScriptového kódu, a to jeho veľkosť a textovú repre- kompaktnosť kódu. S JavaScriptom zdieľa rovnaký princíp zentáciu. zabezpečenia sandboxom a pomocou W3C doporučení aj Zväčšujúcou sa užívateľskou základňou chytrých telefó- kompatibilitu s aktuálnymi prehliadačmi. nov sa zvyšuje počet užívateľov, ktorý prehliadajú stránky WebAssembly sa dá v jednoduchosti zhrnúť ako nízko- pomocou nízkorýchlostných mobilných dát. Tento fakt úrovňový jazyk podobný assembleru, založený na stack spolu so zvyšujúcimi sa nárokmi na interaktivitu stránok machine, ktorý je určený pre spustenie vo WebAssembly má za následok zväčšovanie codebase. Nárast veľkosti má engine2. Špecifikácia jazyka určuje silnú typovosť a bi- za následok to, že medián interaktivity stránok pre mo- nárnu reprezentáciu [36]. Tieto vlastnosti, spolu s jednodu- bilné zariadenia sa pohybuje okolo 7,5 s4. Tieto fakty nútia chosťou, umožňujú WebAssembly dosahovať výkon, ktorý webovú komunitu hľadať iné spôsoby ako optimalizovať je zrovnateľný s natívnym kódom. Aktuálna verzia špecifi- technológie, ktoré sa používajú v prehliadačoch. kácie určuje iba číselné typy (i32, i64, f32 a f64) [33]. Pluginy Java Applet a Silverlight mali výhodu vlastného Okrem binárnej reprezentácie kódu, špecifikácia určuje runtime (JVM alebo CLR) v hosťovskom OS prehliadača aj textovú reprezentáciu. Binárna reprezentácia sa ozna- a tak dokázali vykonávať kód takmer natívnou rýchlosťou. čuje ako WASM a textová ako WAT. Textová a binárna Prekurzormi vzniku WebAssembly by sa dali nazvať po- forma sú navzájom zameniteľné a sú určené pre rôzne pou- kusy skompilovať rôzne jazyky do JavasScriptu, čo malo žitia. Textová forma je určená pre debugging a rôzne ná- svoje výhody a nevýhody medzi ktoré patrí: stroje na analýzu kódu. Binárna forma je určená pre pro- dukčné použitie a beh vo WebAssembly engine3. • Statická a silná typovosť (niektorých) kompilovaných WebAssembly sa označuje aj ako compilation target. jazykov a ich sadu nástrojov pri vývoji. Toto označenie znamená že WebAssembly kód je platfor- • Compile-time kontrola chýb. movo a hardvérovo nezávislý. Pri vzniku bola motivácia vyvinúť doplnok k JavaScriptu, ktorý je s ním plne kompa- • Statická analýza kódu (pri dynamických jazykoch je tibilný, bude bežať v JavaScriptovom engine ale poskytne to náročné). predikovateľný výkon, ktorý bude porovnateľný s natívnym kódom. WebAssembly dokáže s JavaScriptom spolupraco- • JavaScriptové enginy dokážu pomerne efektívne sp- vať na základe WebAssembly JavaScript API. úšťať aj veľké skompilované JavaScriptové codebase. WebAssembly je od počiatku vyvíjaná ako webový štan- • Pri debuggovaní aplikácie a hľadaní chyby bolo nutné, dard pod vedením W3C, s podporou majoritných prehlia- aby vývojár poznal JavaScript a jeho sadu nástrojov. dačov (Mozilla, Chrome, Safari, Edge) [17]. Táto technológia bola po prvýkrát predstavená v roku V roku 2006 Google uvoľnil GWT (Google Web Toolkit 2015 na blogu Luke Wagnera [30]. Hlavnou úlohou WASM – http://www.gwtproject.org/), čo je v skratke súbor je podporiť 3D rendering, editáciu videa, hry, kompresiu, nástrojov pre kompiláciu aplikácie napísanej v Jave do Ja- a iné výpočtovo náročne použitia vo webovom prehliadači. vaScriptu. Pomocou nástroja GWT sú napísané Google Maps, Gmail alebo populárna platforma Blogger. 3 História a dôvody vzniku Napriek tomu, že existuje množstvo jazykov, ktoré je možné skompilovať do JavaScriptu, tento prístup má na- Snaha o klientskú interakciu v prehliadači má dlhú his- sledovné nevýhody: tóriu. Okrem JavaScriptu existujú technológie Java Ap- plet, Silverlight, alebo Adobe Flash. Tieto technológie ne- • Ignorácia sémantických rozdielov skompilovaného ja- boli úspešné hlavne kvôli tomu, že fungovali ako pluginy zyka a JavaScriptu. do prehliadačov. Tiež neboli štandardizované a ich vý- • Generovaný JavaScript nie je možné optimalizovať voj určovala jedna firma (Sun Microsystems, Microsoft, tak, ako kód, z ktorého je vygenerovaný (JavaScript Adobe). je totiž optimalizovaný až v JavaScriptovom engine – S rozvojom internetu majú webové aplikácie stále väčšiu JIT optimalizácia vs AOT optimalizácia). JavaScriptovú codebase, čo znamená nárast veľkosti a počtu súborov. Nepriamo sa túto nevýhodu snažilo konzor- • Debugovanie zdrojového kódu skompilovaného do Ja- cium W3C vyriešiť vylepšovaním štandardu HTTP (Hy- vaScriptu je obtiažne. pertext Transfer Protocol). Prvé vylepšenie bolo možnosť reťazení HTTP odpovedí v HTTP/1.1 pomocou jednoho Spôsob distribúcie funkcionality pomocou transkompilá- cie do JavaScriptu ale nerieši problém výkonu JavaScriptu 2Väčšina existujúcich JavaScripových enginov podporuje WebAs- pre špecializované použitia, ako sú výkonnostne náročné sembly. 3Existujú samostatné WebAssembly runtime ako napríklad 4Údaje sú aktuálne k 1.1.2020 (zdroj: https://httparchive.org/ https://wasmer.io/. reports/loading-speed).
35 VOL.22, NO.1, FEBRUARY 2020
výpočty. Medzi tieto aplikácie patrí spracovanie videa, gra- Optimalizácie x86 fiky, kryptografia, virtuálna realita, atď. C FrontEnd LLVM BackEnd AMD64 C++ Tradične bol JavaScript iba interpretovaný, s rast- kompilátor IR kompilátor ARM IL úcim dopytom po interaktívnych webových stránkach však WASM všetky JavaScriptové enginy využívajú JIT interpreter. Ja- vaScriptové engine ako V8 (Google), Spidermonkey (Mo- zilla) alebo Chakra (Microsoft)5 dokážu JavaScripotvý kód Obrázek 1: Princíp fungovania LLVM toolchainu. skompilovať do určitej formy bytecode a tú optimalizovať. Takto optimalizovaný kód je možné rýchlejšie „interpreto- vaťÿ, čím sa zvyšuje efektívna rýchlosť JavaScriptu [37]. malizovaná forma je následne skompilovaná pomocou bac- Jedna z menej známych optimalizácií JavaScriptu, je na- kend kompilátora pre cieľovú platformu. príklad pridanie typu premennej (ukážka kódu 1). Prida- Toto rozdelenie a modulárnosť LLVM má následovné vý- nie operátora „|ÿ informuje JavaScriptový engine, že ne- hody: musí zisťovať typ založený na výsledku výrazu, ale zistí ho • Pre pridanie podpory nového vysokoúrovňového ja- vo fáze vytvárania AST, čím sa zefektívni jeho činnosť [2]. zyka je nutné vytvoriť iba frontend kompilátor. function compiledCalculation(){ • Pre pridanie podpory nového compilation target je var x=f()|0; // x je 32-bit int hodnota nutné vytvoriť iba nový backend kompilátor. var y=g()|0; // y je 32-bit int hodnota return(x+y)|0; // 32-bit sčítanie, nevykonáva sa • Pre podporu rôznych optimalizácií je možné pracovať ,→ žiadna kontrola typu alebo pretečenia } iba s IR kódom, čím sa tieto optimalizácie unifikujú skrz rôzne jazyky. Výpis kódu 1: Ukážka JavaScriptového kódu s explicitne Jeden z compilation targets je aj WebAssembly. Toto definovanými typmi premenných6. umožňuje rôznym jazykom, pre ktoré existuje frontend kompilátor, aby mohli LLVM toolchain použiť pre kom- Google a Mozilla, tvorcovia prehliadačov Chrome a Fi- piláciu do WebAssembly a bežať v prehliadači [13]. refox, sa rozhodli vyvinúť technológie, ktoré by riešili ti- eto problémy. Spoločnosti sa rozhodli pre odlišné prístupy k riešeniu vyššie uvedeného problému a vznikli dve tech- 3.2 Technológie Native Client a Portable Native nológie Native Client a asm.js. Client Netscape vytvoril v 90. rokoch NPAPI (Native Pepper 3.1 Projekt LLVM API), ktoré sprístupnilo pluginom prehliadača systémove volania. Pomocou NPAPI mohol teda kód pluginu volať Názov LLVM pravdepodobne vznikol ako akronym z Low systémové volania v kontexte užívateľa, pod ktorým bol Level Virtual Machine, no podľa oficiálnej dokumentá- spustený prehliadač. Toto spôsobovalo bezpečnostné ri- cie je LLVM celý názov projektu [14]. LLVM je modu- ziko a bolo jedným z dôvodov zavrhnutia tejto technológie. lárna sada kompilátorov, ktoré dokážu deterministicky a Na NPAPI boli založené aj vyššie spomínané technológie efektívne optimalizovať kód. Kompilácia zdrojového kó- Silverlight, Flash Player a Java Applet. dou pomocou LLVM sa skladá z dvoch po sebe idúcich Mozilla v spolupráci s Google vytvorila PPAPI (Portable kompilácií. O prvú kompiláciu sa stará kompilátor progra- Pepper API) [10], v rámci projektu Mortar [12], ktoré pô- movacieho jazyka (frontend kompilátor). Tento kompilá- vodne malo priniesť PDF čítač PDFium a Flash pluginy tor skompiluje zdrojový kód do LLVM Intermedia Repre- do prehliadača Firefox. Rozdiel oproti NPAPI bol ten, že sentation (LLVM IR) reprezentácie. Táto reprezentácia je cieľ kompilácie nebola architektúra hosťovského zariade- následne optimalizovaná pomocou modulárnych optimali- nia prehliadača, ale LLVM IR reprezentácia. Mozilla, ktorá zátorov. Nato je zoptimalizaovaná LLVM IR reprezentácia spolupracovala na projekte s Google však projekt zavrhla. skompilovaná pomocou druhého, systémového kompilátora Google v tomto projekte pokračoval a ďalej ho rozví- (backend kompilára) pre cieľovú platformu (x86, AMD64 jal a vytvoril technológiu Native Client (NaCl). NaCl bola a WebAssembly). Dvojúrovňová kompilácia, spolu s mo- možnosť ako spustiť natívny kód v prehliadači. Relatívne dulárnosťou umožňujú aby sa LLVM používal pre veľké zabezpečenie tejto technológie sa riešilo výberom systémo- množstvo jazykov a platforiem. vých volaní, ktoré boli označené ako bezpečné. Preto, aby Na schéme 1 je princíp fungovania LLVM toolchainu. sa kód nemusel pre každú architektúru kompilovať zvlášť, Na vstupe je kód, ktorý je napísaný v rôznych vysokoúro- použil Google PPAPI a tím vznikol Portable Native Client vňových jazykoch (C++, C). Tento kód je pomocou fron- (PNaCl) [20]. Tieto technológie sa skladajú z 2 elementov. tend kompilátoru skompilovaný do Intermedia Represen- 7 tation (IR), ktorý je následne optimalizovaný. Táto opti- 1. Toolchain ktorá kompiluje C/C++kód do tzv. NaCl/PNaCl modulov. 5Microsoft Edge bude používať JavaScripový engine V8 a rende- rovací engine Blink [1], kvôli tomu, že prechádza na Chromium. 7Použitý LLVM s CLang kompilátorom.
36 VOL.22, NO.1, FEBRUARY 2020
2. Runtime komponenty, ktoré sú integrované v prehlia- "use asm"; dači a umožňujú spustenie NaCl/PNaCl modulov (po- function f(i){ mocou PPAPI a NPAPI). i=i|0; return(i+1)|0; } Po vytvorení modulov nexe (NaCl) a pexe (PNaCl) bolo možné tieto moduly spustiť v prehliadači. Interakcia Výpis kódu 3: Kód po skompilovaní do asm.js formátu po- modulu s prehliadačom bola možná vďaka vyššie spomí- mcou nástroja Emscripten. nanému Pepper API (NPAPI a PPAPI). Štandard tohoto API bol však nekompletný a chýbala dokumentácia, takže jediný prehliadač, ktorý plne podporoval túto technológiu, asm.js, tak pri vytváraní AST priradí premenným typy, bol Google Chrome (a Chromium porty) [8]. ktoré sú definované pomocou znaku pre bitovú operáciu Výhoda tohoto prístupu spočíva v tom, že z C/C++sa po- OR – „|ÿ a typu „0ÿ, ktorý za ním nasleduje (0 znamená mocou LLVM toolchainu dokázal vytvoriť veľmi výkonný 32 bitový integer). Ak engine nepodporoval asm.js, tak sa natívny kód (pretože používal inštrukčnú sadu danej ar- tento kód vykonával ako štandardný JavaScript. chitektúry – AMD64, x32, ARM). Subset asm.js je teda optimalizovaný subset JavaScriptu. Vo firme Google sa začala debata či pokračovať v NaCl, Polia a premenné sú implicitne typové a používajú sa pretože sa to veľmi podobalo ére pluginov8 a po debatách v ňom iba numerické dátové typy. Výkon asm.js sa mierne medzi V8 tímom a NaCl tímom sa Google rozhodol v máji približuje výkonu natívnemu kódu. Asm.js má síce výhody 2017 oficiálne ukončiť tento projekt a vývojárov presunúť skompilovaného jazyka, ale stále sa jedná o JavaScript, čiže do novovzniknutého WebAssembly tímu [4]. nie je možné plne využiť všetky optimalizácie, ktoré pon- úka LLVM kompilácia. 3.3 Technológia asm.js Vlastnosti asm.js možno zhrnúť do nasledujúcich bodov:
Mozilla sa rozhodla vydať po ukončení spolupráce • asm.js kód predchádza „spomaľovaniuÿ kódu pomo- na PPAPI cestou optimalizácie JavaScriptu a vznikol cou implicitného typu premenných. Toto umožňuje asm.js, čo je subset JavaScriptu, v ktorom sa používajú AOT (Ahead of Time) kompiláciu a optimalizáciu iba číselné dátové typy. kódu do JavaScriptu. Výsledný kód má za následok Obmedzenie na číselné dátové typy má za následok, že zrýchlenie JIT kompilácie JavaScripového engine. JavaScriptový engine nemusí pri JIT kompilácii JavaScrip- tového kódu zisťovať typy premenných, pretože tieto typy • JavaScriptový engine má garanciu, že typ danej pre- sú známe už z vytvorenia AST. Táto optimalizácia sa vyko- mennej sa nebude v runtime meniť, takže môže vyge- náva pri kompilácii JavaScript/C/C++kódu do asm.js, t.j. nerovať efektívny medzikód. Ahead of Time (AOT). Asm.js je teda silne typový subset JavaScriptu [22], 3.4 Zhrnutie Native Client a asm.js ktorý je optimalizovaný tak, aby JavaScript engine po vy- tvorení syntaktického stromu (AST) nemusel zisťovať dá- Native Client priniesol výkon natívneho kódu do prehli- tový typ premenených [38]. adača a asm.js zase prenositeľnosť kódu, ktorý je možné spustiť bez pluginu v každom prehliadači. Fúziou týchto Formát asm.js sa môže použiť ako compilation target, myšlienok vznikla WebAssembly, ktorá je platformovo pretože umožňuje optimalizácie, aké samotný JavaScrip- agnostická ako asm.js, ale zároveň umožňuje kódu výkon tový kód neumožňuje [29]. Myšlienka pridať silnú typovosť podobný Native Client. Native Client a aj asm.js sú popri do JavaScriptového kódu je v ostrom kontraste s vlast- Flash Player, Java Applet a Silverlight míľniky, ktoré boli nosťou JavaScriptu, ktorou je jeho dynamická typovosť. prekurzormi technológie WebAssembly. Obrovskú zásluhu Podľa benchmarkov bola rýchlosť asm.js voči natívnej na rozvoji WebAssembly má Mozilla, ktorej prehliadač je rýchlosti9 menšia iba o 50 % [23]. lídrom v implementácii štandardu W3C WebAssembly. Nečakaný výkon asm.js mal za následok, že sa vytvorila function f(i){ returni+1; pracovná skupina z Mozilla, Microsoft, Google a Apple, a } vytvorili pre tento subset JavaScriptu špecifikáciu.
Výpis kódu 2: Kód pred optimalizáciou pomocou Emscrip- 4 Princíp fungovania WebAssembly ten. Výpis kódu 3 je vo formáte asm.js. Direktíva na prvom WebAssembly je vytvorená ako virtuálny zásobníkový riadku „use asmÿ hovorí JavaScriptovému engine, že na- počítač. Reprezentácia kódu zasobníkového počítača sledujúci kód je v asm.js formáte. Ak engine podporuje umožňuje kompaktnejší kód pre enkódovanie, dekódova- nie, kompiláciu a interpretáciu [35]. 8 Bolo treba do prehliadača pridať NaCl/PaCl plugin, a ten nebol O WebAssembly môžeme povedať, že jej inštrukčný set štandardizovaný. 9Rýchlosť, ktorá by bola ekvivalentná rýchlosti ak by bol kód architektúry (ISA) je RISC (Reduced Instruction Set Com- napísaný v strojovom kóde danej platformy. puter).
37 VOL.22, NO.1, FEBRUARY 2020
(module Initial Stack PostAdd Stack (type $t0(func)) 1 100 100 (type $t1(func(result i32))) 4
Stack Pointer ADD 10 10 SUM 110 (func $__wasm_call_ctors(type $t0)) 2 Stack Pointer (func $main(export "main")(type $t1)(result i32) 5 3 20 i32.const 42) 20 1 POP 100 5 2 POP 10 (table $T011 anyfunc) 25 25 3 Add 100, 10, SUM (memory $memory(export "memory")2) 4 PUSH SUM (global $g0(mut i32)(i32.const 66560)) (global $__heap_base(export "__heap_base") i32 ,→ (i32.const 66560)) (global $__data_end(export "__data_end") i32 Obrázek 2: Zjednodušená schéma zásobníkového počítača - ,→ (i32.const 1024)) Stack machine. )
JIT Kompilátor Výpis kódu 4: WAT zápis binárneho WASM súboru vyge- nerováneho z kódu 5.
WASM Strojový súbor IR kód #define WASM_EXPORT __attribute__((visibility("default"))) WASM_EXPORT int main(){ return 42; }
Optimalizácia Dekodóvanie Vykonávanie Výpis kódu 5: Program v jazyku C pred kompiláciou. kompilácia
let wasmPath= "../out/main.wasm"; fetch(wasmPath).then(response => Obrázek 3: Principiálna schéma spúšťania WebAssembly response.arrayBuffer() v JavaScriptovom engine spolu s časovým pomerom jed- ).then(bytes => notlivých krokov. ,→ WebAssembly.insta0ntiate(bytes)).then(results =>{ instance= results.instance; document.getElementById("container").textContent= ,→ instance.exports.main(); Na schéme 3 sa nachádza principiálna schéma spúšťania }).catch(console.error); WebAssembly vo WebAssembly engine10. Engine pri načí- taní súboru tento súbor iba dekóduje a vytvorí z neho IR Výpis kódu 6: Zavolanie funkcie main() pomocou Ja- kód. Tento kód nie je LLVM IR kód. Tento IR slúži vaScript interoop. JIT kompilátoru na optimalizácie a následnú kompiláciu na inštrukčnú sadu danej platformy. WebAssembly je síce binárny formát, ale špecifikácia ho- ho už takmer 90 % prehliadačov [7], nie je tento spôsob vorí aj o textovej WAT (WebAssembly Text) reprezentácii, fallbacku praktický. ktorá slúži pre sadu nástrojov a ľudí [15]. V praxi sa ne- Ak by sme chceli pri kompilácii WASM súborov vytvoriť predpokladá, že by sa písala WebAssembly ručne pomocou aj asm.js súbory, je to možné pomocou nástroja Emscrip- WAT formátu. WAT zápis používa S-expression [15], ako ten, ktorý používa na kompiláciu vyššie spomínaný LLVM je vidieť na zápise 4. toolchain. WebAssembly je v porovnaní s asm.js o 30 % Tento kód je reprezentáciou C kódu z výpisu kódu 5. rýchlejšia a na mobilnej platforme Android až o 60 % [24].
4.1 Použitie v prehliadači 5 Porovnanie WebAssembly a Ja- vaScriptu WebAssembly momentálne nie je možné v prehliadači spus- tiť priamo. Jediná možnosť je načítanie WebAssembly mo- Nasledujúci zoznam obsahuje výhody, ktoré má WebAs- dulu cez JavaScript a následné používanie tohoto modulu sembly oproti JavaScriptu. pomocou JavaScript interoop. Výpis kódu 6 ukazuje načí- • Rýchlejšie načítanie binárneho súboru, ako textového tanie WebAssembly modulu zo súboru main.wasm, kto- súboru s JavaScriptom (aj keď je použitá komprima- rého WAT reprezentácia je na výpise 4. čná technológia gzip). Ak by prehliadač nepodporoval WebAssembly, je možné použiť fallback na asm.js. Tento fallback je ale veľmi ne- • Dekódovanie binárneho WASM súboru do AST je praktický, pretože výsledný súbor vo formáte asm.js môže rýchlejšie a jednoduchšie ako parsovanie JavaScripto- mať desiatky MB, čo je pre prostredie webu veľmi neprak- vých súborov. tické. Keďže je WebAssembly štandard W3C a podporuje • Kompilácia a optimalizácia kódu je rýchlejšia, pre- 10Môže sa jednať o JavaScripový engine s podporou WebAssembly. tože WebAssembly je typová a je bližšie medzikódu,
38 VOL.22, NO.1, FEBRUARY 2020
ktorý používajú JavaScriptové runtime. Optimalizácie Firefox vo verzii 52 bol prvý z prehliadačov, ktorý za- pre WebAssembly je možné urobiť už pri kompilácii čal podporovať WebAssembly [3]. Momentálne je podpora do WASM. WebAssembly v prehliadačoch viac ako 90 % [7]. Prehli- adače implementujú WebAssembly pomocou globálneho • Reoptimalizácia – na strane klienta nie je potrebná, objektu WebAssembly.Global, ktorý slúži na dynamické pretože WebAssembly je typová. JavaScript engine ne- linkovanie viacerých modulov skrz import a export syn- musí optimalizovať WebAssembly kód a tým pádom tax [16]. Tento globálny objekt je dostupný iba cez Ja- nie je potrebná réžia na optimalizáciu a reoptimalizá- vaScriptové API, čo znamená, že WebAssembly zatiaľ nie ciu, ako v prípade JavaScriptu je možné použiť v prehliadači bez inicializácie z JavaScrip- • Vykonávanie kódu zaberá menej času (aj kvôli vyššie tového kódu [34]. spomenutým výhodám). Na schéme 4 je vidieť pomer medzi vykonávaním Ja- 7 Aplikácie WebAssembly vaScriptového a WebAssembly kódu. Zo schémy je pome- WebAssembly využívajú primárne výkonovo náročnejšie rovo vidieť jednoduchšie spracovanie a následné vykonanie projekty: WebAssembly kódu. Dekódovanie súboru je rýchlejší pro- ces ako parsovanie, pretože engine nemusí pripradovať typy • Oryol (3D framework) [9]. premenných na základe komplexného AST. Jednoduchší • PyBullet (Realtime Physics Simulation engine) [11]. AST a implicitné typy premenných znamenajú rýchlejšiu JIT optimalizáciu a vykonávanie kódu [5]. • D3-force (Graph Simulation library) [6]. • ONNX.js (Open Neural Network Exchange) [18]. AST Neoptimalizovaný JIT Kompilátor kód • Blazor WebAssembly (klientský framework pre vytvá-
JS ranie užívateľského rozhrania) [19]. IR Strojový súbor IR kód Ako je vidieť zo zoznamu, jedná sa zatiaľ o veľmi špe- cifické použitie WebAssembly. Do budúcna sa však ráta s pridaním Garbage Collectoru a ostatných rozšírení pre Parsovanie Optimalizácia a kompilácia Vykonávanie GC lepšiu integráciu s „vyššímiÿ jazykmi. JIT Kompilátor
WASM Strojový súbor IR kód 8 Budúcnosť a rozpracovaná funkcionalita Ako som spomínal v kapitolách vyššie, WebAssembly je vo vývoji a štandardizovaná je iba verzia 1. Špecifikácia Optimalizácia Dekodóvanie Vykonávanie kompilácia WebAssembly 1 dosiahla nasledovné ciele:
• Kompiláciu do neutrálneho jazyka podobného assem- Obrázek 4: Porovnanie vykonávania JavaScriptového sú- bleru, ktorý nie je určený pre špecifickú fyzickú archi- boru a WASM súboru. tektúru.
• Rýchle vykonávanie WebAseembly kódu JavaScripto- 6 Štandardy W3C a podpora prehliada- vým enginom. čov • Kompaktnosť kódu, čo je dosiahnuté binárnou formou a reprezentáciou kódu pre zásobnikový počítač. Štandard konzorcia W3C pre WebAssembly je aktuálne vo verzii 1 (z 5.12. 2019) a skladá sa z troch hlavných častí: • Lineárna pamäť - stack machine. Toto je zabezpečenie voči tomu, aby WebAssembly kód mohol pristupovať WebAssembly Core Specification [26]. • iba k pamäti, ktorú mu určí JavaScriptový engine (po- • WebAssembly JavaScript API [27]. mocou TypedArray, čo je pole, ktoré obsahuje bajty • WebAssembly Web API [28]. pamäte). Prvá špecifikácia s názvom WebAssembly Core Speci- Ďalší cieľ špecifikácie WebAssembly je pridať podporu fication, hovorí o základných vlastnostiach WebAssembly pre funkcionality, ktoré umožnia vytvárať tzv. ťažké desk- ako sú formát kódu, jeho efektívne vykonávanie a jeho topové aplikácie, ako napríklad Photoshop alebo Auto- kompaktnosť. Druhý dokument s názvom WebAssembly CAD. Podpora takýchto aplikácii vyžaduje funkcionalitu, JavaScript API, hovorí o spolupráci medzi WebAssembly a ktorá je popísaná v zoznamoch Využitie vlastností mo- JavaScriptom. Posledný dokument s názvom WebAssembly derného hardware a Vylepšenie loadtime WebAssembly Web API popisuje širšiu integráciu WebAssembly s webo- v prehliadači. WebAssembly je určená aj pre štandardný vou platformou. vývoj webových aplikácii. Požiadavky na funkcionalitu
39 VOL.22, NO.1, FEBRUARY 2020 sú popísané v zozname Vylepšenia pre štandardný vývoj 8.4 Vylepšenia pre štandardný vývoj webových webových aplikácií. aplikácií Pre lepšiu predstavu o aktuálnom stave funkcionality Integrácia ES modulov (používanie import a export som pridal hodnotenie 0 až 4. Toto hodnotenie je za- • direktív). (3) ložené na špecifikácii WebAssembly Specification Release 1.0 (Draft, Apr 09, 2020)11. 8.5 Ostatné vylepšenia Význam hodnotenia je následovný: Tieto vylepšenia nie sú súčasťou W3C WebAssembly špe- 0. – Funkcionalita nemá draft a prebieha o nej diskusia. cifikácie. Komunitná skupina W3C ale diskutuje aj o nich. 1. – Pripravuje sa draft funkcionality. • Jednoduchá a rýchla výmena dát medzi JavaScripo- 2. – Funkcionalita má draft a prehliadače ju začínajú tom a WebAssembly. implementovať. • Integrácia toolchain (balíčkovací systém, webpack, 3. – Funkcionalita má draft a niektoré prehliadače ju ex- parcel, wasmpack) perimentálne implementujú. • Implicitná HTTP cache - z cache si prehliadač vybe- 4. – Funkcionalita je schválená štandardom W3C. rie správny WASM súbor, z ktorého je už vytvorený strojový kód (o ktorý sa postaral JavaScript engine). 8.1 Využitie vlastností moderného hardware S vylepšeniami popísanými vo vyšších zoznamoch, bude • Threading - pre prácu s modernými typmi procesorov možné prepísať hlavné časti frameworkov ako Angu- je potrebné pridať podporu pre vlákna, čím sa otvára lar, Ember, React alebo Vue.js. Tento prepis bude mať cesta k viac-jadrovým procesorom. (3) za následok zrýchlenie behu týchto frameworkov, pretože vo WebAssembly bude možné paralelizovať výpočty, ktoré • SIMD - je to ďalšia možnosť paralelného spracovania vykonávajú tieto frameworky (výpočty pre Virtual DOM dát, pretože 1 inštrukciou dokážeme spracovať viacero a pod.). Pre React by to napríklad znamenalo prepis DPM dát. (3) diffing algoritmu, čo je algoritmus, ktorý porovnáva starý, reálny DOM a nový, aktualizovaný, virtuálny DOM. • Podpora AMD64 architektúry - s architektúrou x86 WebAssembly znamená zmenu nielen pre vývoj webo- (32bit) je k dispozícii 4GB adresovateľnej pamäte. 64- vých aplikácií. So špecifikáciou WASI vznikne platforma, bitová adresa pamäte umožňuje adresovať 16 exabaj- ktorá umožní zdielať a bezpečne spúšťať zdrojový kód skrz tov pamäte. (0) rôzne platformy a operačné systémy. WebAssembly môžeme ale zhodnotiť ako štandard bud- 8.2 Vylepšenie času načítania WebAssembly úcnosti vývoja aplikácií, ktorý sa stále rozvíja. WebAssem- v prehliadači bly má obrovskú výhodu v tom, že od začiatku vzniká ako formálna špecifikácia pod vedením konzorcia W3C. • Streaming compilation - WebAssembly (JavaScript) engine dokáže spúšťať WASM súbor postupne, tak ako 9 Záver prichádzajú pakety. (4) WebAssembly sa môže stať platformou ktorou sa kedysi • Tiered compilation - odstupňovaná kompilácia, ktorá chcela stať Java s mottom ”Write once, run anywhere”. umožňuje pomocou viacnásobnej kompilácie doopti- Pôvodne bola určená pre prostredie webu no jej univerzál- malizoavať výsledný kód. Táto technika sa často pou- nosť a štandardizácia ju predurčuje k tomu, aby sa pou- žíva pri jazykoch, ktoré pre svoj beh používajú run- žívala aj mimo webové prostredie. Hoci je WebAssembly time (.NET, Java). (3) často označovaná za nasledovníka JavaScriptu, nie je to pravda. WebAssemly treba chápať ako nízkoúrovňový, pla- 8.3 Vylepšenia pre vysokoúrovňové jazyky toformovo nezávislý formát kódu. Tento formát je vytvo- rený ako compilation target, je teda od začiatku dizajno- • Automatická správa pamäti - Garbage Collector vaný s týmto cieľom, čo sa prejavilo na jej vlastnostiach. (GC). (2) Vzťah WebAssembly a JavaScriptu by sa dal analogicky prirovnať ku vzťahu Javy a JavaScriptu v dobe vytvore- • Exception Handling (2) nia JavaScriptu. Java mala byť zameraná na výkon a Ja- vaScript na prácu s užívateľským rozhraním a bezpečné sp- • Tail call - optimalizácia pre call stack volania. (2) úšťanie cudzieho kódu na danej platforme. Táto pôvodná myšlienka je presnou analógiu vzťahu WebAssembly a Ja- WebAssembly system interface (WASI) - jedná sa o • vaScriptu. WebAssembly má slúžiť na výkonovo náročné POSIX alternativu pre WebAssembly. (2) aplikácie, medzi ktoré dnes patrí audio, video, kryptogra- 11https://webassembly.github.io/spec/core/. fia, umelá inteligencia a rozšírená realita. Medzi priority
40 VOL.22, NO.1, FEBRUARY 2020 na ktorých momentálne pracuje WebAssembly Working [10] Greggman G. Thoughts on asm.js vs PNaCl Group patrí integrácia s modernými viacjadrovými pro- [online].[cit. 19. 4. 2020] Dostupné z URL: cesormi a rozšírenia, ktoré umožnia integráciu so správ-
[8] Dr. Rauschmayer A. Running code fast in web [21] Netscape Communications NETSCAPE AND browsers: PNaCl versus asm.js [online].[cit. 19. 4. 2020] SUN ANNOUNCE JAVASCRIPT, THE OPEN, Dostupné z URL:
41 VOL.22, NO.1, FEBRUARY 2020
[22] Rossberg, A., Titzer, B.L., Haas, A., Schuff, D.L., [35] webassembly.org WebAssembly Design Rationale Gohman, D., Wagner, L., Zakai, A., Bastien, J.F., [online].[cit. 19. 04. 2020] Dostupné z URL:
42