Magyar Opera

Operások írták - Carakan újratöltve

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.

A bejegyzés trackback címe:

https://magyaropera.blog.hu/api/trackback/id/tr581622414

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

penge™ · http://www.thevenusproject.com/ 2009.12.25. 16:14:02

"A gyakorlatban ez azt jelenti, hogy amikor egy olyan programrészt készülünk lefordí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."

Ezt nem vettem észre. Mikor másodszor futtattam le a Sunspidert alig volt változás az eredményben, pedig eszerint már a gyorsítótárazott scripteket nem kellett volna neki újrafordítani.

cousin333 · http://magyaropera.blog.hu 2009.12.25. 16:36:24

@penge™: Nem hinném , hogy pont erre az esetre gondoltak volna. Még az is lehet, hogy szándékosan nem teszi ezen az oldalon. Vagy a tesztszkriptben vannak ez elleni védekezések.

Mesmoryser 2009.12.25. 16:49:37

@penge™: szerintem ez lehet rá a válasz:

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

Vagyis a SunSpider csak azt méri, hogy egy-egy szkript futása során az elejétől a végéig mennyi idő telt el. Ebbe meg ha jól sejtem, nem tartozik bele a fordítási idő.

És két elütés: "egymár", és "véhetőleg". Egyébként érdekes cikk, kösz a fordítást, angolul a felénél elvesztettem a fonalat :)

Steve31 (törölt) 2009.12.25. 17:34:13

Sziasztok!

Kitört nálam a pánik.
Windows98 alatt nem indul el a 10.5-ös.
Használta már valaki sikerrel ilyen op. rendszer alatt?

Karbonade · http://magyaropera.blog.hu 2009.12.25. 18:03:57

@Steve31: Lehetséges, hogy nem indul el Win98 alatt. Gondolom a véglegesre legalább futtathatóvá fogják tenni, de hogy nem optimalizálnak rá, az biztos.

lalolib 2009.12.25. 18:12:52

Elolvastam, de őszintén nem értettem belőle semmit... Persze, ez az én hiányosságom. :)

Koenigsberger 2009.12.25. 20:46:02

A funkció függvényt jelent, ha ez segít.
:D

Lefordítom: az Opera jobb lett, [mert bla és blabla, továbbá blablabla] és a jövőben csak még jobb lesz. ;)

bazsı' 2009.12.25. 21:07:16

Lassan Java lesz a JavaScriptből :)

penge™ · http://www.thevenusproject.com/ 2009.12.25. 21:12:07

@Bɑzsi: Amilyen gyors már rég meg is előzte. :DD

cousin333 · http://magyaropera.blog.hu 2009.12.25. 21:42:43

@Mesmoryser: Kösz a korrekciót. Egyes pontokon én is majdnem feladtam :).

cousin333 · http://magyaropera.blog.hu 2009.12.25. 21:45:11

Az utolsó mondat nagyon kemény. Igaz, hogy épp most nyomtuk le az eddigi bajnokot, de még nem az igazi a kicsike. Mint a Taxi című filmben, amikor a németekkel versenyez és éppen megverte őket: "kösz a fogadást, és most megyek is a garázsba megbütykölöm egy kicsit a verdát, mert nem gyorsul úgy, ahogy szeretném..." :)

ZeGa 2009.12.26. 09:52:14

@cousin333: Ja vagy miután második verseny előtt azt monjda, hogy bocs, de múltkor behúzva maradt a kézifék...

maximan 2009.12.27. 01:44:45

Remélem Linux alá is kiadják hamarosan :S

Ómájgád 2009.12.27. 10:57:48

Nem tudjátok hogy lehet a Bookmarkok frissítését kérni? Valamiért rossz könyvtárszerkezetben olvasta be a meglévő BM-okat, kitöröltem őket, azóta sehogy sem akarja még1x beolvasni.

Steve31 (törölt) 2009.12.27. 13:46:03

Ez az, végre érthetően, magyarul van!!!
:-)

>Koenigsberger 2009.12.25. 20:46:02
>A funkció függvényt jelent, ha ez >segít.
:D

>Lefordítom: az Opera jobb lett, [mert >bla és blabla, továbbá blablabla] és a >jövőben csak még jobb lesz. ;)

penge™ · http://www.thevenusproject.com/ 2009.12.29. 09:47:01

Remélem 8.-án már kapunk egy új snapshotot.

ZeGa 2009.12.30. 09:59:56

Vagy akár kiadhatnának egy újat újév első napján, amit esetleg már előre megcsináltak :)

Saint-Germain 2009.12.30. 16:39:07

Évek óta élek együtt az Operával, de
most kicsit zavarba ejtett:

VALAMI FIGYELMETLEN LÉPÉSEMRE ELTŰNT A
FŐMENÜ SORA!
Órák óta küzdök itt az infókkal,
még újra is telepítettem, hiába.

Kérlek, VILÁGOSÍTSATOK MEG,
hogyan tehetem láthatóvá ott legfelül
azt a néhány varázsszót, hogy
Fájl Szerkesztés Nézet Könyvjelzők stb.

Köszönöm előre ishhh!

Saint-Germain 2009.12.30. 16:48:48

HUhhh... :) ez elkerülte a figyelmemet.
Nagyon hálás vagyok!
És maradok Opera szerelmesssss.
süti beállítások módosítása