JIT fordítóval gyorsulhat az Android 2.2

Google

Az androidandme.com már februárban arról írt, hogy az Android-ot futtató eszközök jelentős teljesítménynövekedést könyvelhetnek el ebben az évben, ha megérkezik a Google mérnökökből álló csapat által fejlesztett Dalvik JIT Compiler. A weboldal nemrég arról számolt be, hogy Ian Douglas, az Armor Games fejlesztője olyan Android 2.2-n futó Linpack benchmark eredményeket ábrázoló képernyőképeket publikált, amelyek azt sugallják, hogy jelentős teljesítménybeli javulást hozhat a JIT fordító bevezetése. Míg egy normál Nexus One körülbelül 6-7 MFLOPS eredmény elérésére képes, addig ugyanaz a vas Android 2.2-t futtatva már akár 38-40 MFLOPS-t tud. Az oldal reméli, hogy a Google csapata közel van ahhoz, hogy stabil verziót adjon ki a Dalvik JIT Compiler-ből. Erre utalhat az a tény, hogy a nemsokára megrendezésre kerülő Google IO rendezvényen Ben Cheng és Bill Buzbee bemutatják munkájukat egy, a "A JIT Compiler for Android’s Dalvik VM" című előadásban. A részletek itt.

( pepo v | 2010. 05. 18., k – 06:48 )

Akkor lennék boldog, ha végre az Android Pulson is lehetne futtatni 2.2-őt.

( lovas | 2010. 05. 18., k – 09:37 )

Én azon lepődtem meg, amikor először olvastam erről, hogy eddig nem volt JIT.

Andriod nem JVM-et használ, hanem DalvikVM-et. Lényegében köze nincs a megszokott Java-hoz, leszámítva a nyelvet. (Más lib-ek stb.)

Eddig nem volt JIT-es, csak valami JIT kezdemény volt kikapcsolva a forrásban, amit pár ROM-ban bekapcsoltak, de eléggé instabillá tette a rendszert.

Mivel a platform alacsonyabb szintjei C-ben és C++-ban vannak, hatalmas gyorsulás nem várható maximum ilyen szintetikus benchmarkokban mint a LINPACK.

(Mondjuk valaki lefordíthatná C-ben is, kiváncsi vagyok az milyen eredményeket produkálna.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Márpedig a videokból lényeges gyorsulás jön le.
Régebben volt egy hír arról, hogy lényegében azonos vagy jobb hardveren mint az ájfón, kb fele-harmad akkora teljesítményt nyújt az android játékokban. A kezelőfelületen ez nem volt annyira látványos, de állítólag ott is gyorsabb.
/Cég is volt aki demózott androidot saját java motorral és kb. hasonló teljesítmény növekményt mutatott a rendszer. Fel is ajánlották gugliéknak./
Nos most akkor ezzel behoznák....
A JIT-el gyorsulhat szerintem jelentősen. Elmaradt optimalizáció pótlása pl. Gugli annak idején rohammunkában dobta össze az androidot cél a stabilitás elfogadható sebesség mellett és persze az elvárt funkciók nagyrészének teljesítése. Az optimalizációra JIT-re nem maradt idő talán.
Viszont C átírás nem sokat lendítene, hup-on is volt polémia erről számtalanszor kb. olyasmi ha jól optimalizált a java kód bizony futás időben nem nagyon marad el a C-től.

"Márpedig a videokból lényeges gyorsulás jön le."

Melyik videóból? (Az eddigi (bugos) JIT-et használók is csak minimális gyorsulásról beszéltek (kicsit gyorsabb alkalmazásindulás, kevesebb lag. De nem 450%...))

"kb fele-harmad akkora teljesítményt nyújt az android játékokban"

Aki komolyan gondolja a játékfejlesztést az eleve nem kezdi Java-ban (Android alatt).
Egyébként ami hírre én emlékszem, az sem Java teljesítményt mért.

"Cég is volt aki demózott androidot saját java motorral"
Melyik, hol? Én csak C#-os mono-ról tudok.

"Viszont C átírás nem sokat lendítene, hup-on is volt polémia erről számtalanszor kb. olyasmi ha jól optimalizált a java kód bizony futás időben nem nagyon marad el a C-től."

Sun Java (vagy hasonló) használatával, szerver beállításokkal (sok RAM-mal). Ez meg itt az első (publikus) JIT próbálkozás a DalvikVM-ben (egy mobilon).
A C verzió megmutathatná, hogy mit tud a CPU, és mennyire fejlett ez a JIT jelen pillanatban.

Szerk:
Nexus One Linpack eredmények:
gyári: 7 MFLOPS
régi (bugos) JIT: 19 MFLOPS
Új JIT: 40 MFLOPS

Látom én a fejlődést, de ha az előző JIT nem hozott 200%-os általános gyorsulást akkor ez sem fog. (Ettől függetlenül ez jó dolog, örülök neki, de csodát senki se várjon...)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"Régebben volt egy hír arról, hogy lényegében azonos vagy jobb hardveren mint az ájfón, kb fele-harmad akkora teljesítményt nyújt az android játékokban."

Amiről te beszélsz, az egy C++-ban megírt játék engine, semmi köze a Dalvik-hoz:
http://hup.hu/cikkek/20100215/gyorsabb_a_3d_grafika_az_iphone_3gs-en_mi…

Két dolgot tegyünk hozzá. Egyrészt a 3D az külön terület, ha van hardveres gyorsítás a telefonban, akkor hasít, ha nincs, akkor nem hasít, ez teljesen független a platformtól: az iPhone 3GS 28 millió Mtps-t tud, a Google Nexus One 21 Mtps-t, a Samsung Galaxy S ( http://en.wikipedia.org/wiki/Samsung_i9000_Galaxy_S ) pedig majd 90Mtps-t tud.

Másrészt az iPhone nem szoftverplatform, hanem hardverrel együtt jön, csak egyetlen hardverre kell illeszteni, az Android pedig bárhol tud tudni az autók fedélzeti kijelzőjétől kezdve a mobilokon át a netbook gépekig. Teljesen más cserélhető driveren és legalább egy absztrakciós rétegen át kezelni a hardvert, mint kvázi közvetlenül.
--
http://wiki.javaforum.hu/display/FREEBSD

Ahja. Nyilván azért tud 90 millió pps-t a Samsung Galaxy S, mert fényeztek az áteresztő képességen, és nem azért, mert olyan GPU van benne. A PowerVR chip az dísznek van, ezekben az eszközökben... mennyit is tud az iPhone 3GS, 28 Mpps-t? Milyen PowerVR chip van az iPhone 3GS-ben, SGX535? Mennyi Mpps-t tud az SGX535, 28-at? Micsoda meglepetés... :)

Amikor feltöltöd a vertex buffert és a texture buffert onnan a CPU-nak nincs sok dolga, minden azon múlik, hogy a GPU mennyi háromszöget tud textúrázni. Például a Samsung Spica igen gyér 3D tudással bír, a vertex és a texture buffer feltöltése 2-300us, a textúrázott frameDraw pedig 30-50ms, pedig ebben is egy 800MHz-es CPU van, és mégis malmozik.

Én elhiszem, hogy a CPU, a RAM és a GPU közötti áteresztő képességen múlik minden, de akkor kérek mérési eredményeket.
--
http://wiki.javaforum.hu/display/FREEBSD

Ahha. Nyilván a Neon az, ami javítja az áteresztőképességet... :)

A Nexus One hardverének elvileg erősebbnek kellene lenni jóval a 3GS-től. De nem az...

A Nexus One-ban lévő Snapdragon integrált 3D gyorsítást tartalmaz, az iPhone 3GS esetén pedig külön chip végzi ezt a munkát. A Snapdragon chip 22 Mpps-t tud a specifikáció szerint, és ennyit is lehet mérni a Nexus One esetén, ami kevesebb, mint az SGX535 28Mpps tudása. Nem a CPU sebessége számít, hanem a GPU sebessége. Miért is kellene _elvileg_ 3D-ben erősebbnek lennie?
--
http://wiki.javaforum.hu/display/FREEBSD

Bocsánatot kívánok, de éppen Te tűnődtél el azon, hogy egy adott mérés során a Nexus One miért tud csak 21fps-t 1Ghz-es Snapdragon CPU-val, ellenben az iPhone 3GS miért tud 29fps-t 600MHz-es CPU-val:

8 animált 3D modell esetén ez a szám 29 (3GS) és 21 fps-re (NO) változott.

Amikor leírom, hogy a Snapdragon 22Mpps-t tud, az SGX535 pedig 28Mpps-t, akkor én vagyok a hülye, mert a specifikáció számait hozzák a készülékek.

Leállították a nyolc karakter csont alapú animációját, hogy a CPU-t ne terheljék és a GPU dolgozzon. Azonban a frame rate ekkor sem változott.

Micsoda meglepetés. Én kérek elnézést.

Hajrá, győzköd csak magad, hogy a GPU-n kívül semmi más nem számít! :)

Egyrészt azt találtam mondani, hogy a CPU az ideje nagy részében malmozik a GPU mellett. Másrészt mérnök vagyok, megnéztem a specifikációkat, illetve ezt tapasztaltam az OpenGL programom kapcsán is. Harmadrészt Te is ezt írtad három hónapja. Negyedrészt csókoltatom a Distinctive Games fejlesztőit, ők igazi fejlesztők: nem érdekli őket, hogy mennyi és milyen chip van az eszközben, kijelentik, hogy a Nexus One erősebb hardver, mert 1Ghz az órajele, szarnak bele, hogy a mérési eredmények erősen hasonlítanak a hardver specifikáció adta tudására. Ötödrészt felülsz nekik, aztán foggal-körömmel véded az állításod.

Szóval én befejeztem, ha a tények nem győznek meg, akkor semmi.
--
http://wiki.javaforum.hu/display/FREEBSD

Tisztelt mérnők úr! :) A fenti cikket átvettem más szaklapoktól. Alapvetően igazad van, de túl sok platform ment már át a kezemen ahhoz, hogy ne higgyek az ilyen fekete-fehér kijelentésekben (benchmarkokban), így szeretném látni azokat a teszteket is, amik a Galaxy S-t, vagy valamelyik másik SGX chip-es, Androidos telót nyúzzák, mielőtt sűrű mea culpázásba kezdek és kijelentem, hogy a GPU a szűk keresztmetszet (ami jelen esetben valószínüleg igaz). ;)
Rövidesen lehetőségem lesz pár hasonló tesztre, akkor majd összedobok valamit a személyes tapasztalataimról. De tényleg zárjuk le...

Bocsánatot kívánok, de az Android nem JVM, a Java-hoz annyi köze van, hogy a nyelv azonos, illetve a megszokott API jó része azonos. Ezen kívül minden más... nem minden VM tartalmat JIT-et. :)

Nem marketing fogás, ennyi ideig tartott lefejleszteni a JIT-et, ami a 2.x sorozattal jött volna, de nem készült el addigra. A sok 2.x verzióban megjelenő fityfene pedig alapozott arra, hogy lesz JIT, de nem lett.
--
http://wiki.javaforum.hu/display/FREEBSD

Mobilos JVM-ekben nem szokas a JIT. A par evvel ezelotti telefonokon se eleg memoria sem eleg kakao nem volt egy emberi sebesseggel mukodo JIT forditohoz. J2ME-n sincs. BlackBerry-n se. Azota meg annyi tortent, hogy a mobil hardverek elszalltak felfele teljesitmenyben es memoriaban, de eddig ez a szoftveres oldal valtoztatasa nelkul is gyorsitott annyit, hogy ne kelljen pl. a VM-hez nyulni. A Google elso korben az igy sem eleg gyors cuccokat ugy "oldotta meg" hogy kinyitotta a platform alatti layert (a Linuxot). A problema ezzel, hogy pont a JVM jelentette biztonsagot es egysegesseget vesziti el a rensdzer. A masodik korben (ezt tovabb tart lefejleszteni, nyilvan), meg jonnek a JIT-es dolgok.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Én 2005-ben HotSpotos JVM-et láttam a Siemens telefonok forrásában (nem smartphone), tehát igenis megszokott dolog a JIT. :)
Azt nem tudom, hogy BB-n van-e, de nagyon meg lennék lepve, ha nincs.
A JIT-től teljesen független, hogy egy adott mobilplatform engedi-e a natív kódok használatát. Gyakorlatilag a BB az utolsó olyan elterjedt smartphone platform, ahol erre nincs lehetőséged 3rd party fejlesztőként. Ez nem csak teljesítmény szempontból fontos, hanem rengeteg előregyártott komponens használatához nyitja meg az utat, ami egy pusztán Java/VM alapú megoldásnál nem fog működni.

Üdv,
Gergely

Hát ha van a BB-ben JIT, akkor elég pocsék a teljesítménye, maradjunk annyiban... Egyébként nem tudom te mit láttál Siemens telefon kódot, de nálunk - játékfejlesztőknél - a Siemens telefon kb. szitokszó volt... :) Szóval az egy dolog, hogy van-e benne JIT... Amúgy technikailag persze független egymástól, hogy egy JVM-ben van-e JIT és mellette van-e bármiféle natív kód futtatási lehetőség, de nem is arról beszéltem, hogy technikailag, hanem hogy "politikailag" hogyan függtek egymástól ezek az elmúlt 1-2 évben.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( bartamate | 2010. 08. 08., v – 18:32 )

elvileg 1 hete elérhető az update de nekem nem jelzi a telefon

valakinek van ötlete?