Szerző: Hlács Ferenc

2018. január 18. 16:10

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

A Firefox 58 két új fordítóval érkezik, amelyek számottevően felpörgethetik a WebAssemblyre építő online tartalmak betöltődési idejét - egyre lemarad a JavaScript.

Ú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.

ffoxwa03

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.

ffoxwa02

Mindent vivő munkahelyek

Mindig voltak olyan informatikai munkahelyek, melyek nagyon jól fekszenek az önéletrajzban.

Mindent vivő munkahelyek Mindig voltak olyan informatikai munkahelyek, melyek nagyon jól fekszenek az önéletrajzban.

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.

a címlapról