Code wijst op vervangen Dalvik door ART-compiler in volgende versie Android

Een stuk broncode van het Android-besturingssysteem wijst erop dat Google van plan is om in een volgende versie van zijn mobiele OS de Dalvik-compiler te vervangen door de ART-compiler. Momenteel is deze compiler, die het runnen van apps sneller moet maken, experimenteel.

De bewuste code is online gezet in de Git-repositories voor Android-broncode en is geschreven door Google-medewerker Brian Carlstrom. Uit de beschrijving wordt duidelijk dat de code bedoeld is om de ART-runtime-compiler standaard te maken en Dalvik, die sinds jaar en dag zijn werk doet in Android, uit te zetten. Wel lijkt Dalvik met de getoonde code aanwezig te blijven in het mobiele besturingssysteem van Google.

ART moet er voor zorgen dat apps sneller gerund kunnen worden binnen het Android-besturingssysteem. Eén van de nieuwigheden is dat ART ondersteuning heeft voor ahead of time compiling, terwijl Dalvik werkt met just in time. Ook zou ART betere native code afleveren waardoor de onderliggende hardware beter wordt benut. De software is gebaseerd op DroidBooster, de Android-versneller die eerder in handen kwam van Google.

Een experimentele versie van de ART-compiler werd door Google meegeleverd in Android 4.4. Daarbij moesten geïnteresseerden deze zelf aanzetten via het ontwikkelaarsmenu in Android, dat standaard verborgen is. Omdat apps geschikt gemaakt moeten worden om te werken met ART, is het aannemelijk dat Google met het meeleveren ervoor wilde zorgen dat ontwikkelaars zich hierop voorbereiden. Het is vooralsnog onduidelijk wanneer en hoe Google de verandering van Dalvik naar ART wil doorzetten. De internetgigant heeft hier namelijk nog niets over bekendgemaakt.

Reacties (113)

[Verwijderd]

Omdat apps geschikt gemaakt moeten worden om te werken met ART, is het aannemelijk dat Google met het meeleveren ervoor wilde zorgen dat ontwikkelaars zich hierop voorbereiden.

Dit is niet waar.
In principe is ART gewoon 100% compatible met Dalvik, en zou de code niet aangepast hoeven worden.
Het is alleen zo dat ART nog niet helemaal volwassen is, en er dus hier en daar nog wat bugs zijn, waardoor sommige apps niet, of niet goed werken met ART. Maar in principe zou dat opgelost moeten worden door aanpassingen aan ART zelf, niet aan de apps (of er moet toevallig iets heel raars in zo'n app zitten waardoor het eigenlijk ook niet op Dalvik had moeten werken).

Ik gebruik ART zelf al een aantal weken, en ik moet zeggen dat het met de compatibiliteit best goed zit. Alleen de Sound Search service geeft bij mij nog problemen, al m'n andere apps en services werken goed. Wel is er af en toe wat lag bij sommige grotere apps (zoals Facebook of Skype), en moet je voor sommige apps eerst rebooten als je ze van de telefoon naar je SD-kaart verplaatst.

[Verwijderd]

Wat is dan volgens jou de reden dat Google de nieuwe compiler/VM meelevert?

[Verwijderd]

Zodat developers met ART kunnen testen en eventuele compatibiliteitsproblemen aan Google kunnen doorgeven.

Mijn eigen code werkte in ieder geval zonder problemen met ART.

[Verwijderd]

Met de door Qualcomm gepatchte Dalvik en Bionic, werkend op KK 4.4.x apparaten met Snapdragon CPU, worden (waaronder op mijn Nexus) betere resultaten gehaald dan met ART. Maar ART zal zeer goed mogelijk een grote sprong maken bij de volgende versie.

http://forum.xda-develope...optimized-dalvik-t2546120

[Verwijderd]

Het blijft achterhaald om software in een platform neutraal formaat aan te bieden om dan telkens opnieuw door de miljarden handsets opnieuw te laten compileren. Waarom niet eenmalig compileren naar een betreffend formaat en deze binaries dan centraal ter download aanbieden waarbij de handset aangeeft welk type binary vereist is? The horror of die miljarden needless compiles,hoeveel energie kost dat wel niet?

[Dreamvoid]

Tsja, toch is iedereen laaiend enthousiast over platformonafhankelijke HTML5/Javascript webcode die op elk device in een runtime draaien.

[Verwijderd]

Totdat je multithreaded dingen wil gaan doen, dan wordt het ineens minder leuk.

[RangedNeedles]

Bekijk de in HTML5 geïntroduceerde web workers eens
http://www.w3schools.com/html/html5_webworkers.asp

[Verwijderd]

Probleem met die webworkers is dat er geen "shared address space" is. Dat wil zeggen dat als je wil communiceren tussen webworkers, je je hele data structuur telkens moet serialiseren...

Bovendien hebben webworkers geen toegang tot de UI, dus even iets renderen in de achtergrond is er ook niet bij...

Het is best wel beperkt dus.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:49]

[RangedNeedles]

Oh, dat wist ik niet, excuseer. Ik heb er zelf nog niet mee gewerkt, maar ben dat wel eens van plan te doen

[Verwijderd]

HTML5/Javascript en dan ook Javascript op de ServerSide met NodeJS. Gecombineerd met wat leuke CSS frameworks. Jup Zeer nice.

[Qws]

Serverside => Javascript (Node.JS)

[K_VL]

Je hebt dan duizenden verschillende binaries nodig, waarbij je afhankelijk bent van een derde of die het wel of niet voor jou device heeft gecompileerd.
Al deze binaries moeten ook nog ergens opgeslaan worden => kostprijs voor de aanbieder!

Misschien moet je dit toch best eens lezen: http://nl.wikipedia.org/wiki/Just_in_time_compilatie

[Reactie gewijzigd door K_VL op 23 juli 2024 23:49]

[mvdejong]

The horror of tenthousand binaries, and the problem of keeping every app up to date for every new version of every new phone.

Het voordeel van de huidige aanpak is dat je app-package voor de meeste devices geschikt is.

[Verwijderd]

Met intel en arm binaries ben je er. Nu wordt alles in dalvik bytecode opgeslagen en native gecached. Dus het neemt ook meer ruimte in op de handsets terwijl er voor storage van binaries vrijwel onbeperkt ruimte is in de cloud.

[dtech]

Met intel en arm binaries ben je er niet, er zijn ongeveer 7 versies van de ARM instructieset elk met een aantal varianten en additionele instructies. Je moet dus een afweging maken tussen: compatibiliteit van je binary, aantal binaries en hoe goed je gebruik maakt van de mogelijkheden van de CPU.
Als je op een redelijk aantal (zeg Android 2.3+) telefoons de maximale performance wilt krijgen zit je toch tegen 20+ binaries aan.

Je cache argument slaat trouwens nergens op: programmacode is zeer klein in vergelijking met bijvoorbeeld plaatjes (de ruimte van apps is maar voor een klein deel echt executables) en je zou bij native code ook al programmacode op moeten slaan, dus de cloud heeft er niks mee te maken.

Overigens kan je op Android ook gewoon Native code draaien als je dat graag wilt, 3D games doen het bijvoorbeeld vaak.

[Verwijderd]

Je hebt ARM v7 en ARM v8 en Intel, volgens mij zit Android qua handsets nog volledig op 32 bits ARM v7, in 2014 komt ARM v8 zo is de verwachting. Intel speelt een ondergeschikte rol op dit moment.

Dus ik tel 3 binaries. Google kan makkelijk 3 binaries in zn Google play store opslaan, en het compileren naar binaries kan eenmalig op een krachtig workstation gebeuren.

Vervolgens klikt de gebruiker met zn handset aan welke applicatie hij wil en de de Google play store streamt de juiste binary naar de gebruiker.

Geen miljarden compiles meer nodig, geen java bytecode overhead meer, geen extra storage benodigd op de handset om de just-in-time/before-time compiles uit te voeren.

[mvdejong]

Je bent nog steeds hard een oplossing aan het zoeken voor een probleem dat niet bestaat, ten kost van compatibiliteit en flexibiliteit, de reden voor de huidige gekozen oplossing.

Maar als je dan zo'n hekel hebt aan JIT-compilaties, kun je beter voorstellen dat de installatie van een app gaat bestaan uit het compileren van de source of een intermediate code naar native code, dan heb je nog steeds maar 1 compilatie-slag, maar je heb geen last meer van de vendor/version-lockin waar jij naar streeft.

[Verwijderd]

Ja, een JIT in de Cloud op basis van de architectuur van de handset die de app download, ben je dan tevreden? Mag de cloud dan alsjeblieft ook een cache van de binary bewaren als blijkt dat dezelfde ISA ongeveer een miljard keer langskomt of moet de Cloud energie blijven verbranden om elke zelfde ISA handset nodeloos van een vers gebakken binary te voorzien?

[mvdejong]

Geen JIT, geen Cloud, gewoon op het device zelf. Wat nu gedaan wordt in JIT, zou je dan eenmalig doen en op je device opslaan als een native-code binary, waarna de aangeleverde source/intermediate-code weer kan worden opgeruimd. Het enige probleem is dat de native binary mogelijk groter is dan wat er nu aangeleverd wordt, maar dat verschilt niet van het effect van jouw oplossing.

Je zou voor bepaalde devices (ofwel de hele populaire, ofwel degene met zo weinig resources dat de compilatie daar moeilijk te doen is) kunnen besluiten een repository van binaries te maken, maar de administratie en opslag daarvan lijkt me niet opwegen tegen het voordeel.

O ja, en we focussen nu voor je binaries erg op de hardware, maar hetzelfde feature-/compatibiliteits-verhaal krijg je ook nog met je OS-versies. Ook daar heb je bepaalde API's die soms dermate veranderen dat een binary-code executable voor de ene versie niet meer compatible is op een volgende versie. En natuurlijk zijn er naast Android en Windows nog wel andere OS-en in de mobiele wereld, zullen we die ook maar direct uitsluiten voor de apps ?

[Reactie gewijzigd door mvdejong op 23 juli 2024 23:49]

[Verwijderd]

Interessant je laatste opmerking over 'API verschillen', denk je niet dat Google Play Services juist in het leven geroepen is om deze verschillen weg te abstraheren?

Voor mij staat het vast : de ART compiler zal op termijn naar de Google play store cloud migreren, de Google apps zullen in de cloud ahead of time naar de handset in native formaat gecompileerd worden
(cached want er zijn maar zeer weinig verschillende ISA's in de handset space, je gaat niet telkens opnieuw compileren als de binary al voorhanden is, zonde van de energie).

De Google play services laag zal effectief de nieuwe Android API zijn. Android verdwijnt naar de achtergrond, het is alleen nog firmware voor handsetvendors om de Google play services laag op de eigen hardware te ondersteunen.

Voor de nieuwste apps heb je dan alleen nog maar een up to date Google play services nodig. Het fragmentatieprobleem is opgelost, de apps zullen minder laggy zijn, en de controle ligt volledig bij Google.

Vergelijk de Apple app store

[Gomez12]

En Android sterft rustig af omdat 1 groot sellingpoint van Android om zeep is geholpen (niet 100% hangen aan de Play-store)

[Verwijderd]

Android ondersteunt ook MIPS.
Verder heeft dtech gelijk, er zijn ook voor ARM allerlei opties. De simpelste Android-devices hebben bv nog niet eens een FPU, en de standaard ARM-configuratie compileert dan ook met FPU-emulatie.
Dan heb je ook nog dingen als NEON en dergelijke extensies, en zou je ook nog architectuur-specifieke optimalisaties kunnen toepassen (ARMv7 en ARMv8 zijn instructiesets, maar daar zijn verschillende implementaties van, met verschillende pipeline-configuraties, en dus verschillende eisen qua optimalisaties).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:49]

[mvdejong]

Als je maar 1 versie per architectuur produceert, ga je dus elke verbetering in de SOCs missen.

Als een processor-leverancier nieuwe features toevoegt, zouden alle oudere apps die niet kunnen gebruiken, tenzij ze opnieuw gecompileerd worden. En als ze opnieuw gebouwd worden, dan komen er in de code heel veel switches om te kijken over welke features de chipset waar het apparaat op draait beschikt, wat ook niet echt bevorderlijk is voor de performance. Zelfs op desktop- en server-platforms is dat soms een crime, en daar heb je dan minder last van de integratie van de grafische chipset en de aanwezigheid van meerder typen cores.

Met de huidige aanpak bevat het package van de app de functionaliteit, en zit de mapping daarvan naar de features van de SOC en de rest van het device allemaal in de runtime-compiler ingebouwd, die specifiek is gebouwd voor het device.

[Verwijderd]

Als je maar 1 versie per architectuur produceert, ga je dus elke verbetering in de SOCs missen.

Een compiler target nog altijd een isa, niet een SoC. De functionaliteit van een SoC ontsluit je met drivers, niet met een compiler. Of je nu een Qualcomm ARM v7 of een Samsung ARMv7 SoC hebt, de compiler is eender: ARMv7 binaries. De drivers ontsluiten de specifiek verschillen in "randapparatuur" tussen de Qualcomm en de Samsung SoC. Een andere compiler heb je pas nodig als je naar een andere instructieset gaat, zoals bijvoorbeeld ARMv8 64 bits.

[mvdejong]

Zelfs in een klassieke compiler voor desktop- en server-architecturen heb je switches om je code te optimaliseren voor de instructie-set van de target-processor. Die zitten erin om de afweging tussen performance en compatibiliteit te ondersteunen : het kiezen van een modernere processor-variant levert code op die optimaal gebruik maakt van de instructies van de target-processor, maar gaat ten koste van de ondersteuning op systemen die nog processoren van de oudere architectuur draaien.

Voor randapparatuur kun je vaak abstractie via drivers doen (hoewel spelen vaak direct gebruik maken van features van grafische kaarten), er is geen driver voor een processor (of, indien het zo wil zien, de JIT-compiler is dat).

Dat probleem heb je ook met het compileren van apps, behalve dat daar de variatie in de opbouw van de SOC's nog veel complexer is, omdat binnen de architectuur de grafische chip veel meer geintegreerd is, en je niet alleen verschillende aantallen cores, maar soms ook verschillende typen core hebt (krachtig versus zuinig).

Maar eigenlijk geef je in je post al het probleem aan : je spreekt al niet meer over een compiler voor de ARM-architectuur, maar voor ARMv7.

[Verwijderd]

Nou, eigenlijk geef jij in je post aan dat je terugkrabbel van je compiler per SoC naar compiler per isa. Prima natuurijk, daar zijn we het over eens dan.

Nu haal je de GPU en big-little concepten er bij.

GPU vind je niet terug in de compiler persee, hier heb je initiatieven als Cuda en OpenCL voor. Een soortement domain specifieke talen die je naast de generieke programmeertal inzet.

Big-Little vind je helemaal niet terug in de compiler noch binaries. Of denk je dat de just-in-time compiler ook aan scheduling doet ? Volgens mij zijn de big en little processoren van eenzelfde instructieset voorzien. Er hoeft dus niet opnieuw gecompileerd te worden om een proces van de big naar de little te migreren en andersom.

Je hebt in ARM land 32 en 64 bits ARM: ARMv7 en ARMv8, over een tijdje zit iedereen op 64 bits ARM en Intel is de verwachting. Dit lijkt me qua ISA"s zeer overzichtelijk en makkelijk te handlen in een Cloud stored binaries scenario zoals ik schets (Apple doet het al zo).

[mvdejong]

Ik krabbel helemaal niet terug. Ik geef juist aan dat zelfs in de klassieke ontwikkel-omgeving je beslissingen moet nemen over subtiele variaties in processor-architectuur binnen een architectuur. Je kunt kiezen om 1 executable op te leveren voor alles, maar dan maak je ofwel geen gebruik van features die de recentere processor-versies ondersteunen, of je geeft compatibiliteit met de oudere processoren op. Daarvoor kan je in het klassieke applicatie-landschap bewust kiezen, maar in het snel-bewegende mobiele landschap wil je dat niet, want je sluit veel gebruikers uit, of maakt geen gebruik van nieuwe ontwikkelingen.

En je aantallen binaries beginnen te stijgen. Nu heb je al 32- en 64-bits versies van ARMv7 en ARMv8, en dan komt Intel erbij. En blijkbaar wil je dat iedereen straks met 64-bits ARM en Intel werkt. Dus je wil dat apps maar even niet meer ondersteund worden op wat vroegere hardware ? En de wat meer exotische devices, die niet op een van de twee grote jongens draaien, wil je die dan maar laten vallen ? Het voordeel van de huidige oplossing is juist de device-onafhankelijkheid, waardoor ik niet door de apps gedwongen wordt om elk jaar een nieuw device aan te schaffen, geen vendor-lockin, geen versie-lockin.

[Verwijderd]

Het is ook gewoon mogelijk dat er vooraf voor verschillende architecturen wordt gecompilleerd.

Eventueel kan de broncode dan nog worden meegestuurd.

En dan is het hele probleem toch opgelost?

PS: bij het downloaden kiest het systeem natuurlijk automatisch de juiste architectuur. Eventueel kan de code op de server on-demand worden gecompileerd en gecached (voor andere gebruikers met dezelfde architectuur).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:49]

[ikwilwp8]

ARM is een architectuur, geen fabrikant. Je zegt " ARM en Intel". Intel kan ook ARM's maken.

[joco]

mvdejong heeft helemaal gelijk.

Java hotspot compiler maakt gebruikt van AES of SSE versies waar dat mogelijk is.

ook bv 64 bit? java programma's maken daar meteen gebruik van.

Dit kan dus op android ook prima, straks komen de ARMv8 cpu's er aan en dan? Dan moet je dus ook al 4 binairies hebben?
dus 64 en 32 bit x86 en 62 en 32 bit arm?

Nee op het platform compileren op het moment dat je het nodig hebt dan kan het veel optimaler.

Ook bv chrome apps met de native client (NaCl). Op dit moment zijn dat gecompileerde binairies maar ook daar gaat men naar een portable versie toe PNaCl
https://developers.google...client/dev/nacl-and-pnacl

dus de trend is eerder de andere kant op dan wat jij beschrijft

[zerokill]

Klopt maar ten delen. Tijdens het compilen geef je inderdaad aan voor wat voor target je wilt compilen maar je kan ook nog een subtarget aangeven. Kijk voor de grap is naar de subtargets in de ARM backend van de LLVM compiler. Er zijn een stuk of 20-30 subtargets aanwezig met allemaal andere eigenschappen maar wel allemaal voor ARMv7.

Eigenschappen die per subtarget verschillen zijn bijvoorbeeld: hardware div/mul instructies, hardware floating point operaties, wat voor SIMD operaties er aanwezig zijn.

De andere interesante eigenschappen die per subtarget verschilt is de pipeline layout. Om code goed te optimaliseren moet een compiler een beeld hebben van hoe instructies uitgevoerd worden, hoe diep de pipeline is, wat de issue width is, wat voor microops ondersteund worden, wat de delay is van verschillende instructies. Dit is allemaal afhankelijk van de implementatie van de SoC en geloof me, er zitten grote verschillen tussen een Cortex A8, A15, Scorpion en een Apple A7

edit: voor de grap kan je hier de subtargets voor ARM in LLVM zien: https://github.com/llvm-m...ter/lib/Target/ARM/ARM.td
grep op subtargetfeature en je ziet wat voor opties je allemaal kan aangeven binnen een enkele ISA

[Reactie gewijzigd door zerokill op 23 juli 2024 23:49]

[Verwijderd]

Ik geloof je graag, maar wegen de verschillen op tegen het implementeren van een JIT/RAD compiler in de handset?

Waarom de JIT compiler niet in de Cloud implementeren? Het komt me nogal kludgy over om telkens opnieuw dezelfde software te compileren... Niet elke handset heeft een unieke processor, er is dus winst te halen hier.

En een native goed geoptimaliseerd binary draaien is altijd nog beter dan eerst een JIT in het leven te moeten schoppen om de compile te doen. Ik wil *geen* Java/JIT/ART op mn energie constrained device draaien, doe dat maar in de Cloud.

[zerokill]

LLVM is ook een static compiler (JIT wordt ondersteund maar wordt tegenwoordig iets minder gebruikt). Je hebt 100% gelijk dat static compilation niet bijzonder efficient is voor android. Voor Apple devices is dit een stuk nuttiger omdat er zoveel minder verschillende SoC's zijn om voor te compilen en omdat de features van deze SoCs (Op de pipeline na) bijzonder veel op elkaar lijken.

JIT in de cloud klinkt stom. Het voordeel van JIT is juist dat je runtime informatie gebruikt om je programma te optimaliseren. Deze informatie is in de cloud natuurlijk niet aanwezig en kan je beter op het device zelf doen.

Het idee van compilen in de cloud vind ik wel goed eigenlijk maar dan gewoon een static binary (niet iets voor android dus). Je zou inderdaad een speciale binary kunnen compilen als er bijvoorbeeld genoeg vraag is naar een binary met bepaalde features. (Oprecht best een goed idee!)

Ik ben het 100% met je eens over JIT zelf. Ik geloof best dat er bepaalde optimalisaties zijn die alleen door een JIT compiler kunnen worden gevonden maar dat weegt niet op tegen het feit dat er GENOEG dingen zijn die een JIT nooit zal kunnen vinden en die je perse met een static compiler wil doen. Ik denk hierbij bijvoorbeeld een schedulers die te zwaar zijn om te draaien tijdens runtime en eigenlijk altijd tijdens compile time wilt doen.

[Verwijderd]

De cloud weet toch het type van de handset, daar zal vast wel een soort 'target string' naar toe gaan die de voor compileren relevante settings bevat (een string met commandline opties voor de compiler bij wijze van spreken alleen dan natuurlijk generieker: een key naar een database met buildsettings voor het target).

Vervolgens kijkt de cloud of de App al in native versie beschikbaar is voor het target. Zo ja dan kan de binary naar de handset gestreamed worden. Zo nee, dan zet Google zn massively parallel Cloud computers aan de slag om de meest optimale binary die maar mogelijk is te compilen. Hence: JIT in the cloud.

Dus je hebt alle informatie over het target, je hebt de hardware in de google cloud om een -echt goede compile- te draaien. En de client krijgt een snelle energiezuinige native app zonder Java/JIT gedoe.

ART op de handset is fase 1, samen met het uitbouwen van Google playservices, uiteindelijk onstaat er met JIT-in-the-cloud en Google play servies een soort Apple app store. Problemen als laggy apps, fragmentatie, weglopende OEM's met eigen software stacks zullen er niet meer zijn voor het platform dat ooit als OSS Android begon...

[Verwijderd]

Als je het in de cloud gaat doen, krijg je een vergelijkbare situatie als met iPhone en Windows Phone: de apps draaien alleen maar op hardware die door de leverancier van het OS ondersteund worden.

Het voordeel van Android zou juist moeten zijn dat iedere fabrikant het kan aanpassen om te draaien op zijn hardware, zonder dat daar direct support vanuit Google voor nodig is.

Dus wat dat betreft lijkt een hybride-oplossing het beste: de cloud kan voor de meest gangbare systemen een precompiled versie cachen. Maar voor onbekende hardware zou de mogelijkheid moeten blijven bestaan om gewoon een APK met Dalvik-code te installeren, die het device dan zelf via Dalvik, ART of iets kan draaien.

[SPee]

Probleem is dat een "Samsung Galaxy Sx" in verschillende varianten komt. En dat geldt voor veel meer apparaten.
Dus zonder gedetailleerde informatie van het device kun je niet de juiste keuze maken. En die data wel je ook niet steeds over de lijn sturen (naar de gevoeligheid voor hackers ed).

En dan nog de (potentiële) kosten voor de hoster van al die binaries. Eén bestand vs honderden. En de kosten voor al die compilaties. En dan is de verantwoordelijkheid voor de juiste vertaalslag ook bij de hoster ipv bij de fabrikant van het apparaat.

[Verwijderd]

En waarom zou je (voor de toekomst) Alles LOCKEN op Intel en ARM binaries... wie weet komen er nieuwe soorten instructie sets die wel beter zijn.
Anti-innovatie ofzo?

[Verwijderd]

Nee, ik ben pro innovatie, maar zie de oplossing van java client side JIT of dat nou ART is of iets anders als een kludge. Als je weet dat er maar zo weinig verschillende processortypes/ISA's zijn in verhouding tot het aantal handsets. Het ligt veel meer voor de hand om binaries aan te bieden vanuit de cloud. Google heeft dan welliswaar het probleem verschillende handset vendors te moeten ondersteunen maar dit zouden ze met de combi JIT-in-the-cloud/Google play services kunnen aanpakken. Einde laggy apps, einde android fragmentation, verminderd energie verbruik in de handset. Meer het Apple Store model qua apps/updates.

[mvdejong]

Behalve dat er meer processortype's/ISA's zijn dan alleen ARM en Intel, die jij blijkbaar graag zou willen uitsluiten van verdere ontwikkeling van de mobiele wereld, blijf je nog steeds binnen die targets met grote verschillen zitten.

Om nog even een stukje van je te herhalen :

Een compiler target nog altijd een isa, niet een SoC. De functionaliteit van een SoC ontsluit je met drivers, niet met een compiler. Of je nu een Qualcomm ARM v7 of een Samsung ARMv7 SoC hebt, de compiler is eender: ARMv7 binaries. De drivers ontsluiten de specifiek verschillen in "randapparatuur" tussen de Qualcomm en de Samsung SoC. Een andere compiler heb je pas nodig als je naar een andere instructieset gaat, zoals bijvoorbeeld ARMv8 64 bits.

Ja, die compilers zijn hetzelfde, maar op elk type device genereren ze verschillende code, omdat ze precies weten wat de target-architectuur is waarop ze draaien, en dus probleemloos de optimale code kunnen genereren voor precies dat device, terwijl met een vooraf gegenereerde code je altijd de features-/performance-/compatibiliteits-keuze hebt moeten maken d.m.v. stuur-instructies aan de compiler.

[Verwijderd]

Dat kan vanuit JIT-in-the-cloud ook, geen noodzaak om dat op de client devices te doen. Bovendien heb je het voordeel in de cloud dat je een zware compiler kunt inzetten om de perfecte binary te bakken toegesneden op jouw toestel ipv dat je een compiler op energy-constrained handset loslaat. Laat nog onvermeld dat compilen maar 1x per type handset/ISA/architectuur nodig is ipv voor elke instance van die handset afzonderlijk op de client.

[Verwijderd]

en wat als de cloud eruit ligt?? Ik wil het graag lokaal houden. Bijvoorbeeld na een her-installatie van mijn titanium back-up. Alles wordt daarna opnieuw omgezet naar ART (CM11, LG G2). Nu gaat dat gewoon op de device zelf, waar ik voor ben! Houden zo

[Verwijderd]

Je krijgt gewoon de binaries geserveerd uit de Cloud, die staan dus ook op je backup.

[Verwijderd]

Ik wil niet per se met internet verbonden zijn voor een lokale install

[Verwijderd]

Dat zou een Lock in van Google vergroten... dacht dat je daar tegen was.

[Verwijderd]

Daar ben ik ook tegen maar ik kijk naar hoe Google werkt (ze willen macht en de handsets door hun cloudservices/ad networks laten lopen) en hoe ze dat technologisch aan kunnen vliegen.

Ik maak een onderscheid tussen het technisch vernuft van Google en de politiek die ze voeren mbt hun businessmodel (informatie doorverkopen).

[Dreamvoid]

Er is niet altijd 1 universele ARM binary, om effectief native te programmeren zal je kunnen optimaliseren voor de diverse ARM architecturen, en er zijn ook diverse extensies op de ARM ISA (oa NEON/NEON2) die niet op elke ARM SoC werken.

(ah dtech zegt het al )

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 23:49]

[Fuzzillogic]

Is ART open source? Of gaat Google hiermee verder op de ingeslagen weg om Android een steeds meer gesloten platform te maken?

[Verwijderd]

ART is open source, en zit ook al oa in CyanogenMod 11.

[Verwijderd]

ART zit in Andriod, Cyanogen is niks meer dan bedrijf wat Andriod leverd met aangevulde functionaliteiten. Overigens wel een goede "fork" (net als Paranoid Andriod) van AOSP

[Verwijderd]

Ik bedoelde te zeggen dat je ART ook al kan krijgen in custom roms.

[Feanathiel]

Een beetje doorklikken commit en je komt uit op platform/art (master) (de repository waar ART leeft).

[Fly-guy]

Andoid is niet closed en google is ook niet bezig met het dichttimmeren ervan, hoe kom je daarbij? Google apps zijn vaak closed, maar staan los van het os op zich.
Iedereen kan en mag de source bekijken, downloaden en gebruiken om een eigen versie van Android te bouwen, hoe is dat gesloten?
Wil je google apps gebruiken, dan wordt het een ander verhaal, maar dat heeft niets met het os te maken, er zijn zat alternatieven.

[Fuzzillogic]

Google Play Services is gesloten. De klassieke Android apps worden niet meer door google onderhouden, maar vervangen door gesloten varianten, heel erg gericht op de google cloud en google+.bron.

Ik heb een mobiel die Android apps kan draaien. Maar omdat daar dus geen Google Play Services op mogen zijn er de nodige apps die niet werken. Android is dan nog wel open, maar google is het wel aan het uithollen. Ik vreesde dat ART ook cloused source zou zijn, blijkbaar onterecht. Dat is dan weer een positief puntje. Maarja, de proof of the pudding is in the eating...

[Fly-guy]

Nogmaals, dat zijn apps, niet het os. Android is open, de apps die jij wil gebruiken niet. Het zijn dan ook geen Android apps, maar google apps en onderhevig aan hun voorwaarden. Natuurlijk had ik ook liever een open source muziek app gehad, maar dan neem je toch een alternatief? Zat open source apps te vinden, alleen niet van google.

Op linux zijn ook closed apps te vinden, ondanks het open zijn van het os.
Je moet de apps en het os echt separaat zien.

[Fuzzillogic]

Google Play Services is een steeds belangrijker wordende bibliotheek. Je kunt het daarmee steeds meer zien als onderdeel van Android. For all intents and purposes is Android daarmee steeds geslotener aan het worden.

[Fly-guy]

Dat is jouw mening, maar niet een feit. Het is een steeds belangrijk wordende factor in de google versie/implementatie van android, maar zoals amazon laat zien, kun je prima android versies uitbrengen die niet op de play services steunen.

Jij haalt het OS en de apps of visie van googel door elkaar. Iedereen kan kosteloos en geheel legaal de source van de OHA downloaden, er een in car entertainment OS, een besturing van een koelkast of een portable music player os van maken. Wil je echter de diensten van google gebruiken, dan moet je inderdaad gebruik maken van de closed source items van google. Maar nogmaals, dat staat los van android op zich.

De opmerking dat android steeds meet gesloten wordt, is op zijn minst misleid en naar mijn mening klakkeloos napraten van mensen die er niet over nagedacht hebben.

[arnoudwokke]

Nu haal jij dank ik zaken door elkaar. Dat je de source kan downloaden en gebruiken sluit niet uit dat Android steeds geslotener wordt.

Waar veel mensen op wijzen is het feit dat de app suite van Android steeds minder compleet en steeds meer gedateerd is. Natuurlijk zijn er alternatieven, maar dat neemt niet weg dat er elementen ontwikkeld werden in de open source versie die nu gesloten zijn.

Daarnaast zijn er steeds meer apps die zich afhankelijk maken van de voor ontwikkelaars verrekt handige api's van Google. Zonder die api's werken bepaalde apps van derden niet - en je zult dat van tevoren niet weten. Hoe meer ontwikkelaars die api's gebruiken, hoe afhankelijker je wordt van Google op Android. Zie je het belang van Google?

Het valt simpelweg niet te ontkennen dat Google zijn strategie gewijzigd heeft om zijn eigen diensten te pushen op Android. Natuurlijk is dat gerechtvaardigd, want ze maken het os, maar imho is het niet te ontkennen.

Overigens moet ik erbij zeggen dat ik het niet echt erg vind. Dat Android open zou zijn, bleek vooral tot voordeel van fabrikanten en providers, die er makkelijk hun eigen bloatware op konden zetten en Android zo konden aanpassen dat het moeilijk tot niet verwijderbaar is. Hoewel Android open was, was de firmware van toestellen dat niet door gesloten drivers voor het aanspreken van vrijwel alle hardware, waardoor de gemiddelde en zelfs bovengemiddeld ingevoerde gebruiker weinig had aan het feit dat Google Android inclusief app suite vrijelijk beschikbaar stelde.

[Fly-guy]

Ik haal niets door elkaar, jullie zijn in de war.

Nogmaals, het operating system Android is en blijft open, amazons kindle is daar het voorbeeld van. Googles/OHAs versie van Android wordt wel steeds meer richting de gesloten apps van google getrokken en dus inderdaad meer gesloten. Dat dat net de versie van Android is die men gebruikt en gewend is, doet men denken dat google dus Android minder open sourced maakt, maar dat is en blijft dus niet zo.

Zoals iedereen mag doen, pakt google de source en maakt zijn eigen fork, met bijbehorende apps. En met zoals je bij de kindle fire minder aan het apparaat hebt zonder de Amazon service, heb je bij de google versie minder aan je apparaat als je de service van google niet gebruikt. Maar dat is het gevolg van het nemen van de google/OHA versie van Android.

Maart Android zelf is en blijft open source. Plus dat vrij veel het nog steeds prima doet op een tablet of telefoon zonder google services, je moet alleen even harder zoeken.

[YaPP]

Waar anderen op wijzen, zijn de inzichten uit:

http://arstechnica.com/ga...e-by-any-means-necessary/

Samengevat:
- Google forkt 1 voor 1 alle stock apps door eigen closed-source apps.
- Google stopt vervolgens de ontwikkeling van de open apps.
- Google stelt leveranciers voor het gebruik van deze apps nieuwe voorwaarden.
- Developers leunen op de proprietary API's van Google, zoals:
* maps
* messaging
* locations
* in-app purchasing
- Hierdoor worden leveranciers gedwongen om Google's Android af te nemen, of zelf alles na te bouwen wat Google maakt.

Android mag misschien op papier nog open zijn, maar, nee, in praktijk is het niet meer dan een closed-source platform van Google.

Het open source deel van Android staat nu helemaal los van wat er op je telefoon/tablet staat, zonder play store oid.

En Amazon krijgt het voor elkaar, maar heeft er een zware dobber aan:

no major OEM is allowed [by Google] to produce the Kindle Fire for Amazon. So when Amazon goes shopping for a manufacturer for its next tablet, it has to immediately cross Acer, Asus, Dell, Foxconn, Fujitsu, HTC, Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, Sony, Toshiba, and ZTE off the list. Currently, Amazon contracts Kindle manufacturing out to Quanta Computer, a company primarily known for making laptops. Amazon probably doesn't have many other choices.
(..)
If you use any Google APIs and try to run your app on a Kindle, or any other non-Google version of AOSP: surprise! Your app is broken.
(..)
In response to this, Amazon was forced to license mapping data from Nokia and build a working clone of the Google Maps API. The company even has an instruction page dedicated to migrating your app from Google Maps. Again, Google is all about making life easy in its ecosystem and extremely difficult outside of it. If you want to run on the Kindle, you now need to support two different Maps APIs.

It's a terrible situation for the Android forker, in this case Amazon, who now has to deal with either paying license fees to Nokia forever or going out and mapping the entire planet on its own. Amazon is also now required to keep up with Google's break-neck pace of development: Amazon's Maps API supports Google Maps API v1, but Google is already up to v2. If you're a developer and depend on some new feature in the Maps v2 API, Amazon doesn't support it yet. Now you have even more work to do.

[Reactie gewijzigd door YaPP op 23 juli 2024 23:49]

[Verwijderd]

Google Play Service, is zoals je het zelf al zegt een Service van Google. Over Google Play Service verlopen updates op app/apk niveau maar ook systeem updates. Google vragen om de Play Service opensource maken is net zo iets als aan Apple vragen om SIRI opensource te maken. Thats not gonna happen!

En natuurlijk installeert Google eigen gesloten software, omdat die geoptimaliseerd zijn voor hun dienstverlening. Maar dat maakt het OS (andriod) niet uitgehold. De optie is om vrij te kunnen kiezen wat je wilt. Maar software blijft evalueren, de ene vervangt het andere en ja sommige apps (lees diensten) komen te vervallen omdat ze niet meer rendabel zijn.

OHA duid alleen maar aan dat het een stabiele versie betreft
OTA duid op een ontwikkel versie.

[Fuzzillogic]

GPS biedt veel meer dan alleen apk- en systeemupdates. Googe Maps valt er ook onder. Google Messaging Services ook. Als een app daar gebruik van maakt, dan kun je die app niet gebruiken op een kaal of niet-door-google-approved Android-apparaat. Ik noem hier Blackbarry, Kindle, Jolla,... Steeds meer apps werken daar dus niet meer op omdat google nou eenmaal steeds meer diensten in GPS steekt.

Dus ja, core Android is open (inclusief ART blijkbaar), maar het gehele platform komt steeds meer onder invloed van Google en is niet meer vrij.

[Verwijderd]

Dat Google zijn diensten afschermt vind ik niet meer dan normaal. Je moet Google voorzien van 2 petjes .. diensten leverancier ... Andriod leverancier. Andriod is open, de diensten zijn gesloten.

En als op de andere platformen applicaties niet meer werken, dan is dat een teken dat er te veel op Google (lees niet Andriod) geleund wordt. Mijn vraag zou dan eerder zijn waarom heeft de andere aanbieder geen eigen messaging system die te koppelen is aan bijv. G+ of juist niet. In mijn ogen is dat een slechte vorm van ontwikkelen (eerder mee liften).

Ook Blackberry, Kindle, Jolla zijn geen van allen Google merken, noch Google certified. Maar rusten blijkbaar zo zwaar op de dienst verlening (niet Andriod) van Google dat het ongezond is. Dat is een fout die je Google niet kan aanrekenen in mijn ogen. Eerder de genoemde merken zelf die zich zelf in de vingers snijden.

[Loller1]

Google Android (de OHA versie, die door alle grote fabrikanten wordt gebruikt) is wel degelijk niet 100% open source. Het gewone Android is dat wel.

[Fly-guy]

Als ik naar de site van de open handset alliance ga, kan ik daar de source gewoon downloaden. Lijkt me redelijk open...

[Loller1]

Deze Android versie zit vol met (Google) services die allemaal gesloten zijn . Is dus niet open source.

[Fly-guy]

Heb je werkelijk naar de source gekeken? Of de site op zijn minst? Ik kan niet eens tellen hoe vaak uitgelegd wordt dat de source open is.

Die hoef je toch niet te gebruiken? Download de source van die pagina en je kan zonder de play services te moeten gebruiken voor je eigen device een geheel legale open source versie van android bouwen.

[Qws]

Android OS is opensource, Google apps zijn closedsource.

[Qws]

Wat is dit dan? https://github.com/android

Android is opensource, en jij hebt ongelijk, deal with it.

[Dreamvoid]

Hij bedoelt: "Android" is weliswaar open source, maar de bedrijven in de Open Handset Alliance (Samsung, LG, Sony, HTC, etc) hebben zich contractueel gecommitteerd om verplicht de (gesloten) Google apps en API libraries erbij te nemen.

[dragonsoldier]

Wat ik me afvraag is hoe apps geschikt gemaakt moeten worden, het zal toch vooral de android sdk zijn die intern anders wordt?

[lesderid]

Dat denk ik niet, dit is meer low level. Als app developer moet je je norrmaal nu ook niet bezighouden met Dalvik. De APIs blijven normaal hetzelfde, maar de manier waarop de API calls (en alle code) worden gecompiled is wat veranderd wordt. Het is dus de 'black box' tussen de Java bytecode en het echte uitvoeren op de CPU die nieuw is.

[Fly-guy]

Toch is het op dit moment nog wel zo. Je kan nu al kiezen tussen art en dalvik, maar met art zijn er en aantal apps die het niet (goed) doen.
Het zijn er niet veel, maar het zal net je favoriete app zijn... http://www.androidruntime.com/list

[Verwijderd]

Klopt, ik heb 1 app zelf die niet goed werkt met ART. Maar de basis functie werkt wel goed. Enkel het bellen ermee niet.

Verder zorgt ART voor snelheid, beter batterijgebruik en ga zo maar door. 2 dagen met mijn Nexus 4 op ART is normaal

[Quipeace]

ART bleek geen significant effect op de batterijduur te hebben:
http://www.androidpolice....not-good-but-not-too-bad/

[Verwijderd]

Ze testen idle, een video draaien en een app die een lijst door scrolt. Niet echt van toepassing op het dagelijks gebruik van het OS. Misschien is ART dan wel efficiënter in dagelijkse taken en het switchen tussen allerlei taken en het gebruik binnen het OS zelf

Ik vind de test niet goed dekkend. Voor mij gaat hij gewoon veel langer mee dan op Dalvik bij dagelijks gebruik waarbij ik tussen allerlei apps switch en e-mails ontvang en berichten ontvang.

[Verwijderd]

Daar mag ik je helemaal gelijk in geven. Ik denk dat ik zo ongeveer 30 procent langere operationele tijd heb sinds ART in te schakelen. Alleen de eerste twee dagen was het juist veel minder, totdat ik eens op zoek ging naar wat er nu zoveel battery-drain gaf. Het bleek te gaan om een weerwidget, dat dus wel werkte maar idioot veel ging gebruiken.

Nu weet ik niet hoe games zich gedragen met ART, maar bij de reguliere apps bemerk ik weinig problemen. Als we games buiten beschouwing laten, durf ik veilig te stellen dat ART klaar is voor de wereld. En dat bijna de hele wereld klaar is voor ART.

[Verwijderd]

Nee, ART is zeker nog niet klaar. Er zijn veel apps die niet goed werken. En dat ligt niet aan de apps maar aan ART. Dus nog even afwachten denk ik.

[frankyboy707]

Is de basisfunctie van een smartphone niet nog steeds bellen? Maar wat werkt er niet qua bellen? Zou voor mij een dealbreaker zijn...

[Verwijderd]

Gaat waarschijnlijk om een third-party app. De meeste "telefoon-apps" werken met ART gewoon

[corimo]

Leuk nieuws, ben echt benieuwd wanneer we dit kunnen gaan testen
Dan is het alleen nog maar hopen dat het compilen zelf ook nog een flinke boost krijgt, want in een redelijk project met een hoop drawables en layout resources vereist het echt discipline om een build af te wachten.

[Nilsepils]

In Android 4.4 (KitKat) zit de mogelijkheid al ART te testen, onder developer options (kun je dat niet vinden in de settings moet je die eerst even aan zetten).

Whatsapp crashte met ART aan maar doet dat ondertussen niet meer geloof ik. In ieder geval in Whatsapp+ is het probleem opgelost. Verder ben ik nog geen apps tegen gekomen die moeite hebben met ART en ik heb ART dus ook permanent aan staan!

edit:
even gecheckt, ook de normale Whatsapp doet het nu prima met ART!

[Reactie gewijzigd door Nilsepils op 23 juli 2024 23:49]

[Verwijderd]

Helaas doet Xposed het nog steeds niet met ART. Hoe dan ook, ik heb ART een keertje getest en het voelde niet sneller dan Dalvik. Een groot nadeel vind ik dat na een ROM update de "optimizing apps" stap vele malen langer duurt dan met Dalvik. Dat is niet fijn als je regelmatig ROM updates uitvoert. Bovendien nemen apps met ART een stuk meer opslagruimte in beslag. Ik zie mezelf dan ook met volgende Android versies gewoon bij Dalvik blijven.

[Edgarz]

Gelukkig zal de grote gebruikersmassa (wat de primaire doelgroep is) niet zo'n last hebben van langer durende optimalisatie na een Rom change.

[Verwijderd]

Ow, ik merk op mijn LG G2 met CM11 draaiend behoorlijk wat winst. Vooral de animaties in de menu's, launchers en gpu belastende games draaien echt een stukje soepeler. Dit is overigens geen placebo effect. Ik heb Xposed pas geleden geïnstalleerd, niet wetende dat dat ervoor zorgde dat Dalvik geactiveerd werd. Het toestel draaide meteen "minder vloeiend". Ik ben toen gaan kijken in de advanced settings en zag dat Dalvik gebruikt werd. Xposed verwijderd, ART ingeschakeld en het verschil was meteen te merken

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:49]

[Ceejay]

Idem hier, ben nog geen apps tegengekomen die het niet doen, en de snelheidswinst is merkbaar op mijn Motorola Moto G

[Verwijderd]

Ik ook, geen problemen hier gehad met Whatsapp.

[AP3X]

In de laatste Android versies kun je dit al testen

[rob12424]

Heeft dit gevolgen voor bijvoorbeeld Sailfish? Weet iemand dat?

[Mizgala28]

Ik denk best grote gevolgen voor Salfish, die emuleert de Dalvik runtime namelijk.

[acizane80]

Waarschijnlijk wel omdat sailfish een dalvik environment gebruikt.
Als op termijn Google volledig afstapt van Dalvik en enkel Art gebruikt gaan BlackBerry en Sailfish gebruikers alle apps die zij willen installeren opnieuw moeten compileren.
Of de Dalvik runtime vervangen door een Art runtime.

[Verwijderd]

Deels wel, ze moeten nu een ontwikkel team opzetten om ART te implementeren in Sailfish.
Gelukkig is ART wel opensource dus dat kan prima. !!

[johien]

Sinds ik mijn Nexus 7 2013 KitKat heb via de ontwikkelaarsmodus ART aangezet. En dit werkt tot nu toe prima, geen enkel probleem ondervonden. Eerst wordt je systeem omgezet naar ART inclusief al je programma's. Wat je vooral merkt is dat het scrollen door lange lijsten (veel) soepeler gaat.

[Verwijderd]

Ook maar eens gedaan en de eerste indruk is dat hij inderdaad (nog) sneller werkt.
Icestorm Unlimited van 3DMark gedraaiden hij levert iets in op de schone installatie van 4.4.2., van 10673 naar 10510. Maar dat is niet echt en goede test om te draaien in dit geval.

[Verwijderd]

Kijk eens naar een kernel waarmee je de io scheduler kan controleren en eventueel cpu ferquentie en voltage instellingen. Standaard Google kernel mist nogal wat aan optimalisaties.

[Mavamaarten]

Ik merk het vooral bij kleine dingen als het keyboard. Het wisselen van invoervelden en dergelijke gaat veel vlotter, net dingen die er niet echt toe doen maar je device wel sneller doen aanvoelen.

[Verwijderd]

Yup, zeker op de wat minder high-end devices merk je er in bepaalde gevallen best wel wat van.
Grappig op zich, want voordat ART er was beweerden Android-fans bij hoog en laag dat er niets mis was met de soepelheid, response en efficientie van Android.

[BlackPanther]

Kan het kloppen dat ik niet ART kan activeren op mijn note 3 kitkat? developer opties staan aan maar geen "select runtime" in het menu?? kan iemand mij vertellen waarom ??

[joco]

volgens mij shipped samsung ART nog niet mee.

[BlackPanther]

Had het na wat research ook door. evengoed bedankt voor je reply. toch vind ik het heel vreemd dat Samsung deze keuze heeft gemaakt aangezien ze zo goed in de markt staan met goede high end toestellen

[Verwijderd]

ART werkt erg goed, heb nu een custom 4.4.2 ROM en custom kernel op via LINEARO toolchain samengesteld. En het werkt echt rete snel.

Enige tweaks die ik heb gedaan is op kernel niveau (CPU instellingen (bijv 2e core uit bij scherm uit, CPU ferquentie aangepast, CPU voltage aangepast), IO aanpassingen gedaan voor lezen en schrijven van het geheugen).

Whatsapp was het enige wat problemen gaf, maar die heeft een week geleden een update gekregen waardoor dat ook weer verholpen is.