Google en ARM werken aan snellere ART-compiler

Google en ARM hebben de handen ineen geslagen bij de ontwikkeling van een nieuwe compiler die de huidige ART-compiler, die in Android 4.4 en hoger is te vinden, moet vervangen. De Optimizing-compiler zou Android-apps aanzienlijk sneller kunnen maken, al duurt het compilen langer.

ART, wat staat voor Android Runtime, kwam in Android 4.4 beschikbaar als optie voor de tragere Dalvik-runtime. In Android 5.0 Lollipop werd de ART-runtime standaard, met als gevolg dat apps sneller draaiden. ART maakt echter momenteel nog gebruik van een zogeheten mixed ahead-of-time-compiler, Quick geheten. Deze is nog deels gebaseerd op de Dalvik-compiler en maakt dus geen optimaal gebruik van ART en recenter processortechnologie. Google en ARM hebben daarom besloten om gezamenlijk een nieuwe, beter geoptimaliseerde compiler te ontwikkelen. Deze luistert naar de naam Optimizing, schrijft Android Authority.

Optimizing kan onder andere 64bit-code ondersteunen die wordt gebruikt in ARM's AArch64 64bit-architectuur. ARM werkt aan dit deel van de compiler, terwijl Google een 32bit-versie ontwikkelt. Daarnaast zou Optimizing volgens de makers complexere optimalisaties kunnen doorvoeren in de Java-code die gecompileerd moet worden, en er is een verbeterd mechanisme voor register allocation aanwezig.

Er wordt nog volop gewerkt aan Optimizing, maar de compiler zou op dit moment Android-software in bepaalde benchmarks tot 40 procent sneller kunnen laten draaien. Enkele nadelen zijn dat het compileren zelf iets langer duurt en dat de bestandsgrootte met 10 procent toeneemt, maar de ontwikkelaars denken deze neveneffecten met toekomstige aanpassingen te kunnen verminderen. Mogelijk zal Google tijdens zijn I/O-ontwikkelaarsconferentie eind mei meer bekendmaken over wanneer Optimizing in Android zal worden opgenomen.

Reacties (92)

[maevian]

Waarom werkt Google enkel samen met ARM aan deze compiler? Je ziet meer en meer Android tablets met Intel Atoms

[StefanTs]

Android x86 is geen officiële port. Is een hobby projectje.

[leuk_he]

eeh.. nee.. ik denk dat een open source rom ingedachten hebt.

https://software.intel.com/en-us/android/get-device

[StefanTs]

Ik zie daar enkel tools om apps te maken. Geen Android port van Intel.

Ik heb Android x86 in gedachten. http://www.android-x86.org/

[rty]

Op de link van leuk_he zie ik android tablets met intel x86 processoren. Nog meer info hier: https://01.org/android-ia/

[leuk_he]

Wat jij linkt is idd een open source project om android op PC te draaien. Intel levert dus ook gewoon kant en klaar spul om android op zijn atom achtige SOC te draaien.

[gjmi]

Tja, misschien wil Intel en/of Google dat niet. Ligt er aan of ze er baat bij hebben. Ze hebben ook onderling hun taktieken.
En misschien gaat het nog wel gebeuren, misschien zijn ze al wel bezig met onderhandelen, kosten moeten namelijk ook verdeeld worden.

[Gallant]

Omdat verrrrr uit de meeste android devices op ARM chip architectuur draaien dus logisch dat je daar begint. Het zelfde geldt voor het feit dat ontwikkelaars eerst voor de grotere platformen ontwikkelen.. lijkt me logisch.

[marcovtjetje]

Jarenlang hebben Java afficianados ons wijs proberen te maken dat de runtime profiling van Java en de terug propagatie van die informatie een superieur principe was wat betreft code snelheid. Je zou de machine zo optimaal benutten.

NGen, Art, Microsoft die C++ gebruikt voor zijn Apps implementatie, het lijkt alsof JIT een tikje op zijn retour is.

[Verwijderd]

Heeft ook te maken met de energie behoefte. JIT is misschien wel snel genoeg, maar alleen met voldoende kloksnelheden. Dit zou misschien net zo snel kunnen zijn maar met lagere kloksnelheden waardoor weer energie wordt bespaard.

[halofreak1990]

Waarom JIT? Waarom niet gewoon AOT compilen, zoals o.a. Microsoft doet voor Windows (Phone) als een app eenmaal goedgekeurd is. JIT is eigenlijk alleen maar handig voor debuggen, i.c.m. bijv. Edit-and-Continue.

[JustFogMaxi]

Omdat met JIT on the fly kan compileren voor de architectuur waar het op draait zonder aparte builds te maken.

[halofreak1990]

Zoals gezegd, dit heeft alleen nut voor debugging, wat hopelijk niet gebeurt vanuit de marketplace.

[wjvds]

JIT heeft nog een nut: het maakt analyse van codepaths waardoor bepaalde optimalisaties later uitgevoerd kunnen worden mogelijk - dit wordt door Java veel gebruikt. Dit geeft Java soms snelheidswinsten t.o.v. C++ in real-world scenarios. Zie ook http://en.wikipedia.org/wiki/Adaptive_optimization.

[arendjr]

Haha, je realiseert je dat je de discussie nu in een cirkel laat draaien? Het argument wat je nu aandraagt is precies waarmee marcovtjetje de discussie begon.

En de reden waarom je nu dus ziet dat met name op mobile vooral teruggegrepen wordt op AOT is dus omdat die optimalisaties inderdaad soms (of beter gezegd, heel zelden) tot verbetering leiden, maar JIT wel altijd runtime overhead heeft.

[Verwijderd]

En programma's die hun eigen code kunnen wijzigen dan?

[Verwijderd]

Volgens mij begrijp je niet wat JustFogMaxi bedoelt.
In de app store hoeft niet voor iedere mogelijke architectuur een build te bestaan. Een Android-device kan zelf bytecode compileren naar de specifieke hardware. Hierdoor werkt een applicatie dus 'altijd' zonder dat de developer of de store iets hoeft te weten van de hardware. De hardware is weg-geabstraheerd, en je programmeert tegen een generieke virtuele machine aan.

Wat dus niets te maken heeft met debugging.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 11:03]

[leuk_he]

Er zijn zeer veel ARM processoren. (en ook nog wat andere architecturen) De theorie zegt dat je de code kunt optimaliseren voor het apparaat waar het op draait. Dus daarom wil je pas op het apparaat compileren.

Het nadeel is dat op dit moment gecompileerde code groter is. Op devices met weinig geheugen worde de JIT gecompileerde code vrij snel wegggooid. Geheugen is daar waardevoller dan CPU kracht.

10-20% meer geheugen gebruik op devices die geheugentekort hebben kost wellicht meer performance dan 10-20% meer performance.

[arendjr]

En je denkt dat de JIT zelf die tegelijk met het programma moet draaien geen geheugen kost?

[wph]

Net zo snel op lagere kloksnelheden betekent gewoon sneller op dezelfde kloksnelheden. Dat het ook energie bespaart is daar een logisch gevolg van, je proces is immers eerder klaar.

[BRAINLESS01]

Volgens mij zit het verschil er in dat je telefoon of tablet er van uit gaat dat je alle apps die je download ook daadwerkelijk wilt gebruiken. Die worden dan eenmalig volledig gecompileerd en opgeslagen. Wil je er vanaf, dan moet je app weggooien.

Als Java nu ineens alle applicaties op je computer volledig vooraf ging compileren, dan zou iedereen gaan schreeuwen over het CPU verbruik en de opslagruimte die als sneeuw voor de zon verdwijnt. En als ze volledige applicaties gaan compileren bij het opstarten, dan duurt het veel te lang om applicaties te kunnen starten. De huidige situatie is een win-win.

Op een computer wordt alleen het deel gecompileerd dat je op dat moment nodig hebt (JIT = Just In Time), dat gaat super snel. Als je op de computer maar 5% van de applicatie gebruikt, compileer je dus ook maar 5%. Tijdens het gebruikt van de applicatie ga je langzaam meer stukken code tegenkomen die nog niet gecompileerd waren, dat wordt dan op dat moment nog even gedaan. Dat je daar niets van merkt komt doordat het hele kleine stukjes zijn.

[RagingPenguin]

Volgens mij zit het verschil er in dat je telefoon of tablet er van uit gaat dat je alle apps die je download ook daadwerkelijk wilt gebruiken. Die worden dan eenmalig volledig gecompileerd en opgeslagen. Wil je er vanaf, dan moet je app weggooien.

Als Java nu ineens alle applicaties op je computer volledig vooraf ging compileren, dan zou iedereen gaan schreeuwen over het CPU verbruik en de opslagruimte die als sneeuw voor de zon verdwijnt. En als ze volledige applicaties gaan compileren bij het opstarten, dan duurt het veel te lang om applicaties te kunnen starten. De huidige situatie is een win-win.

AOT gebruikt juist minder CPU kracht als JIT(en minder RAM). Bij JIT ben je nog constant aan het compilen, dat kost resources. Bij AOT duurt het instaleren wel net iets langer. En het opslag verhaal valt wel mee, dat is zo'n 10-20%. Niet echt 'sneeuw voor de zon'.

Op een computer wordt alleen het deel gecompileerd dat je op dat moment nodig hebt (JIT = Just In Time), dat gaat super snel. Als je op de computer maar 5% van de applicatie gebruikt, compileer je dus ook maar 5%. Tijdens het gebruikt van de applicatie ga je langzaam meer stukken code tegenkomen die nog niet gecompileerd waren, dat wordt dan op dat moment nog even gedaan. Dat je daar niets van merkt komt doordat het hele kleine stukjes zijn.

JIT voegt wel extra latency toe(de bekende 'stroperigheid' van Andriod). En in het geval van mobiele apperaten kost het je ook batterijtijd. JIT is terecht een pricipe waar steeds meer vanaf word gestapt. het kost meer CPUkracht, meer RAM, meer stroom en het is trager. AOT kost je alleen ~15% meer opslag ruimte.

[latka]

Er is Java en Android: de jvm maakt het verschil. Desktop/server class machines met hotspot gaan supersnel (zoals de Java afficionados claimen). Op een mobiel device wil je dit niet: de CPU is te langzaam, het geheugen beperkt en wil je direct antwoord (geen warmup tijd). Dan is aot een betere oplossing: sneller het eerste frame op je scherm maar het wordt niet sneller na verloop van tijd (jit dus wel). Verder maakt de implementatie van de hit nogal uit: hotspot is 10 jaar ouder (en 10 jaar meer aandacht) dan dalvik of art. De keuzes van google staan los van de mogelijkheden van jit op een andere klasse machine.

[Verwijderd]

Ja, zo'n 10-15 jaar geleden waren onze desktops ongeveer even krachtig als onze smartphones nu.
Maar ook toen al waren de Java JITs veel beter en sneller dan Dalvik.
Ik snap persoonlijk niet zo goed waarom Google van JIT naar AOT is overgestapt. Dalvik was ooit ontworpen voor telefoons met enorm lage resources, maar is voor een moderne smartphone met veel snelle CPU-cores en geheugen verre van optimaal. Een JIT zoals Java (of .NET) op de desktop gebruikt had ook al vele malen sneller kunnen zijn, maar wel met de voordelen van JIT erbij.

[froggie]

Zoals vaak het geval is met dit soort complexe technologie en concepten is het geen silver bullet en kost het tijd voordat we begrijpen wanneer iets toegepast moet worden en (wellicht belangrijker) wanneer juist niet.

Ik denk dat de HHVM PHP runtime welke ontwikkeld wordt door Facebook een goed voorbeeld is waar JIT wel degelijk meer performance levert dan een AOT compiler, HipHop. In sommige code paden van de website zorgen runtime optimalisaties voor een 2x speedup ten opzichte van de AOT Cpp translated en optimized build. Waar JIT met name tot z'n recht komt is bij in gebruik name van nieuwe CPU generaties; dezelfde build kan uitgerold worden in alle clusters, maar op servers met de laatste generatie Intel CPUs kan gebruik worden gemaakt van optimalisaties voor crypto en het sorteren van arrays, wat significante performance winst oplevert (en dus geld bespaard).

De keerzijde is dat dit alleen goed werkt wanneer de JIT voldoende opwarmt. Wanneer een HHVM instance gestart wordt is er een warmup script dat uitgevoerd wordt voordat deze daadwerkelijk live production traffic krijgt, zodat de request latency hit als gevolg van JIT voorkomen wordt. Precies dit werkt waarschijnlijk niet goed in een omgeving met interactive applicaties zoals een smartphone, waar geen tijd is voor deze warmup stap.

[Reactie gewijzigd door froggie op 28 juli 2024 11:03]

[chaogai]

JIT is er nog wel. Julia (julialang.org) is een project waar de taal ontwikkeld wordt voor snelle uitvoering van berekeningen.

[Ziriax]

Ecologisch gezien is JIT gewoon een ramp. Waarom zou je miljoenen toestellen telkens opnieuw een programma Just In Time laten compileren, terwijl een developer of beter nog een server dit 1 keer kan doen voor al die miljoenen devices... Ok, JIT kan in sommige gevallen snellere code opleveren, maar voor het merendeel van de apps zal dit niet veel uitmaken.

[latka]

Cache de gejitte code? Nog een voordeel: 1 binary voor alle platformen. Hoef je niet je x86 en arm versie te testen en als volgend jaar een mipsphone uitkomt werken alle apps vanzelf. Beter dan vendor lockin zoals die op x86 bestaat met native binaries.

[Laurens-R]

Dat klinkt als de natte development droom; maar er kan nog zoveel fout gaan op het niveau van de runtime/library implementatie van het nieuwe platform, dat je alsnog lekker aan het testen bent. Ik geloof niet meer zo in die 7de JIT hemel, omdat ik al vaak genoeg gezien heb dat de andere factoren (OS, Runtime, Library) roet in het eten gooiden.

Desalniettemin vind ik bijvoorbeeld .Net etc heel erg fijn hoor; ik ben alleen iets realistischer gaan kijken naar de hele '1 binary op X aantal platforms' droom, wat men ons in het begin met Java wel wilde laten geloven.

[Reactie gewijzigd door Laurens-R op 28 juli 2024 11:03]

[latka]

Hmm. Ik ontwikkel onder Windows en deploy onder Unix (vroeger ook wel mainframe). Enige probleem is een hard pad in de code. Soap services, database toegang en alle andere relevante zaken zijn werkelijk nooit een probleem. Dit doe ik al 10 jaar dus waarschijnlijk doe ik iets fout.

[Verwijderd]

De code is ook compacter, omdat een hoop optimalisaties uitgesteld kunnen worden tot de JIT-fase.
Denk aan het unrollen van loops, of het inlinen van functiecalls.
Dus, minder bandbreedte nodig, minder opslag, etc. Ecologisch best mooi dus!

[egnappahz]

Android 5.1 heeft al een incrementatie in efficientie van ART tegenover android 5.0. (vraag maar aan de exposed developer) Het zit bij android dus inderdaad niet stil onder de moterkap!

[Verwijderd]

Eens, mijn ervaring met Android 5.1 (op een Nexus 4) is dat het stukken vloeiender (eigenlijk gewoon helemaal prima) loopt dan Android 5.0. Ik vind dat de softwrae op de Nexus 4 met Android 5.1 nog nooit zo optimaal heeft gefunctioneerd.

Heb het dan uiteraard niet over games .

[Verwijderd]

Android 5.1 is de beste versie die ik ooit heb gehad op de Nexus 4. Batterij ging achteruit met 5.0. Maar ik kan nu weer 2 dagen doen met mijn batterij met 5.1
Tevens draait het ook een stuk soepeler.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 11:03]

[SV_25]

"Enkele nadelen zijn dat het compileren zelf iets langer duurt en dat de bestandsgrootte met 10 procent toeneemt,"
Ik vond de compile tijd en het geheugen verbruik van apps in lollipop al een ramp (beide waren x3), dus deze aankondiging lijkt me echt niet goed. Zeker aangezien android nogal lomp om gaat met het verplaatsen van apps naar de sd kaart en gebruikers verwachten direct na het downloaden ve app deze te kunnen gebruiken. .

[SuperDre]

Bestandsgrootte is niet gelijk aan geheugengebruik..

[calvinturbo]

Goed om te horen dat Google de snelheid van Android en/of apps op Android blijft tunen

[Aaargh!]

Snelheid is nooit een prioriteit geweest voor Google/Android. Hun grootste prioriteit is tegengaan van fragmentatie, ook al gaat dit ten koste van performance. Je ziet dit op heel veel punten in de keuzes die Google maakt, bijvoorbeeld OpenCL niet supporten en zelfs actief tegenwerken en in plaats daarvan RenderScript pushen.

[Jazco2nd]

Het is goed te zien dat Google echt serieus moeite doet om Android op alle mogelijke manieren sneller te maken. Het Windows Phone OS is razendsnel en heeft minder krachtige hardware nodig voor een vloeiende ervaring tov Android. Maar wellicht dat dankzij ART en de bugfixes in 5.1 dit al een beetje verholpen wordt. En met dit nieuwsbericht ziet het er goed uit... voor toekomstige Android modellen dan. Als je nu een toestel van een jaar of ouder hebt mag je al blij zijn als je 5.0 hebt/krijgt, laat staan 5.1

[Verwijderd]

Er zijn al jaren berichten dat Android sneller wordt, Project Butter, de snellere ART ipv Dalvik en nu weer de opvolger van ART.

Maar nog steeds lees ik op de twitters berichten over stroperigheid van Android en applicaties. Dus ja, kennelijk wordt Android/Apps sneller zwaarder dan de hardware meegroeit.

De hardware groeit overigens ook voornamelijk meer in de breedte (meer cores) dan dat de single core snelheid nou zo snel toeneemt. Misschien moeten applicaties daar iets meer mee doen, parallel processing.

Android, het blijft java.

[BRAINLESS01]

Ik merk eigenlijk niets van die stroperigheid. Ik heb zelf een Galaxy S4 en tot een paar weken geleden had ik nog Android 4.4, sindsdien heb ik Android 5 en dat werkt nog soepeler. Ik had al niets te klagen, maar met Android 5 merk ik dat het allemaal net nog een tikje beter is geworden.

Ik kan klachten over de Samsung software wel begrijpen, maar Android zelf is prima.

Toegegeven, met een Galaxy S4 heb (of had) ik een high-end telefoon. Misschien is het met een budget telefoon van 20 euro minder bruikbaar.

[Aaargh!]

Als developer merk ik het wel, zeker als je het vergelijkt met iOS. Performance van een recent high-end Android toestel is vergelijkbaar met een iPhone van een paar jaar terug.

Het gebruik van Java is voor een groot deel de oorzaak hiervan, en dat gaat ART of deze nieuwe compiler echt niet oplossen. Het probleem zit grotendeels in de manier waarop Java applicaties met geheugen omgaan en het effect hiervan op het gebruik van de CPU cache.

[calvinturbo]

Er waren laatst benchmarks op YouTube waar de iPhone met de Nexus werd vergeleken. Apps starten veelal sneller op de Nexus, de Nexus startte z'n OS sneller op en ga zo maar door..
Hoezo iOS sneller? Door hoe iOS werkt lijkt het alsof de iPhone sneller is, maar dit is helemaal niet het geval. Bij Android duurt het bijvoorbeeld even voordat de app daadwerkelijk start, maar hij is wel sneller gestart.

[Reactie gewijzigd door calvinturbo op 28 juli 2024 11:03]

[RagingPenguin]

Bkeijk deze reallife testen tussen de N6 en iPhone 6 eens. Voordat de N6 is opgestart heeft de reviewer al alle home screens laten zien van de iPhone 6.

Daarna komen wat app opstart testen waarbij de iPhone 6 is 6 van de 8 testen de snelste is.

En dat is logisch, iOS is met z'n C apps veel efficienter geschreven dan Andriod emt z'n Java apps.

[calvinturbo]

TechSource 4 months ago
Ya we mentioned In the video that the nexus 6 lost because of the encryption. We can re do the test after rooting the nexus 6 but then it would be useless as we are comparing 2 devices out of the box. Iphone 6 can also be jailbroken.

De Nexus 6 is een drama qua performance vanwege de encryptie die standaard aan staat en het feit dat Qualcomm drivers niet gebruikt worden voor de encryptie.

Zie ook hier vergelijking met de Note 4 erbij:
https://www.youtube.com/watch?v=DV2X51kAVfc

Tevens is de resolutie van de Nexus 6 en Note 4 1440p terwijl die van de iPhone 6 maar 720p is.

[Reactie gewijzigd door calvinturbo op 28 juli 2024 11:03]

[vali]

Tja en wie brengt de nexus 6 uit? Op dit moment verkoopt Google zelfs de Nexus 6 als virtuele provider.

Met wp10 is het ook mogelijk om encryptie aan te zetten en ik merkte geen snelheid verschil op mijn Lumia 520 (en dat is zelfs een low budget toestel).

[calvinturbo]

Helaas is het niet zo simpel als jij het stelt.
De reden dat Google niet de aanbevolen Qualcomm driver gebruikt voor de Nexus 6 is omdat ze deze niet open-source mogen vrijgeven.. En dat moeten ze wel aangezien het een Nexus apparaat is. De Nexus 6 draait dus minder optimaal dan bijvoorbeeld een Motorola Android toestel die ook encryptie aan heeft, omdat alle andere Android toestellen alleen kernel sources hebben die vrijgegeven moeten worden, niet de gehele code.

De vergelijking met Windows Phone toestellen gaat niet op, Windows Phone is 0% open-source.

Het is wel jammer dat de Nexus 5 uit de winkel even goed of beter draait dan de Nexus 6 terwijl je voor die laatste twee keer zoveel betaald..

[Reactie gewijzigd door calvinturbo op 28 juli 2024 11:03]

[vali]

Hoezo gaat de vergelijking niet op? We hebben het hier toch over de snelheid van het toestel? Mij boeit het vrij weinig dat het OS van mijn toestel niet opensource is, zolang de apps die ik sideload dat wel zijn.

Daarnaast vind ik maar een zwak excuses. De Google services zijn ook closed source en die worden toch ook met elk toestel meegeleverd?

[Reactie gewijzigd door vali op 28 juli 2024 11:03]

[calvinturbo]

Alle Android toestellen behalve Nexus toestellen gebruiken ook closed-sources drivers en hebben dus ook geen problemen met die encryptie. De Nexus wel, omdat Google verplicht is om alles open-source vrij te geven.

[RagingPenguin]

Encryptie zorgt niet voor alle performance problemen op de N6. Andentech heeft een N6 met FDE en een N6 zonder FDE getest en de versie zonder FDE heeft nog steeds performance problemen:

When the Nexus 6 review was published, I commented that there were performance issues that weren't present on the Nexus 5 running Android Lollipop. Many users commented that the FDE may have been to blame. Like I mentioned earlier, Motorola provided us with a build of Android with FDE disabled. Unfortunately, I haven't noticed any improvements to many of the areas where there are significant frame rate issues such as Messenger and Calendar. I speculated in the Nexus 6 review that the performance issues may simply be the result of insufficient GPU performance or memory bandwidth to drive the QHD display.

Bron

[_David_]

En die performance problemen zijn opgelost met 5.1

On benchmarks, we're seeing much higher random read and write scores on the Nexus 6 with 5.1; random read gets a 2x speed boost, while random write is a whopping 9x faster. The same dramatic speed boosts aren't present on the Nexus 5, and we suspect the difference is that the Nexus 6 is encrypted while the Nexus 5 is not. According to Francisco Franco, a longtime third-party Android kernel developer, Google is now using NEON instructions on the Nexus 6 to speed up encryption performance. Performance could be further improved by enabling hardware-accelerated encryption, which the Nexus 6 still doesn't use, but Google has been experimenting with the feature in the Android Open Source Project.

Bron: http://arstechnica.com/ga...-1-speed-security-tweaks/

[RagingPenguin]

Dat gaat over de schrijfsnelheden. 'other issues' zijn in dese context oa framedrops.

[Verwijderd]

BlackBerry gebruikt op de qualcomm's ook niet de standaard drivers voor encryptie. Toch deed mijn Q10 niet onder aan de n5 qua responsiveness bij de overstap. Dat je eigen encryptie standaard gebruiken je telefoon dus trager maakt gaat dus zeker niet altijd op.

[calvinturbo]

De Nexus 6 is nog steeds responsive, maar is wel duidelijk trager in benchmarks en dus soms ook met apps opstarten.

[Aaargh!]

En er zijn ook benchmarks die exact het omgekeerde tonen. Als je maar goed je benchmark kiest kan je aantonen wat je wilt.

Ik merk in de praktijk echter dat Android echt veel trager is, tijdje terug had ik een stukje code wat na zwaar optimalsieren op een SGS4 met moeite draait, blijkt na porten naar iOS als een zonnetje te draaien op een iPhone 3GS. Om maar wat te noemen.

Kan jouw benchmark aantonen wat het wil, ik koop daar niet zo veel voor. Ik merk gewoon dagelijks dat een iPhone rondjes rent om Android toestellen met op papier veel betere specs. Meer cores, meer RAM, hogere kloksnelheden, maar ondertussen in real-world toepassingen veel trager.

[Garret1410]

Ben het wel eens dat de Iphone heel goed draait en snel is. Ook de soepelheid kan Android niet aan tippen maar wat betreft pure snelheid dus apps opstarten kan ik zeggen dat de S6 heel snel is. Ik heb ze naast elkaar gelegd en grofweg zijn ze even snel. Op een paar apps na is de S6 ietsje sneller met opstarten.

Het jammere van Android is dat het soms lijkt alsof er niets gebeurt als je een app opstart terwijl de iPhone direct reageert.

[ToFast]

Dan doe je gewoon wat verkeerd...

[sfranken]

Dat komt ook omdat iOS maar op een zeer beperkt aantal HW configuraties hoeft te draaien, waardoor de compiler zwaar kan optimaliseren, iets wat bij een Android toestel niet kan.

Daartegen: Mijn OnePlus is reallife veel sneller dan een iPhone 6, alleen met booten niet. Apps starten, draaien en resultaten zijn sneller/hoger

[Aaargh!]

Ja en m'n SonyEricsson K800i draait ook sneller...

[latka]

Je bedoelt dat Java garbage collection doet en objectieve c niet? Apple doet reference counting (vroeger, pre ios5, met de hand dus crashende apps en nu automatisch). Reference counting cache behaviour is rampzalig tov. Garbage collection en kent nog steeds het probleem van cycles (ook met arc). Dus ik weet niet waar je op doelt zonder wat bronnen.

[Carbon]

Je bedoelt dat Java garbage collection doet en objectieve c niet? Apple doet reference counting (vroeger, pre ios5, met de hand dus crashende apps en nu automatisch). Reference counting cache behaviour is rampzalig tov. Garbage collection

Reference counting cache behaviour? Leg dat eens uit!

en kent nog steeds het probleem van cycles (ook met arc). Dus ik weet niet waar je op doelt zonder wat bronnen.

Strong reference cycles zijn nog mogelijk, echter de compiler/static-analyser geeft in die gevallen wel een waarschuwing.

[latka]

De counter zit bij het object, dus moet je de pointer op null zetten EN het object benaderen om de teller aan te passen. Bij gc hoef je het object niet in het hotpath te benaderen.

[Carbon]

Bij de 32-bit Objective-C runtime zit de counter niet in het object maar wordt bijgehouden middels een globale hashtable.

Bij de 64-bit runtime zitten de eerste 19 bits van de counter in de isa pointer.

[Reactie gewijzigd door Carbon op 28 juli 2024 11:03]

[Aaargh!]

Nee, ik doel vooral op het gebrek aan pointers en het feit dat Java aanmoedigt voor elke scheet een nieuw object aan te maken. Gevolg van dit alles is dat je in Java vaak nieuw geheugen alloceert omdat je data moet kopieren ipv dat je gewoon een pointer doorgeeft. Elke keer data van/naar een ander stuk geheugen lezen/schrijven verhoogt het aantal cache misses en dat is een van de manieren waarop je heel makkelijk performance verliest.

Geen JIT of compiler gaat je daar mee helpen.

[latka]

En de jit doet dit vaak op de stack wat een gratis allocatie is. Je opmerking over kopiëren snap ik niet: als een functie een string object verwacht wordt er gewoon een pointer naar de string doorgegeven en geen kopie gemaakt. Copy constructors ed zitten in c++.

[Aaargh!]

Zeg je maar wat of heb je ervaring met iOS/Android development ?

Een enkele core van een SGS6 is langzamer dan die van een iPhone 6 (benchmarks), en single-core performance is in 99% van de gevallen het enige wat er toe doet. Tel daarbij op de inefficiëntie van Java/Dalvik en het resultaat is een SGS6 die significant trager is dan een iPhone.

Maar jij gaat me ongetwijfeld uitleggen waarom een SGS6 met een tragere CPU en de giga-overhead van een allocation-heavy taal als Java sneller gaat zijn dan een iPhone 6 die native code runt.

[marhalm]

Ik heb geen verstand van programmeren. Ik kan enkel terugvallen op hoe het aanvoelt als consument (apps laden, snelheid binnen menu's etc). Aangezien je het over de performance had kan ik daar wel wat over zeggen en dan moet ik toch tot de conclusie komen dat ik het niet eens ben met jouw bewering. Het is nogal een boude uitspraak namelijk.

[Aaargh!]

Ik kan enkel terugvallen op hoe het aanvoelt als consument (apps laden, snelheid binnen menu's etc).

Dat zal best prima zijn, dingen die te traag werken release je gewoon niet. Ik heb met enige regelmaat features moeten schrappen of versimpelen op de Android versie van een app simpelweg omdat het niet lekker draaide.

Je krijgt vaak gewoon een lichtere versie van iOS apps.

[Reactie gewijzigd door Aaargh! op 28 juli 2024 11:03]

[Mlazurro]

Twitter, het blijft een wetenschappelijke bron.

[ronaldmathies]

Ik moet zeggen dat ik tot nu toe maar erg weinig berichten gezien heb op wat voor media dan ook dat het er wel op vooruit is gegaan ( buiten mischien wat syntetische benchmarks). Het gaat uiteindelijk om de gebruikers ervaring. En als die niet beter wordt dan zie je ook geen positieve berichten maar wel negatieve. Dus ja, twitter kan een bron zijn.

[Mlazurro]

Een paar enkele reacties op Twitter zeggen bitter weinig, statistisch gezien. Zoals bij alles is er een grote meerderheid die niets te klagen heeft.

Plus, iets gezien hebben op twitter is ook geen echte bronsvermelding.

[bredend]

Er zijn goedkope trage en dure snelle telefoons. En er zijn goed geprogrammeerde applicaties en er zijn slecht geprogrammeerde applicaties. Dat probleem zal dus altijd blijven.

Doordat er vele soorten chips zijn is het best handig om de code eerst algemeen te compileren, en daarna op het toestel nog eens te optimaliseren voor een specifieke chip.

[dfury]

Zeker nog nooit gehoord van PhoneGap (Cordova) waarbij er enkel HTML5, javascript enz wordt gebruikt?

[Verwijderd]

Welke van de twitters? De oude of de nieuwe? Ik kan helemaal niet meer bijhouden hoeveel twitters er tegenwoordig zijn. Ik moet zeggen dat jouw post wel erg krachtig onderbouwd word door dit sterk staaltje bronvermelding. Hulde!

[JoostyBoy]

Sneller en beter. Hoe compatibel zou dit zijn met bestaande Android applicaties? En kan het Xposed Framework doorontwikkeld worden om met de Optimizing ART te werken?

[Reactie gewijzigd door JoostyBoy op 28 juli 2024 11:03]

[morrowyn]

Tja, wat ik niet echt snap is dat mensen gaan huilen om zaken als:
- compile time,
- binary wordt iets groter( 10%-20% of whatever)
En dat allemaal ten bate van de performance.

De performance is waar het om draait want dat geeft uiteindelijk een responsive app.

Ik drink liever een extra kop koffie tijdens het wachten op een build, dan dat ik allemaal slechte reviews krijg omdat de app niet performt.
Want slechte reviews zijn wat moeilijker weg te werken dan die 5 minuten kop koffie leuten.

[Verwijderd]

Ik weet niet hoe jullie de artikelen lezen, maar in het gelinkte artikel vindt ik niet dat de nieuwe compiler Optimizing heet, ik lees dat er Optimizing gedaan wordt op ART, waar voorheen een Quick implementatie van was. M.a.w. ik denk dat de Optimizing compiler gewoon ART heet, waar voorheen de Quick compiler ook ART heette.