Android 4.4 bevat experimentele ART runtime-compiler

Google heeft aan Android 4.4 de experimentele ART-compiler toegevoegd. Deze runtime-compiler zou beter presteren dan de huidige Dalvik-compiler. De ART-compiler is vermoedelijk een doorontwikkeling van de DroidBooster-software van het overgenomen FlexyCore.

Dat de ART runtime-compiler nog een experimenteel karakter heeft, blijkt uit het feit dat deze compiler handmatig geactiveerd moet worden in het Developer Options-menu van Android 4.4 KitKat, zo meldt XDA Developers. Als een ontwikkelaar kiest voor de ART-compiler in plaats van de reguliere Dalvik-compiler, dan zal deze gebruik gaan maken van zogeheten OAT-systeembestanden in plaats van Dalviks ODEX-bestanden. Verder bevat de Android 4.4-software de dex2oat-tool, waarmee ODEX-bestanden naar OAT-indeling geconverteerd kunnen worden.

Met de ART-compiler lijkt Google al een aanzienlijk deel van de Android-versneller DroidBooster in KitKat hebben opgenomen. Google kreeg DroidBooster in handen na de recente overname van het Franse softwarebedrijf FlexyCore. DroidBooster zou diverse optimalisaties bevatten ten opzichte van de Dalvik runtime-compiler, onder andere door betere native code af te leveren waardoor de onderliggende hardware beter wordt benut.

Android 4.4 KitKat bevat al diverse optimalisaties om het besturingssysteem geschikt te maken voor apparaten met 512MB werkgeheugen. De ART-compiller lijkt nu ook onderdeel uit te maken van Googles optimalisatieslag onder codenaam Project Svelte, maar het is onduidelijk of deze nieuwe runtime-compiler al in de opvolger van KitKat Dalvik zal gaan vervangen.

Reacties (46)

[Stukfruit]

Link naar een benchmark.

Ziet er erg goed uit Als alles echt twee tot drie keer sneller wordt dan wordt dat straks een leuke gratis upgrade!

[Reactie gewijzigd door Stukfruit op 22 juli 2024 21:42]

[Verwijderd]

Ik zou graag een review met benchmarks willen zien tussen alledaags gebruik met en zonder ART.

[jeroen7s]

ja en geen gebullshit meer dat apple betere hardware gebruikt alleen al omdat apps sneller zijn, want apple hardware loopt wel degelijk achter, ook al draaien apps/games vaak sneller

[Kiwi]

Levert dit dan niet problemen op? Ik weet niet precies hoe het in elkaar zit, maar volgensmij zit dit best diep in het systeem.

Klinkt als een mooie functie, maar toch wel apart dat het via een 'omweg' ingeschakeld moet worden.

[doltishDuke]

Als het goed is, is dat gewoon abstract Zie als een webpagina bezoeken bijvoorbeeld. De browser en de server zijn hetzelfde. Verbinding kan gaan via ADSL, kabel, glasvezel, postduif, WiFi, 3G, noem maar op. Zijn gewoon lagen die ingeschakeld kunnen worden.

^{Overigens, nee, ik kon even echt geen beter voorbeeld bedenken}

Het zal waarschijnlijk nog niet volledig stabiel zijn. Daarom zal de optie standaard nog uit staan. Anders krijg je wellicht dat de telefoon een keer op zijn bek gaat. Voor Tweakers niet zo'n probleem, maar mijn ouders bijvoorbeeld slaan in complete paniek bij een melding dat er een app hangt.

[Reactie gewijzigd door doltishDuke op 22 juli 2024 21:42]

[Carbon]

Wordt onder de ART runtime de Dalvik bytecode naar machinecode vertaalt of net als b.v. met de Erlang compiler naar threaded code?

Nog steeds geen match een native C compiler maar ART kan een aardige performance boost opleveren.

dalvik vm vs art vm

[Reactie gewijzigd door Carbon op 22 juli 2024 21:42]

[jj71]

Nog steeds geen match een native C compiler maar ART kan een aardige performance boost opleveren.

Hoe weet je dat zo precies, kun je een bron noemen waaruit blijkt dat een native C compiler beter code zou opleveren dan de ART compiler?

JIT compilers leveren niet per definitie minder goede code op dan ahead-of-time native compilers. De JIT die in Oracle's JVM zit (HotSpot) bijvoorbeeld doet heel specialistische optimalisaties, onder andere gebaseerd op profile informatie die tijdens runtime wordt verzameld. Een ahead-of-time compiler heeft die informatie niet en kan dat soort optimalisaties dus niet doen. In sommige gevallen is de native code die HotSpot genereert dus efficiënter dan een ahead-of-time native code compiler kan genereren.

(Ik weet zelf geen details over hoe goed Google's Dalvik en ART JITs kunnen optimaliseren).

[Verwijderd]

JIT kan inderdaad efficiënter zijn dan een native C compiler. Wat wel een performance verlies oplevert is de garbage collector. Dit kost gewoon tijd. De stack moet bevroren worden en de references moeten geanalyseerd worden.

Garbage collection heeft wel degelijk voordelen, omdat het de snelheid van software ontwikkelen verbetert en ook de stabiliteit bevordert.

Ook Apple heeft dit geanalyseerd en de meeste crashes op iOS werden veroorzaakt door memory excepties of leaking.

Apple heeft op OSX kort garbage collection gedaan, maar dit na 1 of 2 jaar alweer gestaakt en vervangen door ARC (Automatic Reference Counting).

Dit streeft naar best of both worlds. Simpele software ontwikkeling zonder je al te druk te hoeven maken om memory management, maar niet (onvoorspelbare) performance verlies van de garbage collector, omdat compile time de retain en releases van objecten wordt gedaan.

[Carbon]

JIT kan inderdaad efficiënter zijn dan een native C compiler.

Met sterke nadruk op kan!,
Stel... zowel de C compiler als de JIT genereren de meest optimale code dan zal de native C code nog steeds sneller zijn, domweg omdat de overhead van de JIT compiler ontbreekt.

Garbage collection heeft wel degelijk voordelen, omdat het de snelheid van software ontwikkelen verbetert en ook de stabiliteit bevordert.
Ook Apple heeft dit geanalyseerd en de meeste crashes op iOS werden veroorzaakt door memory excepties of leaking.

Het grote pobleem van garbage collection is dat er constant geheugen wordt gelekt met als gevolg dat er op elk gegeven moment meer geheugen wordt gebruikt dan werkelijk nodig is, uiteraard totdat de GC ingrijpt.

Een ander probleem van GC is dat je geen controle hebt over de aanroep van de destructor, en dat levert interresante problemen op als het object in kwestie een non sharable resource gebruikt.

Apple heeft op OSX kort garbage collection gedaan, maar dit na 1 of 2 jaar alweer gestaakt en vervangen door ARC (Automatic Reference Counting).

Apple heeft inderdaad een gulden middenweg gevonden met ARC.
Bijna alle voordelen van GC maar dan zonder de nadelen.

[Reactie gewijzigd door Carbon op 22 juli 2024 21:42]

[Patrickkkk]

het probleem dat er iets meer geheugen word gebruikt is alleen een probleem als je erg performance kritische applicaties maakt (waar meer geheugen een probleem is). Meestal is het goedkoper om Managed te ontwikkelen en een beetje meer geheugen te kopen. (nu is in .net het verschil ook weer niet mega groot) Vaak is het ook belangrijker om een goede architectuur te hebben dan dat je allerlei optimalisaties doet. Het is dus gewoon belangrijker om de juiste tool op het juiste moment te kiezen.

om maar een oversimplificatie te maken:
- snelle ontwikkeling => managed (persoonlijk: .net)
- performance kritisch => (C++ C)

Het probleem van een non sharable resource word opgelost met een using statement (in .net ik weet niet hoe dit in java gebeurd)

Van ARC had ik nog nooit gehoord, zeer interessant!

[Carbon]

Meestal is het goedkoper om Managed te ontwikkelen en een beetje meer geheugen te kopen.

Beetje lastig op een mobiel device

- snelle ontwikkeling => managed (persoonlijk: .net)

Als je alleen in de MS wereld opereert is .Net een prima keuze.

- performance kritisch => (C++ C)

Mee eens.

Van ARC had ik nog nooit gehoord, zeer interessant!

Objective-C maakt voor geheugenbeheer gebruik van reference counting en voor de komst van ARC was de programmeur verantwoordelijk voor het op de juiste plaats incrementen/decrementen van die reference count en dat werd wel eens teveel gedaan of vergeten.

Onder ARC genereert de LLVM compiler de code voor het incrementen/decrementen van de reference count.
Voordeel: managed memory zonder de nadelen van GC

Meer info: Objective-C Automatic Reference Counting (ARC)

[Reactie gewijzigd door Carbon op 22 juli 2024 21:42]

[Carbon]

[...]

Hoe weet je dat zo precies, kun je een bron noemen waaruit blijkt dat een native C compiler beter code zou opleveren dan de ART compiler?

Zucht.... nogmaals zie: dalvik vm vs art vm

JNI is het resultaat van C compiler!

Een andere bron:
Java(HotSpot) vs Dalvik vs C: android-benchmarks

JIT compilers leveren niet per definitie minder goede code op dan ahead-of-time native compilers.

Klopt.

De JIT die in Oracle's JVM zit (HotSpot) bijvoorbeeld doet heel specialistische optimalisaties, onder andere gebaseerd op profile informatie die tijdens runtime wordt verzameld. Een ahead-of-time compiler heeft die informatie niet en kan dat soort optimalisaties dus niet doen.

Is ook niet nodig want die profile informatie wordt door de HotSpot JIT gebruikt om bepalen of het zinvol is om de bytecode om te zetten naar native code, dat probleem doet zich helemaal niet voor bij precompiled native code.

In sommige gevallen is de native code die HotSpot genereert dus efficiënter dan een ahead-of-time native code compiler kan genereren.

Dat kan, maar dat komt niet door de gebruikte methode (precompiled native code of JIT) maar door betere optimalisaties voor specifieke situaties.

Als je kijkt naar de bekende benchmarks dan zie je dat JIT compilers soms concurrerende tijden neerzetten, probleem is alleen dat real-life code niet uit tight loops met tienduizenden iteraties bestaat.

[Reactie gewijzigd door Carbon op 22 juli 2024 21:42]

[joco]

zie hier heel veel reacties waarvan ik zeg Tja..

En JIT compiler kan echt werk betere code generen dan native, het heeft nu eenmaal veel meer info ter beschikking. op Android weet ik het zo niet maar de laatste hotspot implementaties van Java zelf zijn echt al zeer goed. daarnaast kan een hotspot compiler gebruik maken van de echte cpu/hardware die er in zit. als bv iemand 64 bit Android telefoon uitbrengt, dan draaien direct alle 'gewone' Android apps 64 bit, met ook direct alle register en performance verbeteringen die dat met zich mee brengt.

[Raventhorn]

als bv iemand 64 bit Android telefoon uitbrengt, dan draaien direct alle 'gewone' Android apps 64 bit

Zover ik weet moeten die apps dan wel tegen 64bit (of platform onafhankelijke) libraries zijn gecompileerd, maar het kan zijn dat ik het mis heb en Android zelf 'kiest' welke versie libs het beste is. That is, om écht 64-bit te draaien, en niet (zoals Windows doet) 32-on-64.

En JIT compiler kan echt werk betere code generen dan native, het heeft nu eenmaal veel meer info ter beschikking

Dat neemt alleen niet weg dat performance technisch een JIT-compiler standaard begint met een achterstand van 2-0.
Allereerst omdat een native compiler geen extra overhead genereerd bij het omzetten van bytecode naar 'machinetaal' (oftewel, je zit dichter op het systeem zelf), en als tweede omdat deze geen last heeft van de overhead en performance impact van de GC.
Het heet niet voor niets een VM (Virtual Machine).

Daarintegen moet je met een native taal als C en C++ zelf goed op je geheugengebruik letten, waar dat met Java en bijv. .Net een stuk minder is.

daarnaast kan een hotspot compiler gebruik maken van de echte cpu/hardware die er in zit

En dat kan een native geschreven app niet? Deze zit juist nog dichter op de hardware, dat is ook een van de redenen waarom C / C++ vaak wordt gebruikt in de ontwikkeling van (grote(re)) games, in tegenstelling tot bijv. Java en .Net.
En ik neem aan dat je óf HotSpot, óf JIT compiler bedoeld... HotSpot is namelijk een JIT compiler, maar geen type compiler

[Reactie gewijzigd door Raventhorn op 22 juli 2024 21:42]

[joco]

natuurlijk hoef je niet te compileren tegen libraries
Het is java, het draait in een virtuele machine

Al mijn java apps draaien meteen op een 32 of 64 bit vm. Daar hoef ik niks voor te veranderen. En als ze dus op een 64 bit machine draaien hebben ze ook meteen alle voordelen van die 64 bit machine

Dezelfde app in java geschreven waar niks aan veranderd is kan dus meteen op een 64 bit vm direct 10GB aan memory gebruiken. Geen enkel probleem

Ook de overhead van een GC.... Hoe je ook compileerd naar native toe , de GC blijf je houden.. Dat is nu eenmaal inherent aan java apps. Dus ja de GC heb je niet als je puur C++ doet maar ja dan heb je veel buggier code als je even niet oplet.

Hotspot is niet maar zo een simpele jit compiler, (dus alleen maar just in time snel even compileren) daar zit veel en veel meer in. Dat is echt een state of the art vm. Niet niks voor niks gaan vele scripting talen net daar op werken (ze compileren hun ding naar de vm toe). Want bv we hebben het tegenwoordig over javascript engine's maar die zijn nog lang niet zo ver als waar hotspot is.

En nee, een native geschreven app, compileren 1 keer naar een cpu/hardware waar jij nog net op wilt draaien. Daarna release je dat en dat is het dan.
Maar nu komt intel met een nieuwe cpu, bv met nieuwe AVX instructies, jouw native gecompileerde app gaat niet maar zo die instructies gebruiken. Voor een Java programma die op hotspot executeert hoeft alleen hotspot even aangepast worden (dus een nieuwe java versie) en alle java apps geschreven en gereleased jaren terug gebruiken meteen die nieuwe AVX instructies..

[Raventhorn]

natuurlijk hoef je niet te compileren tegen libraries
Het is java, het draait in een virtuele machine

System libraries zijn óók libraries.
Je compileert dus eigenlijk altijd tegen libraries, tenzij je zelf de noodzakelijke functionaliteiten in al je apps bouwt, maar dat is 'reinventing Java all over again'...

En als je een complexere app bouwt (neem een Java game of enterprise applicatie) dan kom je al snel tot het gebruik van functionaliteit die niet, of niet eenvoudig, in de standaard Java-libraries te vinden is. Of die veel specifieker is dan wat er wordt meegeleverd.
Hiervoor zijn meestal wel third party libraries te vinden, maar ook hiertegen zal moeten worden gecompileerd. (Bijv. Apache Commons Logging)

Dezelfde app in java geschreven waar niks aan veranderd is kan dus meteen op een 64 bit vm direct 10GB aan memory gebruiken. Geen enkel probleem

Zolang er platform independant libraries worden gebruikt is het inderdaad geen enkel probleem. Zodra er echter voor een specifiek platform wordt gecompileerd (of externe libraries via JNI worden gebruikt) is het wel zaak om het goed in de gaten te houden.
32-bit libraries zullen waarschijnlijk in een soort '32-bit emulatiemodus' draaien (zoals WOW64 doet voor 32-bit applicaites op 64-bit Windows), waarbij onder de motorkap function calls en geheugenallocaties worden vertaalt zodat de VM er mee kan werken.

32-bit externe libraries (bijvoorbeeld Windows DLL's) zullen vaak gaan klagen als ze worden gebruikt in een 64-bit VM, waardoor je app waarschijnlijk niet start of flink crasht.

Ook de overhead van een GC.... Hoe je ook compileerd naar native toe , de GC blijf je houden.. Dat is nu eenmaal inherent aan java apps. Dus ja de GC heb je niet als je puur C++ doet maar ja dan heb je veel buggier code als je even niet oplet.

Dat zeg ik...
Al is geheugengebruik (en vooral memory leaks) een groter probleem dan 'buggy code'. Die heb je in iedere taal als je niet oplet.

En nee, een native geschreven app, compileren 1 keer naar een cpu/hardware waar jij nog net op wilt draaien. Daarna release je dat en dat is het dan.
Maar nu komt intel met een nieuwe cpu, bv met nieuwe AVX instructies, jouw native gecompileerde app gaat niet maar zo die instructies gebruiken. Voor een Java programma die op hotspot executeert hoeft alleen hotspot even aangepast worden (dus een nieuwe java versie) en alle java apps geschreven en gereleased jaren terug gebruiken meteen die nieuwe AVX instructies..

Zover ik weet is het vertalen van system calls naar 'cpu calls' een taak van het OS, en niet van de VM of applicatie zelf...
Ik kan er naast zitten, maar zover ik weet wordt er onder water gewoon gebruik gemaakt van de OS-specifieke API's, zowel in bijv. HotSpot als voor je willekeurige C++ applicatie.
Het omzetten van de calls is, volgens mij, de taak van de HAL (Hardware Abstraction Layer).

De compiler compileert vervolgens wel tegen een specifieke versie van de API van een bepaald platform (Linux, OS X, Windows), maar zolang daar niks in veranderd hoeft er in je applicatie ook niets te veranderen.
En nieuwe instructiesets worden ook in C++ applicaties opgepakt zodra het OS ze ondersteunt. Daar zijn de API's voor.

[joco]

hotspot compileerd naar native code toe met de instructies die runtime voor handen zijn

als voorbeeld van een release note van de komende java 8:

http://openjdk.java.net/projects/jdk8/features#164

"Improve the out-of-box AES Crypto performance by using x86 AES instructions when available, and by avoiding unnecessary re-expansion of the AES key."

Dat gaat dus nooit lukken in een taal die je 1 keer compileerd naar native code toe, want dan compileer je tegen veel ouwere processors aan. Die had toen nog geen AES instructies, of moet het speciaal uit programmeren met speciale "paths"

Ik denk niet dat hotspot echt allemaal windows calls doet, dat zou betekenen dat ze op alle besturing systemen die ze draaien een totaal andere implemenatie hebben. (en ze draaien nog al op verschillende besturing systemen).

Maar goed de ART runtime kan hier ook gewoon gebruik van maken, die weet op het moment dat de app wordt geinstalleerd precies waar hij op draait.

De meeste apps voor android zijn pure java apps. Ik gok dat het voornamelijk in de games zit die meer naar native toe gaan.

[lieuwex]

Als je het activeert als gebruiker, zet android dan alle .ODEX bestanden om in .OAT? En wat als je deODEXed bent?

[johnkeates]

Als je op dat niveau met je telefoon aan het kloten bent, dan ben je ook zelf verantwoordelijk voor de consequenties.

Stel dat ODEX->OAT een richting op gaat en niet de andere kant op, dan heb je dus een probleem.

[Jeanpaul145]

Als je op dat niveau met je telefoon aan het kloten bent, dan ben je ook zelf verantwoordelijk voor de consequenties.

Stel dat ODEX->OAT een richting op gaat en niet de andere kant op, dan heb je dus een probleem.

Niet als je telefoon geroot is en je ROM Manager en ClockWorkMod hebt geinstalleerd. ODEX bestanden worden op de telefoon gegenereerd na installatie van een APK, en kunnen bij het booten opnieuw gegenereerd worden wanneer de Dalvik cache is geleegd mbv bijvoorbeeld CWM.

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 21:42]

[Amadeus1966]

Niet echt, mensen die op zo'n niveau aan het "kloten" zijn op hun toestel hebben vaak wel een goede backup achter de hand.
Daarnaast is een reflash bij de meeste toestellen ook zo gedaan.
We kennen geen problemen, slechts uitdagingen ;-)

[cornedor]

Ik heb het maar even uit geprobeerd op m'n N7, een hoop google services blijven crashen, maar tussen het OK klikken door is het mogenlijk om het weer terug te zetten waarna alles ook weer naar behoren lijkt te werken ;-P Dit vereist wel wat snel tappen op je scherm.

[lieuwex]

Als je root hebt kan je dan kijken in /data/apps om te zien of er .dex of .oat bestanden zijn? Bij voorbaat dank!

[SpaceCaker]

het is mogelijk om op device te deodexen dus wat ik denk is dat als de dev-options ziet dat je deodexed ben dat ie de bestanded gaat odexen en dan naar oat
not sure though

[Maatie]

Waarom wordt er door het toestel gecompileerd? Zorgt dat niet voor onnodige vertraging?

[Greveldinges]

Dit gebeurt eenmalig

[Condor70]

Natuurlijk, maar dit hoeft maar 1 keer bij het installeren (en eventueel opnieuw bij een firmware upgrade).

Het grote voordeel is echter dat er specifiek voor die betreffende hardware gecompileerd kan worden wat weer extra snelheidswinst oplevert bij gebruik.

[seapip]

Dit gebeurd maar een keer en daarna staan de gecompileerde bestanden er gewoon voor altijd en hoefen ze niet weer gecompileerd te worden, zou een bak zijn als je os steeds moet compileren als je hem opstart xD

[_geenpunt_]

Om te proberen had ik het aangezet maar nu start Whatsapp niet meer op... iemand anders daar ook last van??

[Paksoy]

Ik denk dat je het moet herinstalleren, zodat de bestanden opnieuw gecompileerd kunnen worden.

[-Bas]

Herinstallatie heeft bij mij geen zin gehad, heb uiteindelijk alles weer moeten herstellen naar fabrieksinstellingen, OPASSEN DUS!

[NinTeNdO_FrEaK]

Waarom optimaliseert google kitkat voor apparaten met 512mb geheugen? Niet dat het niet goed is dat ze een efficient OS maken, maar de toestellen die kitkat zullen krijgen (buiten misschien een aantal oude Nexus toestellen), zullen veelal 1 a 2 GB geheugen hebben.

[basvn]

Ik denk dat 75% van alle Android toestellen low/mid range zijn. Met 512mb/1gb. Door dit nu te doen gaan ze de fragmentatie onwijs tegen! Nu worden er Massa's cheap phones & tabs gemaakt met 4.1 omdat die soepel loopt op goedkopere toestellen.

[divvid]

nu alleen nog zorgen dat al die low/mid range toestellen ook echt een update krijgen. Aangezien dat vaak via de fabrikant loopt zal dat vast niet gebeuren.

eerlijk is eerijk, dat heeft apple toch beter voor elkaar. (heb zelf een huawei -y-300)

[MavhRik]

Als je deODEXed bent heb je geen .ODEX bestanden toch...

Dit is dus een reactie op lieuwex...

[Reactie gewijzigd door MavhRik op 22 juli 2024 21:42]

[Verwijderd]

Hoe veel sneller is dit dan in de praktijk? En in welk opzicht? Loopt het smoother, openen de apps smoother, is hij sneller in ruwe kracht, of van alles een beetje? Zou heel mooi kunnen worden in combinatie met een Snapdragon 800 en ook goed voor de positie van Android tegenover iOS. Lijkt me heerlijk om eindelijk de "mijn iPhone is zo smooth" fanboys hun mond te kunnen snoeren.

[jeroen7s]

in theorie(en 99% ook in de praktijk)
voordelen:
-sneller apps openen
-apps draaien sneller
-efficienter geheugen(geen vm)
nadelen:
-grotere apps(volgens reviews 10 tot 70% groter, vergelijkbaar met ios apps qua grootte)
-tragere installatie
en ja ik hoop het ook stel u voor een galaxy s4 met apps die op native machine code draaien zoals bij ios
ik denk dat er dan niet veel meer overblijft van iphone 5s

[DLGandalf]

Wat is een runtime compiler? Volgens mij is dit geen gebruikelijk term, het kan een virtual-machine zijn, die mogelijk aan Just-in-time compiling doet. (wat in dit geval zeker het geval zal zijn.)

Nasst het runtime gedeelte bestaat het framework misschien ook uit een compiler.

[Reactie gewijzigd door DLGandalf op 22 juli 2024 21:42]