'Android 2.2 is 450 procent sneller dan 2.1'

De aankomende versie 2.2 van Android, genaamd Froyo, zou 450 procent sneller zijn dan de huidige 2.1 versie. De extra snelheid zou het resultaat zijn van de nieuwe Dalvik jit-compiler die in Android 2.2 standaard wordt geactiveerd.

Uit resultaten van het benchmarkprogramma Linpack blijkt dat een Nexus One met Android versie 2.2 circa 450% sneller is dan eenzelfde telefoon met versie 2.1 van het besturingssysteem. De site Androidpolice wist de hand te leggen op een testrom van 2.2 en voerde de benchmarks uit. Met Android 2.1 wist de Nexus One ongeveer 7 megaflops te scoren, terwijl met versie 2.2 het resultaat uitkwam op 37,6 megaflops. Het lijkt niet om een uitschieter te gaan, aangezien de benchmarkdatabase van Linpack verschillende entries bevat van Nexus One toestellen die met Android 2.2 zijn uitgerust en dergelijke scores neerzetten.

Eind vorig jaar werd bekendgemaakt dat de Dalvik Virtual Machine, het onderdeel van Android dat programma's laadt, een jit-compiler zou krijgen. Een dergelijke virtual machine compileert delen van de broncode van software eerst naar native code, alvorens het programma uit te voeren. Deze aanpak zou een stuk sneller moeten zijn dan de huidige. Momenteel is Dalvik een zogenaamde interpreter, waarbij broncode wordt omgezet en uitgevoerd terwijl het programma draait.

Reacties (159)

[johnbetonschaar]

Leuk en goed natuurlijk maar dit blijft natuurlijk een synthetische benchmark, en vooral bij JIT omgevingen liggen dit soort resultaten nog veel verder van de werkelijkheid dan bij gecompileerde benchmarks. Als de nieuwe Dalvik JIT net een uitbreiding heeft gekregen die precies het stukje bytecode dat hier wordt gebenchmarked goed kan optimaliseren in native code, dan runt zo'n benchmark al snel 4.5x zo snel. Of je hier in de realiteit heel erg veel van zal merken valt maar te bezien, in een real-world applicatie ga je niet 1 miljard keer dezelfde berekening uitvoeren en verder niks, dus dan is het voor de VM ook veel moeilijker om hotspots te vinden voor extra optimalisatie.

Edit:
Ik zie nu pas dat er voorheen niet eens een JIT compiler werd gebruikt. In dat geval kan je inderdaad over de hele linie grote snelheids verbeteringen zien ja (hoewel JIT-compiler benchmarks nog steeds een heel vertekend beeld kunnen geven, dat wel).

Heel vreemd dat er pas in 2.1 een JIT compiler wordt gebruikt

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 19:50]

[YopY]

Heel vreemd dat er pas in 2.1 een JIT compiler wordt gebruikt

Sja. Waarschijnlijk was dat een zodanig grote en complexe klus om een JIT te bouwen specifiek voor die toepassing dat ze dat uitgesteld hebben tot deze versie, en bleek de performance zonder JIT voldoende.

[87Vortex87]

Nee, in 2.2. komt de JIT compiler pas.

[johnbetonschaar]

Op zich begrijpelijk, maargoed als je kijkt wat er allemaal aan bestaande JIT compilers beschikbaar is (ook open-source, denk aan Psyco bijvoorbeeld) misschien wel een vreemde keuze, vooral als je een nieuw mobiel platform wilt lanceren. Dan wil je toch dat het de eerste keer gelijk helemaal super is?

[humbug]

Apple, Microsoft en dus ook Google brengen allemaal OSen uit die niet perfect zijn. Of had Apple met de iPhone moeten wachten totdat er Multitasking inzat? (Dan hadden we nog nooit van de iPhone gehoord)

[Dreamvoid]

De kop was dan ook beter geweest:
VM in Android 2.2 is 450% sneller dan in 2.1

[trion75]

En dus is Android 2.2 450% sneller dan 2.1, aangezien alles in de VM draait.

[demonite]

Waarom? Als gebruiker van een android telefoon ben je je toch helemaal niet bewust dat al je apps in een VM draaien?

[dipje2]

De Dalvik VM die gebruikt wordt in Android was nog niet toe aan JIT wat ik denk / gok.

Davik is een VM speciaal bedoeld voor lower-memory devices en andere kleine apparaten, dus een goede keuze voor de basis van een telefoon-OS.

En je hebt helemaal gelijk met de benchmarks + JIT opmerking. En meestal is de snelheid van Flash I/O de factor dat huidige smartphone's 'haperend' kunnen aanvoelen, en niet de CPU.

Maar toch, extra snelheid is nooit weg, so bring it on

[thunderbird2k]

Rekenintensieve operaties zullen door de JIT veel sneller worden afhankelijk van het algorithme. Ga er echter niet van uit dat over het algemeen Android echt 4.5x sneller wordt of in de praktijk in veel programma's dubbel zo snel. Vaak is de geheugenbandbreedte of de videokaart een bottleneck bij de prestaties.

Daarnaast zijn veel kritische onderdelen al lang in native code (C/C++) geimplementeerd.

[watercoolertje]

Dat is toch logisch, enkel de kop is wat misleidend maar als je de tekst leest trek je die conclusie ook...

Net als een 3D mark score, het is leuk en aardig maar het zegt niks over echte games of over hoe die presteren... Zelfde geld hier het is een statische/synthetische benchmark dus die resultaten kan je niet 1:1 naar apps doortrekken

Maargoed zeer spoeding zal het verder uit lekken en krijgen we nog extra nieuws van google, en zal de nieuwe snelheid waarmee het toestel op start/foto's maakt en browsed snel genoeg bekend worden, die getallen zeggen ons (als gebruiker) meer!

[pizzaislekker]

Heeft dit gevolgen voor de programma's die de Nexus One draait? En hoe zit het met andere toestellen, worden die ook sneller na een upgrade naar android 2.2?

[dipje2]

Over het algemeen niet. De ervaring die ik nu heb is dat HTC's Sense het enige is wat niet werkt met JIT aan.

Neocore, verschillende spelletjes, Copilot, Google Maps, Facebook, berg widgets, Buienalarm + spul, SMS backup... ik heb van alles draaien op m'n Hero'tje en het werkt gewoon met JIT aan.

[watercoolertje]

Je Hero is echt wel veel sneller geworden of je hebt JIT niet goed toegepast, ik heb zelf JIT op de Hero gehad en op de spontane reboots na werd alles toch wel een stuk (merkbaar) sneller, vooral met browsen merkte ik het heel erg.

Anyway, goed dat dit er aan komt, extra power is nooit verkeerd, dat zou ook betekenen dat het zuiniger wordt omdat alle taken sneller gedaan zijn

[87Vortex87]

De JIT compiler komt met Android 2.2. Android 2.1, die nu uit is, heeft alleen wat softwareoptimalisatie. Hoe kom je aan een JIT compiler op je Hero als al bekend is dat dit conflicteert met de Sense UI?

[watercoolertje]

Hoe ik er aan kom, ROM-bakkers. Wat moet ik met Sense, vind Android prima zo als het er standaard uit ziet en de widgets gebruik ik niet dus nergens last van gehad met Sense UI

Daarbij heeft ook Samsung een telefoon waar al een JIT compiler op werkt en dat is ook 2.1, en me Milestone met JIT deed dat al vanaf 2.0 en 2.0.1 Volgens mij had ik zelfs een JIT compiler op me G1 maar dat weet ik niet zeker, moet wel 1.6 geweest zijn dan!

Edit:
Exact, standaard zit het er dus nog niet in nee

[Reactie gewijzigd door watercoolertje op 23 juli 2024 19:50]

[87Vortex87]

O, dus je bedoeld dat alleen de custom roms tot nog toe de JIT compiler hadden? Ik had namelijk nog nooit gehoord van de JIT integratie in stock roms in android.

[dipje2]

Ze zijn er al een poosje mee bezig, en het zit in de source tree van Android. Het staat alleen altijd uit voor stock ROMs omdat het nog niet stabiel was.

Custom-ROM bakkers pakken de JIT source, compilen het, en zetten het aan in hun eigen ROMs.

Weet alleen niet zeker of het kan werken op 1.6, volgens mij was het voor >= 2.0.

Maar wie weet is dat ook allang anders.

Anyway, JIT is dus bedoeld om in mainstream (stock) ROMs te komen vanaf 2.2, maar de source is dus allang in de repositories beschikbaar en nieuwsgierige mensen zetten het aan en kijken wat het doet .

[_JGC_]

Die JIT-compiler compileert virtual machine code naar native code. Dit is een techniek toegepast door andere virtual machines zoals Java en .Net, maar ook Firefox doet dit tegenwoordig met Javascript. Het verschil bij Firefox is ook behoorlijk.

[watercoolertje]

Ja de JIT-compiler werkt gewoon op elk toestel, het ging juist om de ondersteuning voor Android en die is zo te zien dik in orde gemaakt

Lijkt me trouwens niet dat het overal deze zelfde verbetering mee gaat brengen maar sneller wordt het er zowiezo van

[Verwijderd]

Geen gevolgen voor de software, ook huidige software zal gebruik kunnen maken van de JIT. Andere toestellen zullen ook sneller worden. Hoeveel sneller, ligt aan de optimaliasties van de JIT compiler icm. de gebruikte CPU instructieset.

[amaterasu]

wow dat is echt een verbetering
Dat de LG gw620 maar eens word geupdate naar een hogere Android versie

[Reactie gewijzigd door amaterasu op 23 juli 2024 19:50]

[Rob Coops]

Ik zeg eerst praktijk voorbeelden van deze welhaast onmogelijke verbetering en dan geloof ik het pas. Een benchmark en zeker een benchmark die niet berekend is op een VM met een jit compiler is niet een goede manier om aan te tonen of een systeem sneller is geworden omdat er eigenlijk geen vergelijk gemaakt kan worden tussen voor en na jit. Als je een normale applicatie hebt zul je waarschijnlijk heel veel minder taken op deze manier kunnen compileren en dus heel veel minder snelheidswinst behalen. Natuurlijk zal er nog steeds wel een winst te behalen zijn van tot wel 100% met een beetje geluk een een applicatie met veel code die steeds maar herhaald wordt maar 450% is gewoon een probleem van de benchmark, niet een bewijs dat Android sneller is geworden.

[Bob]

Exactly, JIT is prima voor korte herhaalde code, precies wat een benchmark is. Stel je het andere extreme geval voor: een complexe applicatie waar weinig code meer dan enkele keren wordt uitgevoerd. Als je hier JIT forceert zal het trager draaien, het just in time compileren kost namelijk ook redelijk wat tijd, tijd die niet altijd rendeert.

[Verwijderd]

een complexe applicatie waar weinig code meer dan enkele keren wordt uitgevoerd

Misschien is die applicatie niet goed geprogrammeerd of niet getuned voor een mobiel apparaat ? Iemand die de ene keer een ArrayList gebruikt, dan weer een Vector, dan weer een List klasse van zichzelf en vervolgens weer een List uit een van de Apache Commons library zal inderdaad tegen de lamp lopen bij mobiele apparaten met beperkt geheugen en waar de applicaties meestal voor een kortere periode draaien dan op een server. Voor elke lijst klasse moet dan de JIT compiler weer worden aangeroepen terwijl de meeste List implementaties eenzelfde basis principe hebben. Iemand die dus de zogenaamd complexe server applicaties programmeert met bv JBoss en andere frameworks zal niet automatisch geschikt zijn om applicaties te schrijven voor een mobiele device. Ik ken Android niet, maar zover ik begrepen heb is het Android OS geschreven in Java ... en een OS wordt 1 keer geladen en gestart en zal vervolgens in het geheugen blijven (geschikt dus voor JIT) terwijl een leuke app misschien zeer kort draait en dus minder geschikt is voor JIT.

[Verwijderd]

Android is gebasseerd op de linux kernel, dat is geschreven in c(++).
android applicaties worden geschreven als java source maar worden niet naar dezelfde byte code gecompileerd als bij java.

[Stevendefeij]

@konin525 Ter aanvulling de linux kernel bestaat uit C en uit assembly
(lijkt me anders ook moeilijk om voor de cpu om c te snappen.)

[Verwijderd]

Android is niet geschreven in Java. Alleen de syntax is hetzelfde.

[j0bro]

Android is het operating system met de drivers, libraries en zeer belangrijk: de Dalvik Virtual Machine, allen geschreven in C.

De Android applicaties zijn allemaal geschreven in Java, maar worden na compilatie naar Java bytecode (*.class bestanden) geconverteerd naar het Dalvik Executable-formaat (*.dex bestand). Dit formaat is geschikt voor de aangepaste instructieset zoals die in de Dalvik VM gebruikt wordt, eentje die zeer geschikt is voor mobiele apparaten.

Via de SDK schrijf je apps en via de beschikbare NDK kan je ook native C code in je apps gebruiken om zo low level operaties uit te voeren, bij voorkeur voor rekenintensieve taken.

Zo moet het weer duidelijk zijn

[Adion]

Een applicatie waar geen code herhaalt word uitgevoerd zal hoe dan ook al wel snel draaien, het al dan niet JIT-compileren zal dan niet echt merkbaar zijn.
De programma's die wel merkbaar sneller kunnen zullen hoogstwaarschijnlijk toch wel ergens iets herhalend aan het uitvoeren zijn, en in dat geval zal het compileren wel snelheidswinst geven.

Het is inderdaad wel zo dat normale applicaties uiteraard niet enkel korte lussen van korte code hebben zonder andere bottlenecks, dus het is zeker niet zo dat elke applicatie nu 450% sneller zal draaien.

[demonite]

Volgens mij is het wel degelijk realistisch. Als ik het goed begrepen heb zijn alle android apps dus gecompileerd naar een intermediate language (*.dex = dalvik executable). Nu, bij het runnen van zo'n app worden alle android applicaties dus geinterpreteerd, elke statement, elke loop.
Doordat hetgene wat deze applicaties draait (de Dalvik VM) bij 2.2 dus niet meer interpreteert maar eerst compiled naar native code levert dat 450% snelheids winst op.
Dat is onafhankelijk van welke app of wat die app precies doet.
Het uitvoeren van instructies gaat sneller omdat ze niet meer geinterpreteert hoeven te worden. Bare metal performance vs interpretation.

[Verwijderd]

je vergeet even de compile tijd mee te rekenen. Dat is een eenmalige actie die normaal veel tijd kost. De JIT compiler die in de sun java vm zit, compileerd de bytecode ook alleen naar native code als het stuk meermalen wordt uitgevoerd.

De meting van 450% is natuurlijk heel extreem omdat bij een zelfde berekening die steeds maar herhaald wordt een JIT compiler extreem goed rendeerd.
Bij een enkele berekening is het juist trager, elk opvolgende zelfde berekening is veel sneller.

[naikon]

Compileren kost helemaal niet veel tijd. Een beetje efficiente compiler zet megabytes aan code per seconde om in machine code. Volgens mij word door de meeste mensen hier de kracht een van een (jit) compiler behoorlijk onderschat.

Ter illustratie, een normale VM ziet er ongeveer zo uit:
while(true) {
switch(mem[ip]) {
case ADD: mem[mem[ip+1]] += mem[ip+2]; ip += 3; break;
case JUMP: ip = mem[ip+1]; break;
... etc ....
}
}

Je kan aan het aantal indirecties al zien dat een speed up van 450% gemakkelijk te realiseren is wanneer de code direct word uitgevoerd door de CPU ipv door de VM.

Een echt goede JIT compiler kan op basis van runtime statistieken ook nog eens betere keuzes maken dan een normale (statische) compiler. Wat dat betreft is denk ik die verbetering van 450% nog maar het begin.

[demonite]

In het geval dat de JIT compiler tijdens start-up alle byte code omzet naar native code vervalt deze JIT compile tijd tijdens de executie van het programma. Dan duurt het starten van je app ietsje langer.. Van bytecode naar native code lijkt me niet een mega-zware taak die heel veel tijd in beslag neemt. Met een beetje caching van de gegenereerde byte code kom je al een heel end, en er zitten vast nog veel meer slimmigheidjes in. Het feit dat het interpreteren van bytecode maar 450% langzamer is als bare metal performance geeft al aan dat er best wel wat intelligentie in die Dalvik VM zit.

[batteries4ever]

Tja mijn eerste gedachte was: hemel, dan moet 2.1 wel gigantisch inefficient zijn.....

[Wilco87]

Helaas is dit nog niet het geval, hier gaan meerdere geruchten over rond, echter is hier helaas geen bevestiging over vanuit lg, erger nog... Zij na contact met hun blijkt dat nog niet eens zeker is of hier wel een nieuwere rom voor komt, wel heel jammer gezien 1.5 rom van de gw620 toch echt zeer achterhaald is !

[RiGhTeOuS]

Dat zou heel fijn zijn! Ik dacht dat we al op 1 mei een update kregen...

450% is echt belachelijk veel! Maar ik neem aan dat het niet bij elke applicatie is.

[vgroenewold]

Daar heb je dan weer minder kans op bij het Android platform helaas, groot deel te maken met de providers.

Als deze snelheidswinst inderdaad klopt, vind ik dat nu precies de richting wat een dergelijk platform moet hebben. Niet alleen de snelste mobieltjes nodig hebben, gewoon ook zorgen dat het systeem zelf snel en efficient blijft, liefst sneller bij iedere update. Ik raak in ieder geval steeds meer gecharmeert van Android.

edit: @Rob Coops, dat is inderdaad ook een heel goed punt. Maar dat principe heb ik altijd aangehouden, eerst zien dan geloven.

[Reactie gewijzigd door vgroenewold op 23 juli 2024 19:50]

[arnoo1]

inpreciepe zegt een benchmark ook niet al te veel, en herhalen van codes is meestal wel vrij snel, mensen kopen ook geen toestel omdat hij goed scoored met een benchmark maar eerder of het toestel goed en snel draai , we zullen uit eindelijk zelf zien/ervaren of het zo is.

[himlims_]

helaas; had je geen LG moeten kopen, als er een telefoon fabrikant is die niets heel weinig aan aftersales doet dan is 't LG wel. Geen updates, geen software, etc.
_{heb ik 't puur over mobiel - wat LG doet in andere takken ben ik niet bekend mee}

[Reactie gewijzigd door himlims_ op 23 juli 2024 19:50]

[Verwijderd]

Hier geef je zelf het antwoord al, ze maken ook andere producten en zijn waarschijnlijk op winst uit. En heb de gw620 geprobeerd maar hij wijkt best veel af van de ui van android. LG heeft hem veel te veel aangepast imho. Geef mij maar een HTC. Zij maken tenminste erg goede telefoons en je krijgt later ook de beloofde updates.

[k7of9]

LG heeft het teveel aangepast zeg je...om vervolgens HTC te prijzen, die de UI veel diepgaander aanpast. Beetje tegenstrijdig.

En om HTC te prijzen om hun updates vind ik ook wat vreemd. Ze lopen nog steeds hopeloos achter.

Ik heb zelf een HTC hoor daar niet van. Wel een met een stock UI gelukkig.

[Verwijderd]

Het werd tijd......

[sys64738]

Vrij kort na de introductie heeft LG al bekend gemaakt dat er geen updates gaan komen voor de GW620..... dus reken er maar niet te hard op.

[Verwijderd]

Ik zal wel wat missen, maar waarom wordt binnen android uberhaupt gewerkt met niet-native code? Lijkt me dat je op een low-power platform als een mobiele telefoon toch zoveel mogelijk snelheid wil hebben, dus dat je dan een android versie erop gooit die gecompileerd is voor de architectuur die je device gebruikt?

Ik heb het dus puur over base-android niet over allerlei gekke apps die wellicht in java geschreven worden en in de marketplace geplempt worden (als dat kan).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:50]

[Dreamvoid]

Grootste reden is veiligheid, in een managed code omgeving kan je veel strakkere regels afdwingen (en heb je geen last van buffer en stack overflows) dan wanneer je alle apps maar lekker in native code rond laat banjeren. Daarom is de iPhone zo makkelijk hackbaar (en screent Apple elke app afzonderlijk), daarom stapt Microsoft bij WP7 over naar een .NET/XNA-based framework, daarom heeft Blackberry ook alles in een Java VM draaien. Je wil applicaties uit de grote boze buitenwereld kunnen sandboxen.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 19:50]

[RielN]

Ik denk dat de grootste reden de portability is.

[Dreamvoid]

Welk ander platform draait dan Dalvik?

[johnbetonschaar]

Er zijn Android devices op x86, op ARM, en volgens mij zelfs op verschillende ARM instructiesets. Portability is dus zeker wel een groot voordeel, anders zou je nooit een Android applicatie voor ARM kunnen draaien op een Android tablet met x86, bijvoorbeeld.

Maar verder heb je gelijk wat betreft de veiligheid en stabiliteit, een van de grootste voordelen van een VM is dat je inderdaad veel makkelijker processen van elkaar kan scheiden, sandboxen, geheugenfouten kunt detecteren en isoleren etc.

Dus zowel portability als security/stability

[84hannes]

Ik durf ook niet te beweren dat Android zelf in Dalvik draait. Vrijwel alle software die er op draait echter wel. Zodoende kan je Android programma's eenvouedig naar alle devices porten (zonder (her)compilatie). Bij die rare interfaces die fabrikanten menen te moeten toevoegen denk ik wel dat gebruik wordt gemaakt van Native code.

[humbug]

Belangrijk voordeel is hardware onafhankelijkheid. Schrijf een andere kernel en jit compiler en je complete programma biblioheek is verhuist. Daarnaast is een goede JIT compiler vaak beter dan een statische compiler omdat die JIT compiler precies weet welke hardware jij tot je beschikking hebt. Bij een statische compiler kom je toch vaak uit op iets wat overal op draait en dus veel optimalisaties mist.

Wat jij dus feitelijk wil (een geoptimaliseerde base en portabele applicaties) is dus precies wat Android doet.

[nika]

Zo, 450% dat is nogal wat. Ik heb geen ervaring met Android, maar was 2.1 dan zo'n ontzettende slak?

[Deem]

Nee, absoluut niet. Sterker nog, 2.1 is sneller dan bv 1.5 omdat ze het geheugen-management hebben verbetert waardoor alles sneller werkt.

[Flying Bobman]

Ik kan me dan ook moeilijk voorstellen dat je het echt gaat merken, die 450%. Als nu al 95% van alle apps direct op je scherm staan, wat moet er dan nog sneller Misschien dat het eens tijd wordt voor zwaardere apps, meer 3D en grafische opsmuk. Zou die 450% ook gelden voor Flash 10.1? Of draait dat weer anders? Ik hoop echt dat Adobe kan bewijzen dat Apple er naast zit en dat alles gewoon lekker vloeiend loopt op een smartphone. De filmpjes die er tot nu toe zijn, zien er redelijk veelbelovend uit voor een beta.

[Verwijderd]

Juist, dat denk ik dus ook. Dat er zwaardere games uitkomen en voor flash heb je ook een snel OS nodig. Ik hoop dat het ook op de Legend gaat werken. Dan waarschijnlijk wel zonder flash...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:50]

[Ganymedus]

Hm dat maakt de noodzaak van 1 GHz processors enigszins overbodig. Goed nieuws voor telefoons met een 600 MHz processor.

[Voxyn]

Tsss wat ben jij nou voor een tweaker een echte tweaker vind een snellere processor is altijd beter


Ontopic: Is eigenlijk ook bekend of er verder nog grote veranderingen inzitten of allen performance fixes?

[Reactie gewijzigd door Voxyn op 23 juli 2024 19:50]

[watercoolertje]

De market is op de schop geweest, zo kan je bij apps aangeven dat ze altijd auto. geupdate moeten worden (op eigen risico neem ik aan, of misschien geeft ie wel een waarschuwing als het programma ineens extra rechten wilt)... Tevens zou alles wat overzichtelijker moeten worden binnen de market.

Flash 10.1 Beta zal er waarschijnlijk in gebakken zitten

JIT-Compiler zoals je hier kan lezen zal er dus ook in zitten!

Apps2SD maar of dat er nu in gaat komen of in een latere release is me niet helemaal duidelijk.

Overall tweaks uiteraard, alles kan altijd beter dus ik neem aan dat er op meerdere gebieden (kleine) optimalisaties uitgevoerd zijn.

En het updaten per Android-onderdeel via de market zou er ook in zitten, maar ook dat kan in een latere release zijn (nergens wordt bevestigd dat dat in 2.2 gaat zitten), denk eerder Gingerbread (Android 2.5 of 3)

[_beevee_]

Het is vrij aannemelijk dat tegen het einde van deze maand the final FP 10.1. (i.i.g.) voor Android beschikbaar is. Dat werd de afgelopen dagen tijdens de Adobe developers week i.i.g. gesuggereerd ... e.e.a. zal waarschijnlijk op 20/21 mei a.s. op het Google I/O developers event aangekondigd en snel daarna gereleased worden (ik denk ook Android 2.2).

[Verwijderd]

Snellere processor = accu sneller leeg, het is juist de kunst om de CPU precies snel genoeg te maken.

Trouwens, kun je geen native binaries installeren op Android? Als dat allemaal door een general purpose CPU gecompileerd moet worden kan ik me wel iets voorstellen bij die traagheid ja... net zoiets als Java eind jaren '90: ook niet vooruit te trappen op je (toen) gloednieuwe Pentium 2 machine.

[Verwijderd]

En het verschil met java tegenwoordig is.. wat?

[Verwijderd]

Java op telefoons is tegenwoordig JIT in hardware, dat scheelt wel veel.

[MSalters]

Dat de desktop CPU tegenwoordig snel genoeg is dat de gebruiker weer de traagste factor is, niet het Java programma.

Bij een telefoon is je probleem niet alleen de snelheid. Het elke keer opnieuw compileren vreet ook nog eens batterijen.

[dipje2]

Daarom worden de applicaties ook 1-malig gecompileerd bij installeren en bij first-boot na installatie van een ROM.

In Android, de Dalvik-Cache

[_beevee_]

domme vraag: is de accu van een snelle processor eigenlijk sneller leeg dan die van een langzame processor als beide hetzelfde doen?

[humbug]

Ja en nee

Als de twee processors intern hetzelfde zijn en er enkel een snelheidsverschil. Ja. Dan staat de snellere processor welliswaar uit zijn neus te eten maar ook dat kost inspanning.

Als de twee processors niet exact hetzelfde zijn (ander deel van de waffer, ander model enz) valt er weinig over te zeggen. Een P4 op 3GHZ is waarschijnlijk langzamer dan een dual core Atom, maar verbruikt toch meer.

[SlagerBlom]

Ik tweak mijn pc zo dat hij het minst energie verbruikt en toch acceptabele prestaties neerzet. Onderclocken heet dat ook wel...

[Stukfruit]

Android-telefoons doen dit ook, maar dan automatisch.

[aval0ne]

Tsss wat ben jij nou voor een tweaker een echte tweaker vind een snellere processor is altijd beter

Nee, voor een tweaker is een trage processor die je sneller kan doen lopen beter.

[Cid Highwind]

Op den duur zullen die hun meerwaarde ook vast wel bewijzen, met name in applicaties zelf. Maar ik dacht inderdaad precies hetzelfde, aangezien ik op een Legend zit. Minder overhead van het OS is sowieso altijd beter.

[iMispel]

Als Nexus One gebruiker vind ik dit natuurlijk fantastisch nieuws. Maar eigenlijk kunnen we hier ook uit concluderen dat de huidige Android 4 keer te traag is... Ik vraag me dan ook af hoe de huidige Android presteert tegen de iPhone, waar alles in (Objective-)C is geschreven, dus sowieso reeds geoptimaliseerd is.

BTW: Dit bewijst nogmaals dat goed geschreven software minstens even belangrijk is dan rauwe harware specs.

[RielN]

De iPhone heeft inderdaad wel die gigantische respons en soepelheid die android, ben eerlijk, niet heeft. Ik heb zelf de G1, verwacht vandaag de desire te krijgen, en hoop stiekem dat ie de respons a la iPhone kan waarmaken straks.

[87Vortex87]

Ja, de respons en soepelheid is ongeëvenaard op de iPhone. Dat zal niemand ontkennen. MAAR! Met de Desire moet ik eerlijk zeggen dat Android naast iPhone is komen te staan. Kijk maar naar de youtube-filmpjes waar het browsen wordt vergeleken.

De Desire heeft Android 2.1, dus nog geen JIT Compiler. Met Android 2.2 zal de Desire waarschijnlijk ook de nieuwe iPhone gewoon bijhouden en wellicht zelfs iets beter zijn.

Anders gezegd, eerst maakte Android een inhaalslag middels de hardware (terwijl de iPhone het nog op mindere hardware, beter deed), nu is de software aan de beurt en zal het verschil, imo, geheel worden weggewerkt.

Het zal dus uiteindelijk aankomen op smaak, gevoel bij het merk/bedrijf en wat je als intuïtieve UI beschouwd.

Edit: @hieronder: Okè, iPhone 3GS dan

[Reactie gewijzigd door 87Vortex87 op 23 juli 2024 19:50]

[aval0ne]

Ja, de respons en soepelheid is ongeëvenaard op de iPhone. Dat zal niemand ontkennen.

Toch wel, ik vind de respons van een niet 3gs iphone ondermaats, zeker als je veel apps geinstalleerd hebt.

[Helsie]

De Desire kan dat wel ja. De G1 'niet echt'.
(Heb sinds gister Desire, mijn vrouw heeft al een tijd de G1)

[DCK]

Natuurlijk mag je dat niet concluderen. Er staat alleen dat Android sneller is, als het echt te traag was geweest was die JIT-compiler wel een grotere prioriteit geweest. Android 2.1 is een besturingssysteem dat vrijwel net zo responsief is als iPhone OS , en dat met multitasking, dus zelfs geinterpreteerd doet Android het niet slecht.

Overigens heeft de programmeertaal (Objective-C) weinig te maken met hoe 'geoptimaliseerd' een programma is; dat ligt aan de runtime. Java kun je ook naar native code compilen bijvoorbeeld. Als je kijkt naar geoptimaliseerde code ben ik subjectief van mening (en ik weet dat die mening met mij gedeeld wordt) dat Java (zoals gebruikt wordt om voor Dalvik te schrijven) nettere, leesbare code oplevert dan Objective-C.

[chronoz]

Het was ook wel nodig, mijn HTC Hero loopt erg onstabiel op HTC 2.1 custom roms, terwijl ik juist de stabiele heb uitgezocht.

Hopelijk komt er dan ook eindelijk een goede mediaspeler.

Go Android!

[Verwijderd]

Voor de Hero schat ik de kans op een 2.2. rom ongeveer 0.1%.. Wellicht dat er mogelijkheden bestaan om de release JIT naar 2.1 te porten, maar stabiliteit zal er dan alleen maar minder op worden.

Ik vraag me trouwens af waarom je stabiliteit koppeld aan dit onderwerp? Ik heb ook meerdere 2.1. ROMS geprobeerd en geen enkele was onstabiel, wel een paar kleine mankementjes, maar dat is wat anders dat instabiliteit.

[watercoolertje]

Tuurlijk is dit rock solid, anders gaat google het er echt niet in bouwen, ja dat bij onze ingebouwde JIT-Compiler je toestel elke X uur ff reboot klopt maar dat zegt niks over hoe goed/slecht google het er in kan krijgen Zegt meer over ons zelf/devvers

[Reactie gewijzigd door watercoolertje op 23 juli 2024 19:50]

[Verwijderd]

Hmmm SE X10 moet dat dit ook maar krijgen haal nu net de 5 mflops

[Deem]

Het zal waarschijnlijk een feature worden van Froyo 2.2. Ik hoop voor SE dat ze afzien van 2.1 en direct doorgaan met 2.2

[watercoolertje]

Hoop het ook want 2.1 heeft met die CPU@1Ghz (zelfde als de nexus one toch?) maar 7 MFLOPS Evengoed een voorruitgang, maar liever 700% of meer (van 5MFLOPS naar 37MFLOPS)

[Reactie gewijzigd door watercoolertje op 23 juli 2024 19:50]