Így gyorsítja tovább a WebAssemblyt a Mozilla

Új, kétszintű és streaming fordítóval igyekszik tovább gyorsítani a WebAssemblyre építő webes alkalmazásokat a Mozilla, a hamarosan érkező Firefox 58-ban. Az iparági összefogással megvalósult webes bájtkód már most is érezteti jótékony hatását az online felületeken, a cég új megoldásai azonban még nagyobb lendületet adhatnak neki.

A gyorsulás első motorja az új streaming fordító, utóbbi képes már letöltés közben elkezdeni a futtatni kívánt kód fordítását. A második újítás a kétszintű, egy baseline és egy optimizing komponensből felépülő fordító - a baseline compiler akár 10-15-ször gyorsabb fordítást ígér a kódot párhuzamosan hatékonyabbá tevő optimizing változatnál. Ezekkel a Mozilla szerint a böngésző gyakorlatilag gyorsabban tudja fordítani az adott kódot, mint ahogy az a hálózatról beérkezik - asztali gép esetében másodpercenként 30-60 megabájtnyi WebAssembly kód lefordításáról van szó, de még egy átlagos mobileszközön is másodpercenként 8 megabájtos tempóval dolgozik a böngésző. Ezzel a letöltést követő fordítás miatti plusz időt a cég lényegében teljesen ki tudja iktatni.

A CPU lett a szűk keresztmetszet

Ahogy blogposztjában a Mozilla is rámutat, míg korábban az adott hálózat sávszélessége volt a szűk keresztmetszet a böngészés sebességénél, mára a processzorteljesítmény lett az, azon belül is elsősorban a fő végrehajtási szálé. Ez annak köszönhető, hogy a weboldalak mára jókora mennyiségű JavaScript kóddal dolgoznak, amelyekhez nem elhanyagolható parse-olási és fordítási idő is tartozik. Logikus lépés tehát, hogy a böngészők a fő threadet igyekeznek tehermentesíteni, illetve a lehető legkorábban elindítani, a CPU idejének lehető legjobb kihasználásához. Ez JavaScripttel nehezen valósítható meg - bár parse-olással felszabadítható a fő szál egyes fájlok alól, maga a parsing ugyanakkor továbbra is megmarad, amelynek végét meg kell várni a fordítás elkezdéséhez, az pedig ismételten a fő threaden zajlik.

A WebAssembly ezzel szemben eleve kevésbé munkaigényes: annak dekódolása a Mozilla szerint jóval egyszerűbb, mint a JavaScript parsing, ráadásul mind a dekódolás, mind pedig a fordítás elosztható több thread között, a feladat tehát jóval gyorsabban lezavarható. Első körben a streaming compiler lép akcióba, ennek neve lényegében meg is magyarázza a működését: a fájlok letöltésekor a rendszer nem várja meg, hogy az egész fájl lejöjjön, már az első csomag beérkezésekor megkezdi a fordítást - a WebAssembly esetében ugyanis lehetőség van a sorról sorra történő fordításra is, amit a Firefox 58 hamarosan ki is használ, de a böngésző legfrissebb nightly verziójában már most ott van a funkció. Ha a több szálra osztott első szintű, vagy baseline fordítás befejeződött, a kód a fő threaden kezdhet futni, a többi szálon pedig a többszintű fordító második szintje, az optimizing compiler kezdheti végezni a feladatát, vagyis az optimalizált, hatékonyabb kód elkészítését - mikor ez lezárult, a rendszer egyszerűen kicseréli a két kódot a fő threaden, még gyorsabb végrehajtást eredményezve.

Égbe révedő informatikusok: az Időkép-sztori Mi fán terem az előrejelzés, hogy milyen infrastruktúra dolgozik az Időkép alatt, mi várható a deep learning modellek térnyerésével?

A megoldás bár hasonlít, nem egyezik teljesen a JavaScript motoroknál látott kétszintű fordítóknál látottakkal, azok ugyanis a második szintet csak akkor vetik be, ha az adott kód adott részére sokszor szükség van. A WebAssembly esetében az optimizing compiler a teljes kódon átmegy, sőt a cég szerint a jövőben az is lehetséges, hogy a fejlesztőknek a jövőben módjuk lesz majd beállítani, hogy milyen szintű optimalizációt végezzen a fordító. A csiszolással sem érdemes ugyanis túlzásba esni, ahogy a vállalat is kiemeli, a baseline compiler, mint fentebb láttuk 10-15-ször gyorsabban dolgozik a második szintű fordítónál, miközben az optimalizált kód csak kétszer gyorsabb az első körben generáltnál.

Tempó, tempó, tempó

Ezzel a WebAssembly betöltése a fejlesztők szerint CPU-terhelést illetően végeredményben jobban hasonlít majd egy kép dekódolásához, mint a JavaScript betöltéséhez. A Mozilla hasonlata azért különösen helytálló, mert a webes "teljesítménymaximalisták" 150 kilobájt JavaScript láttán már megemelik a szemöldöküket, egy ugyanekkora kép viszont nem zavar sok vizet - ami nem is meglepő, hiszen utóbbi jóval kisebb töltési időt produkál. Összességében tehát a WebAssembly fájlok jóval gyorsabban töltődnek be, mint a megegyező méretű JavaScript tartalmak.

Említést érdemel továbbá, hogy a Mozilla tervei szerint a későbbiekben tovább spórol majd a CPU teljesítményével azáltal, hogy a HTTP cache-be raktározza a letöltött WebAssembly fájlokat, így nem kell azokat az oldal minden egyes frissítésekor újra dekódolni és fordítani. Ugyanezt a JavaScript bájtkóddal a cég már a Firefox 58-cal megkezdi, úgyhogy valószínűleg a WebAssemblyre építő hasonló funkcióra sem kell már sokat várni.