A nemrég megjelent Opera 10.5 pre-alfa verziójának sztárja egyértelműen az új, Carakan névre hallgató JavaScript motor volt. Úgy gondolom, hogy a fejlesztőik megérdemelnek annyit, hogy teljesítményüket bemutathassák, és azt mindenki megismerhesse. Át is adnám nekik a szót...

Ez a bejegyzés a "Carakan Revisited" című cikk fordítása. Az eredeti cikk 2009. december 22-én jelent meg a Core blogon.

Kicsi több mint egy év telt el azóta hogy elindítottuk a Carakan-projektet, ami az Opera ECMAScript végrehajtási sebességének drasztikus növelését célozta, és most jött el az első fejlesztői kiadás ideje.

Amit bő egy éve elkezdtünk implementálni, az - ahogy azt már a Carakanról szóló korábbi bejegyzésemben is írtam - egy új keresztplatform bájtkód-értelmező az új, regiszter alapú utasításkészlethez, egy új belső objektummodell automatikus osztályozással és belső tulajdonság-gyorsítótárral, és egy gépi kód generáló. És mi mindezt elkészítettük, sőt, ennél többet is.

Az új bájtkód-értelmező és az új objektummodell keresztplatform fejlesztés, ami azt jelenti, hogy minden hardveres platformon működik, amire az Operát átültetjük. Ezek önmagukban is jelentős teljesítmény-növekedést jelentenek a korábbi Futhark motorhoz viszonyítva, amiket a jelenlegi Operákban alkalmazunk.

Egy átlagos asztali gépen a Carakan bájtkód-értelmezője a SunSpider teszten körülbelül három és félszer gyorsabb, mint a Futharké, és korai tesztjeink az ennél kisebb teljesítményű processzorokkal üzemelő beágyazott rendszerek esetében még nagyobb előnyt mutatnak a Carakan javára.

Az optimális sebesség elérésére azonban a gépi kód generálás (másképpen JIT - Just In Time, [azaz futásidejű generálás]) a helyes megközelítés, és erre összpontosítottuk az optimalizációs munka nagy részét is.

A Carakant felszereltük egy forrópont (hot-spot) detektáló JIT fordítóval, ami olyan gépi kódot fordít, ami a legkomplexebbek kivételével minden utasítást képes végrehajtani a bájtkód-értelmező meghívása nélkül. Ez a technika ötvözi a kód fordítás-időbeli (compile-time) statikus analízisét és a bájtkód-motor futásidejű állítását az optimális bájtkód generálása érdekében, különös tekintettel az aritmetikai számításokra.

A motor funkció-beágyazásokat is végez (function inlining), mind a beépített funkciók (például Math.sqrt() négyzetgyök-vonáshoz), mind programozó által készített funkciók esetén. A JIT fordító jelenleg csak 32 illetve 64 bites x86-os gépi kódot generál, de idővel további architektúrákat is támogatni fog, az ARM-al kezdve a sort.

De nem csak ennyit tettünk a Carakan projekt során. Szeretnék megemlíteni két másik érdekes fejlesztést, amit implementáltunk: az "osztott szemétgyűjtött halmot" (garbage collected heap), és a fordított szkriptek gyorsítótárazását. [Az előbbi angolul is olyan hülyén hangzik ám, mint magyarul... A "halom" az objektumok egy speciális fa-struktúrájú ábrázolása.]

Osztott szemétgyűjtött halom (divided garbage collected heap)

Az ECMAScript nyelv feltételezi egy olyan szemétgyűjtő (garbage collector) létét, ami automatikusan felszabadítja a már nem használt memóriaterületeket. A Carakan szemétgyűjtője sokban hasonlít a Futharkéra: egy egyszerű megjelöl-és-kisöpör (mark-and-sweep) felépítés; csak néhány apróbb, de igencsak hatékony változtatást végeztünk el rajta a teljesítmény növelése érdekében. Drasztikusan megváltoztattuk viszont a szemétgyűjtő használatának módját.

A Futhark esetén az ECMAScript motor által a szkripteknek lefoglalt összes memóriát (bármelyik fülhöz tartozott is) egyetlen megosztott halomban tároltuk el [mármint a területek nyilvántartását], így minden alkalommal, amikor a memória felszabadítása érdekében szükség volt a szemétgyűjtő futtatására, az végigellenőrizte az összes memóriát. Minél több fül volt megnyitva, annál lassabb volt a szemétgyűjtés.

A Carakan esetén sok kisebb halmot használunk. Minden új fülön, keretben (frame) vagy beágyazott keretbe (iframe) betöltött dokumentum saját halmot kap. Mivel a különböző dokumentumokban futó szkripteknek időnként hozzá kell férniük egymás objektumaihoz, a Carakan beépített támogatással rendelkezik két halom összevonásához, illetve annak eldöntéséhez, hogy ez egyáltalán szükséges-e.

A felépítés előnye egyértelmű: a kisebb halmok miatt minden szemétgyűjtésnek kisebb az erőforrás-igénye. Mivel a szemétgyűjtést csak olyan halmokon kell elvégeznünk, amikből memóriát foglaltunk le, automatikusan csak az aktív halmok memória-területein kell végigmennünk, minden más halmot kihagyhatunk. Végeredményül azt kapjuk, hogy nem számít, hogy 1 vagy 100 fül van-e nyitva, ha egy szkript aktiválja a szemétgyűjtőt, az erőforrás-igény mindig nagyjából azonos marad.

Fordított programok gyorsítótárazása

Az ECMAScript-motorok felépítéséből adódik, hogy a sebességtesztek gyakran nem mérik a fordító teljesítményét. A Futharkhoz viszonyítva a Carakan fordítója sokkal inkább összpontosít a program elemzésére és a gyorsan futtatható bájtkód generálására, emiatt bizonyos esetekben lassabb lehet annál. Ez egy szándékos kompromisszum volt a részünkről.

A Futhark rendkívül hatékony fordítója helyett a Carakan gyorsítótárazza a lefordított programrészeket. A gyakorlatban ez azt jelenti, hogy amikor egy olyan programrészt készülünk fordítani, amit nem sokkal korábban egy másik szkript kapcsán már lefordítottunk, akkor ismét az előző fordítás kimenetét használjuk fel, és teljesen elhagyjuk az ismételt fordítást. Ez a módszer nagyon hatékony lehet bizonyos böngészési környezetekben, például amikor az ember sok egy adott honlapon barangolva egymás után tölti be az oldalakat, mivel az egyes oldalak ilyenkor jórészt ugyanazokat a szkripteket futtatják le újra és újra egy nagy saját könyvtárból.

Tervek a jövőre vonatkozóan

Noha már közel járunk a Carakan motor kiadásához, nem tervezzük a fejlesztés befejezését. Rengeteg kisebb-nagyobb ötletünk van, és tervezzük a JIT fordító portolását más architektúrákra is.

Az egyik terület, ahol vélhetőleg nagyot tudunk majd előre lépni, az a memóriahasználat, mégpedig egy hatékonyabb objektum-ábrázolás használatával. A Carakan bizonyos esetekben már ma is kevesebb memóriát igényel, mint a Futhark, azáltal, hogy az automatikus objektum-osztályozó rendszer megosztja az információkat a hasonló objektumok között, illetve a "másolás írás esetén" (copy-on-write) sémát használja szövegadatok megosztása esetén. De vannak olyan terveink, amik megvalósításával az ECMAScript objektumok méretét akár a jelenlegi tizedére is képesek leszünk lecsökkenteni.

Szeretnénk továbbá növelni a nem aritmetikai kódokból, például tulajdonság-lekérdezések kapcsán generált gépi kód sebességét, mert itt még egyáltalán nem értük el az aritmetikai utasítások esetén tapasztalható teljesítményt.