Intel: Android niet erg geschikt voor multicore-processors

Volgens Intel zou er meer gedaan moeten worden om Android te optimaliseren voor chips die over verschillende processorkernen beschikken. De fabrikant roept makers van socs op om het OS te optimaliseren voor meer dan één core.

Intel-topman Mike Bell claimt dat de ingebouwde thread scheduler van het Android-besturingssysteem verbeterd moet worden om de beschikbare processorkracht in multicore-socs te kunnen benutten. Omdat mobiele apparaten doorgaans een beperkte accuduur hebben, is het effectief aan- en uitzetten van processorkernen belangrijk, maar Bell claimt dat Android hier niet goed mee omgaat. Zo zou het OS bij het uitvoeren van een taak vaak andere threads stoppen, wat de snelheid niet ten goede komt. De topman pleit voor verbetering in de manier waarop het OS threads over de beschikbare cores verdeelt.

Bell zei ook dat Intel tests heeft gedraaid waarbij multicore-chips slechter presteerden dan singlecore, maar hierover werden verder geen details gegeven. Hij roept soc-fabrikanten op om meer te doen om Android compatibel te maken met multicore. Daarbij moet vooral de scheduling van threads verbeterd worden om effectiever met de beschikbare processorkracht om te gaan.

Android-toestellen zijn door fabrikanten in rap tempo voorzien van dualcore-soc's: de meeste high-end modellen beschikken minimaal over twee kernen, terwijl nieuwe smartphones, zoals de HTC One X en Samsung Galaxy S III, al over vier stuks beschikken. Apple gebruikt momenteel een dualcore-chip voor zijn iPhone en iPad, terwijl Microsoft voor Windows Phone nog geen multicore-socs toestaat. Mogelijk wordt dit in Windows Phone 8 wel mogelijk.

Onlangs kwam de eerste smartphone op de markt die is gebouwd rondom een Intel-soc, uit de speciaal voor mobiele apparaten ontwikkelde Medfield-serie. Om het uitbrengen van Android-apparaten met Intel-hardware te bevorderen bracht de fabrikant een port uit die Android 4.0 geschikt maakt voor de X86-architectuur.

Reacties (144)

[Lisadr]

Linaro is bezig geweest met de optimalisatie van Android en heeft het (volgens hun benchmark) 2x sneller laten draaien.

http://www.androidauthori...t-as-stock-android-92831/

Binnenkort zal het onderdeel worden van CM9
http://www.androidpolice....t-are-being-added-to-cm9/

Dit is voor mij bewijs dat Android veel efficiënter met hardware kan omgaan mits het geoptimaliseerd gaat worden.

[vali]

Bekijk dezetopic op xda developers maar eens, krijg je een heel ander beeld ervan. Komt naar voren dat linaro helemaal niet 2x zoveel sneller is.

Zou mij niks verbazen dat het een en ander getweaked hebben binnen android en stabieler draaien in tegenstelling tot een stock rom.

[Reactie gewijzigd door vali op 27 juli 2024 20:18]

[bazs2000]

Dat ziet er goed uit. Android is in de 'normale' vorm niet verkeerd maar er is nog veel ruimte voor verbetering. Ik heb een ZTE Blade en wat mij vooral stoort is dat Android vrij log is. Een oude build draait prima terwijl 4.0 erg log aanvoelt. Het loopt allemaal wel vloeiender maar even naar een menu gaan geeft toch wat lag.

Tweaken kan maar uiteindelijk zit je tegen de max terwijl je weet dat het beter kan. Microsoft heeft dat tezamen met Apple toch een stuk beter voor elkaar. Microsoft bewonder ik dan weer omdat WP7 op 'mindere' specificaties een hele goede performance kan neerzetten. Android heeft op dat gebied nog een lange weg te gaan en Linaro zou nog weleens een hele belangrijke input hebben gegeven.

Ik kan niet wachten totdat het in CM9 is verwerkt want dan gaat het ook meteen op mijn telefoon.

[Dreamvoid]

En WP7 is puur gebouwd voor single core Qualcomm SoC's, dus daar heb je in feite hetzelfde verhaal als bij iOS: het is lekker optimaliseren voor 1 stuk hardware, maar lastiger als je het generiek wil doen.

[scsirob]

Zal wel aan mij liggen, maar op mijn telefoon hoef ik geen top-speed te hebben. Ik wil een goede balans tussen vlot werken en lange accuduur. Dat laatste is voor mij veel belangrijker dan 20 apps tegelijk laten racen. What's next, overclocked Samsung Galaxy met een extra accu en een watercooling stack op je rug??

[watercoolertje]

Nee waarom watercooling?

Ik heb een SGS3 op 1.7Ghz, gewoon omdat 1.7Ghz maar 1.325v vraagt terwijl standaard het toestel op 1.4Ghz draait en 1.35V krijgt Hoewel mijn naam anders doet vermoeden, wordt mijn telefoon helemaal niet warmer door die overclock, en als die niet op 1.7Ghz draait (wat ie zeer zelden nodig acht) is die nog zuiniger en dus minder warm dan een stock toestel ook!

[zonoskar]

Android heeft hetzelfde 'probleem' als Windows. Het moet op heel veel en heel verschillende hardware draaien. Van een 500 MHz single core tot een quad core met companion CPU. Van een low-end tot een high end GPU. Dan is het gewoon lastig om alles te optimaliseren, want een optimalisatie voor de ene CPU/soc hoeft niet perse te betekenen dat dit ook goed is voor een andere CPU/soc.

[simplicidad]

Nu men vraagt waarom vraagt Intel die aan de andere SOC bouwers ? Simpel, marketing.

Intel claimde enkele dagen terug dat het significante optimalisaties heeft gedaan ivm multicore en Android MAAR het is niet zeker dat het dat wil delen

Intel claims it is making significant improvements to the multicore performance of Android - but isn't sure if it's willing to share them with the open-source community.

http://www.pcpro.co.uk/ne...ut-is-it-willing-to-share

Ik vermoed dat het artikel (of bron artikel) dit stuk misschien ontbreekt en het veel eerder gaat om de impressie te wekken dat Android systemen met intel beter of optimaler zijn dan de andere varianten.

Dus blijkbaar heeft Intel wel beschikking over een geoptimaliseerde Android met betere thread support.

[Reactie gewijzigd door simplicidad op 27 juli 2024 20:18]

[Dreamvoid]

Is natuurlijk ook logisch - voor wat hoort wat. Intel heeft weinig zin om veel werk te steken in de multicore scheduler van Android, waarna de ARM fabrikanten "dank je wel" zeggen zonder zelf iets bijgedragen hebben aan het project. Daarom dus blijkbaar deze oproep voor meer activiteit vanuit het ARM kamp.

Geen marketing dus, maar gewoon business.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[simplicidad]

Ik vind dat een rare stelling omdat Android een open project is of toch grotendeels. Je zou toch verwachten dat anderen ook iets hebben bijgedragen tot het platform. En gezien Intel vrij laat in het verhaal is gestapt heeft het ook kunnen meeprofiteren van de contributies die anderen voor hen op dat moment hadden gedaan.

Op zich vind ik het een arrogante en opmerkelijke houding omdat die dingen veelal zijn gebouwd op het werk van een ander. Moest iedereen Intel zijn houding adopteren dan was er ook geen sprake van de zaken waar ze nu over spreken of van meeprofiteren.

Inderdaad het is een business beslissing om dit voor hunzelf te houden, maar het zo portreteren naar de pers toe is wel pure marketing.

[Reactie gewijzigd door simplicidad op 27 juli 2024 20:18]

[Dreamvoid]

En gezien Intel vrij laat in het verhaal is gestapt

Laat? Intel is al sinds de jaren 90 met Linux bezig, en al jarenlang met Android. Waar denk je dat GoogleTV op draait?

Als je kijkt hoe Linux in de server wereld draait, dat is echt een gelijkwaardige samenwerking tussen de grote Linux-vendors: IBM, Oracle, Red Hat, Novell, Cisco, Canonical, Intel, AMD, Google (en zelfs MS), etc dragen allemaal structureel veel code bij aan het project. Bij een project als Webkit is het niet veel anders, de grote gebruikers zijn ook de grote contributeurs. Voor commerciele bedrijven (en dat zijn Intel, ARM, de SoC fabrikanten en Google allemaal) staat of valt het hele cooperatieve OSS model met een (min of meer) eerlijke verdeling van resources. Teveel freeloaders (en dan bedoel ik niet een paar tweakers met een hobby distro/mod) en het enthousiasme van de grote contributeurs gaat snel omlaag.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[simplicidad]

Ten eerste Android heeft nog relatief weinig met linux te maken. En daarbij zie ik nog altijd niet wat dat te maken heeft met de stelling dat Intel laat in het Android verhaal is gestapt.

Want ten tweede Intel IS relatief laat in het Android verhaal gestapt. De Android x86 port waar mensen dan naar verwijzen was geen officiële port.

Denk dat ze 2 jaar na de eerste SDK maar pas hadden aangegeven te beginnen om het te ondersteunen en eigenlijk nadien heb ik niet veel meer gezien dan press releases. Geloof dat ze pas vorige maand de eerste officiële x86 Android emulator hebben gereleased... http://android-x86.sceners.org/en/?p=515

En op je vraag te antwoorden over Google TV. Het draait op ARM hardware blijkbaar was x86 toch niet dat (http://www.cultofandroid....f-next-gen-device-at-ces/) en dat voor iets wat "jarenlang aan gewerkt zou zijn".

Trouwens Meego vergeten die ook het android alternatief moest zijn ? http://nl.wikipedia.org/wiki/MeeGo

[Reactie gewijzigd door simplicidad op 27 juli 2024 20:18]

[Dreamvoid]

Ten eerste Android heeft nog relatief weinig met linux te maken.

Wat een onzin, Android is een 100% Linux distributie. Net zoals Ubuntu, Red Hat, WebOS, Access, LiMo, MeeGo, BlackHole, Crystalbuntu, DD-WRT, en al die andere distro's. Linux is Linux. Wat er bovenop gebouwd is kan van alles zijn, het blijft allemaal Linux.

En op je vraag te antwoorden over Google TV.

Ja, in de toekomst draait GoogleTV ook op ARM. Maar de eerste generatie GoogleTV draaide op Atom, dus Intel was er wel degelijk vroeg bij. Vroeger dan de ARM fabrikanten in elk geval.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[Sebazzz]

Ik vind het een raar, maar wel een waar lijkend verhaal. Ik was bijvoorbeeld gisteren in de Mediamarkt en ze hadden daar bij de 'Samsung Hub' allerlei toestellen zoals de Galaxy SIII, Galaxy Tab en Galaxy Note uitgestald staan.

Ik heb er even mee gespeeld maar je ziet dan toch dat zelfs het scrollen over het homescreen van de telefoon/tablet niet 100% soepel gaat en ietsje schokkerig gaat. Dan vraag ik mij toch af hoe men dat voor elkaar krijgt terwijl een behoorlijk krachtige processor onder de motorkap zit. En de Lumia 800 doet het juist hartstikke soepel, met veel minder krachtige hardware.

Misschien dat het niet aan de onderliggende kernel en componenten ligt, de Linux kernel heeft natuurlijk al vele iteraties aan optimalisatie gehad. Ik vond namelijk Android ported to C# wel interessant om te lezen: de .NET runtime draait met een grotere performance dan Android 'native' Java.

[Dylan93]

Ik heb er even mee gespeeld maar je ziet dan toch dat zelfs het scrollen over het homescreen van de telefoon/tablet niet 100% soepel gaat en ietsje schokkerig gaat. Dan vraag ik mij toch af hoe men dat voor elkaar krijgt terwijl een behoorlijk krachtige processor onder de motorkap zit. En de Lumia 800 doet het juist hartstikke soepel, met veel minder krachtige hardware.

Dit komt omdat bij Android de interface pas sinds Android 4 volledig de GPU gebruikt, en zelfs nu het dat doet is de thread die de UI afhandeld een thread met normale prioriteit en niet realtime zoals bij iOS en WP is, hierdoor voelt Android niet vloeiend aan en zal dit waarschijnlijk ook nooit gebeuren. Het is de keuze van Google destijds geweest en naar mijn mening een design fout.

[awenmaek]

design fout

Je kan het noemen hoe dat je het wil, maar ik zou het eerder "design keuze" noemen.

De GUI in realtime laten draaien heeft ook zijn problemen. Het maakt oa. multitasken problematisch.
Probeer eens te scrollen op een iphone (vinger niet van het scherm loslaten) tewijl je een webpagina inlaadt: het inladen van de pagina stopt volledig (en dan heb je helemaal niets aan jouw dual core). Android laadt deze gewoon verder in, maar op mindere hardware kan je dan wat schokken hebben.

In de toekomst lijkt mij dat multitasken toch meer gaat doorbreken op vlak van phones/tablets. Android is hier nu ook de enige met full-multitasking (ipv taskswitchen of in beperkte mate op de achtergrond iets mogen draaien).

[Erwin1967]

Al is het een keuze, ik vind het een foute keuze. De interactie met een gebruiker is het allerbelangrijkste wat er is. Een tablet ( of smartphone) moet altijd direct reageren. Het zal een doorsnee gebruiker worst zijn of het echt multitasking is of niet. Wat een gebruiker wel opvalt zijn haperingen en schokkerig scrollen. Bij iOS wordt het afremmen van het scrollen zelfs getoond waardoor er ook weer een vloeiendere indruk ontstaat. Op mijn Nexus stopt het scrollen nog steeds 'plotseling'.
Overigens is multicore juist bedacht om geen last te hebben van meerdere threads. Dus een thread top prioriteit geven zou niet zoveel invloed moeten hebben op de andere threads.

[Nibbz]

Op openbare telefoons worden veel apps geinstalleerd door iedereen die hem vast pakt? Misschien dat hij daarom beroerd loopt na een poosje.

[zonoskar]

Waarom zou de hoeveelheid apps invloed hebben op de snelheid van het apparaat? Enkel draaiende processen hebben invloed en Android kan hier redelijk goed mee overweg (taken worden uitgeschakeld als dit nodig is). Bij het scrollen maak je veelal gebruik van de GPU (bij Android 3.2 of hoger) en ik kan me niet voorstellen dat er een taak op de achtergrond draait die de GPU belast.

[ronaldmathies]

Nee, lijkt mij niet tenzij al die apps op de achtergrond (actief) draaien. Want als na het installeren van een aantal apps het scrollen niet meer soepel gaat dan is er nog veel meer mis dan alleen het threading mechanisme.

[RoccoS]

Juist niet. Op al die telefoons en tablets in winkels is vrijwel nooit een account geïnstalleerd waarmee je apps kunt downloaden, soms is er niet eens een internetverbinding actief.

[Verwijderd]

Ik ervaar dit ook. Veel tablets/GSM's geprobeert en zie telkens de zelfde hikjes en onderbrekeningen daar waar het vloeiend zou moeten zijn.

Het is erg pijnlijk om te moeten zien dat de MONO VM (geen .NET zoals jij zegt of ik moet ergens wat gemist hebben in het artikel) het beter doet qua performance dan Android's Dalvik VM.
Heel interessante ontwikkeling.
Google heeft hier nog wel wat te doen daar zijn wij het over eens.

[mrdemc]

http://www.mono-project.com/Main_Page
Zoals je ziet is Mono een opensource variant op het .NET framework. Niet hetzelfde, maar werkt wel zoveel mogelijk hetzelfde zodat je applicaties kunt porten.
Heeft verder weinig meerwaarde op wat jij zegt en wat hierboven is gezegd, maar ter info

[Verwijderd]

ik weet het maar is niet gelijk aan .NET

[Verwijderd]

Dat heeft volgens mij weinig met processorkracht maar meer met het gebruikte algoritme te maken. Zie FireFox 13, die opeens ook stukken soepeler scrollt dan eerdere versies.

Wat niet wegneemt dat een jonge VM als Dalvik waarschijnlijk zeker nog niet perfect geoptimaliseerd zal zijn.

[Verwijderd]

welke widgets stonden open?
er zijn een aantal widgets die moeten iedere keer eerst laden. er zijn er zelfs die updaten zich eerst nog.
Daar heeft het volgens mij het meeste mee te maken.
Als mijn weer app aan het updaten is gaat het switchen van homescreen ook wat soepeler.

maar ik heb altijd gezegd, ik heb liever hoomescreens met widgets die 1 a 2 sec even haperen dan helemaal geen homescreens en widgets.

Maar het is wel vreemd ja, dat terwijl de rest van de telefoon nergens hapert e.d.

[Verwijderd]

Omdat Samsung en HTC troep als software erop zetten die de telefoons ontzettend vertragen. Kijk naar Sony, het kan wel bij Android met mindere hardware ook.

[Mellow Jack]

Helaas wordt dat niet veroorzaakt door Android. Dat is echt de schuld van Samsung. Mijn SGS2 icm ICS (Cyogen Mod) draait vele malen lekkerder vergeleken met een iPhone 4s.

Dit gaat dus meer over het batterij verbruik. Dmv een goede scheduler kan je eerder/langer je cores uitschakelen en verbruik je zo minder power

Al vermoed ik dat ze hier 2 punten willen maken. Eerste punt is het bericht zelf en het tweede punt is natuurlijk even een steek onder de riem naar de andere fabrikanten en het platform waar Intel maar niet groot op kan worden...... Ze zeggen dus eigenlijk... Het komt niet omdat wij geen producten kunnen maken die werken op Android... Het komt door Android omdat die niet goed omgaat met de producten die intel maakt (terwijl het eigenlijk een beetje van beide is)

[Reactie gewijzigd door Mellow Jack op 27 juli 2024 20:18]

[awenmaek]

De default schermen van Samsung staan meestal vol met geheugen en processorverslindende widgets (weer, nieuws, zware kalender widget, aandelen widget,,...). Als er iemand van de winkel nog eens een achtergrondanimatie aanzet is het een compleet feestje.
Na deze weg te nemen is al stukken beter (hoewel ik moet zeggen dat Android 4.0 op een Galaxy S2 er al minder moeite mee heeft).

De meeste OS'sen hebben trouwens op hun homescreen enkel starticoontjes (IOS) of vereenvoudigde widgets (Windows phone).
Om de vergelijking te maken moet je het apps screen open maken en daar in scrollen.

[thekingofping]

Linux>Android>Samsung skin: lijkt me ook niet bevordelijk voor performance. Zelfde Samsung gsm als Nexus zonder Samsung skin draait al soepeler.

[mrdemc]

Als het standaard geinstalleerd staat op een telefoon, kun je op z'n minst verwachten dat het soepel loopt

[g4wx3]

linux is de kernel, zonder extra programma heb je niks.

Android implementeerd rechtsreeks op linux, draaid een VM, en de meeste delen van android draaien dan weer in de JAVA-VM

[CaPtAiNCaRnAgE]

Waarom doet Intel zijn beklag bij de makers van SOCs?
In geval van een software-issue lijkt het me dat Google, als maker van het kale Android, het eerste aanspreekpunt zou moeten zijn voor Intel. De makers van hardware hebben, zeker in de embedded wereld, wel wát ruimte om een en andere af te stemmen en te optimaliseren, maar als volgens Intel Android's thread scheduler het probleem is blaffen ze tegen de verkeerde boom dunkt me.

[Dreamvoid]

Android is open source, het hele idee is dat alle fabrikanten meehelpen. En niemand kan schedulers beter optimaliseren dan de cpu makers zelf. Zo werkt het ook bij GNU/Linux - Intel, AMD, IBM, Oracle, etc dragen bakken met code bij om de schedulers beter te maken voor hun cpu's.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[H!GHGuY]

Het gaat om de linux kernel en mogelijk enkele dalvik zaken die thread scheduling beinvloeden (zoals thread affinity, thread scheduling policy, priority/nice levels, ...)

Het is algemeen geweten dat de Linux kernel scheduler op enkele vlakken wat tekort schiet:
- interactiviteit (zie bvb de brainfuck scheduler en recenter ook de barbershop load distribution algorithm scheduler (https://lkml.org/lkml/2012/2/12/64))
- power-aware scheduling (power usage <-> speed)
- asymmetric multi-processing (verschillende cores zoals bvb big.Little concept van ARM)

Ik vermoed dan ook dat Intel's claims vooral hierover gaan. Anderzijds wordt er binnen de kernel community wel degelijk aan deze zaken gewerkt.

[ronaldmathies]

Het gaat om de drivers, Intel is van mening dat de SOC makers hier meer verantwoordelijkheid en ondersteuning in moeten geven. Je kan je drivers maar net zo goed maken als dat de informatie voorziening van de SOC leverancier is.

Dus dat ze hun beklag doen bij de SOC producenten is logisch. Een mooie vergelijking is de onderteuning van video kaarten onder Linux. Daar klaagte ook iedereen dat NVidea en Ati meer moeite zouden moeten doen voor goede ondersteuning en betere performance, en ook daar betrof het een driver probleem.

[Wulfklaue]

Wij van WC eend...

Pikant detail, intel komt uit met hun concurrerende CPU ( Medfield ), en deze is ... single core.

Is het nu toevallig, dat Intel commentaar heeft, hoe slecht Android het doet in multi-thread scenario's wanneer hun oplossing "single" thread is.

Dat is zoals zeggen: Android Multi-Thread sucks, please buy our single thread solution, that kicks ass...

Je kan zeggen dat Intel dit bericht lanceert uit de puur goedheid van hun hart. En ik vertel je dat Sinterklaas iedere jaar snoep voor je gereed zet.

Dat Android heel wat kracht onbenut laat, lijkt mij zelf logische. Hoeveel verschillende CPU, GPU, en andere hardware combinaties moet Android wel niet ondersteunen? Het gevolg is dat als je voor één platform specifiek optimaliseert, dat natuurlijk de boel beter zal draaien.

Als je naar Windows 8 kijkt, dit zal lekker vlot draaien, aangezien MS beperkingen in plaats gesteld heeft voor de hardware waarop "hun" OS mag draaien. Met als gevolg dat men meer kan optimaliseren.

En dan spreken we nog niet van al die ROMMEL, dat fabrikanten bij op Android smijten, voor extra inkomsten, maar dat soms de boel enorm vertragen. Doet me terugdenken aan die HP, en andere PC's dat ze vol smijten met tijd beperkte virusjagers, en andere rommel, in de hoop dat je het zou kopen, en dat je PC 5* langer deed om op te starten, dan met een proper systeem.

Als er problemen zijn met Multi-thread, dan ligt het vaak omdat heel wat programma's voorzien zijn om in Single thread te draaien. In tegenstelling tot de PC wereld, waar we JAAAAAAAREN om gedaan hebben, van toen de eerste dual thread cpu, naar dual core cpu's, naar quad cores. In de ARM CPU wereld, is dit echt op verdekken korte tijd gegaan, dat we van Single Core, naar Quad Core gesprongen zijn.

[Verwijderd]

Tuurlijk vertelt Intel dit erg graag. Eigen belang voorop.
Maar je zult het op zijn minst vreemd moeten vinden dat Android hier en daar toch de nodige hikjes heeft. CPU en GPU power genoeg.
Ik zelf kijk liever vooruit in de hoop dat dit soort opmerkingen Google triggert want intel hijgt ze weliswaar nog niet in de nek maar wakker blijven is in deze branch geen overbodige luxe.
Android blijft voor mij voorlopig het beste OS, al is het alleen maar vanwege de vrijheid die het biedt. Het kan alleen nog maar beter worden.

[Dreamvoid]

hoop dat dit soort opmerkingen Google triggert want intel hijgt ze weliswaar nog niet in de nek

Uh, Intel werkt intensief samen met Google aan de x86 versie van Android, van nek-hijgen is geen sprake (of die samenwerking is wel heel innig ).

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[Verwijderd]

zei ik wat anders dan???

[alexbl69]

Precies de reden dat ik een paar jaar geleden alle HP producten heb afgezworen. Een simpele printerdriver paste op een gegeven moment niet eens meer op een CD. Ja, de driver natuurlijk wel, maar de meegeleverde crapware niet.

Zijn ze daar nu nog niet van afgestapt dan?

[dj.verhulst]

HP bied tegenwoordig voor veel printers/multifunction ook basis drivers aan
waar alleen basis drivers inzitten, de andere fabrikanten van dergelijke apparatuur ide proppen ook van alles bij , en bieden vaak ook geen basis driver aan.

[Verwijderd]

HP heeft altijd al losse drivers (zonder demo's of ingeperkte versies van tekenprogramma's en andere zooi) gehad, je moest wel even de moeite doen om die op hun site te downloaden (al stonden ze meestal ook wel ergens in een submapje op de CD).

[awenmaek]

ls er problemen zijn met Multi-thread, dan ligt het vaak omdat heel wat programma's voorzien zijn om in Single thread te draaien. In tegenstelling tot de PC wereld, waar we JAAAAAAAREN om gedaan hebben, van toen de eerste dual thread cpu, naar dual core cpu's, naar quad cores. In de ARM CPU wereld, is dit echt op verdekken korte tijd gegaan, dat we van Single Core, naar Quad Core gesprongen zijn

Als je voor Android programmeert (Android SDK in java) zal je merken dat een hele boel objecten zelf een thread starten.
Zelf threads starten is ook "poepsimpel" (Google raadt ook af om zaken af te handelen in de GUI thread).

Zelfs een slechtgeprogrammeerde Android app heeft zowat altijd meer dan 1 thread.

[Dreamvoid]

Is het nu toevallig, dat Intel commentaar heeft, hoe slecht Android het doet in multi-thread scenario's wanneer hun oplossing "single" thread is.

Intel heeft niet 1 single threaded chip - Medfield heeft hyperthreading dus is sowieso dualthreaded, en met hun volgende SoC Oak Trail eind dit jaar zitten ze op 4 (2 cores, 4 threads), net zoveel als al Tegra3 en Exynos 4412, en 2 meer dan grote concurrent Qualcomm met hun S4.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[Sinester]

Het gevolg is dat als je voor één platform specifiek optimaliseert, dat natuurlijk de boel beter zal draaien.

Dat doen fabrikanten toch ook voor hun eigen mobieltjes? vandaar dat Sony smartphones vaak bijna even snel zijn als hun concurrent met mindere hardware

[alexbl69]

Bij communicatieprotocollen hebben we en-masse de overstap naar serieel gemaakt, omdat o.a. timings- en ontwerpproblemen ervoor zorgden dat parallel, hoewel in theorie sneller, in de praktijk te veel problemen kende.

Is dat bij multi-core CPU's niet nog veel sterker het geval? Je moet zo veel rekening houden met de werking van multi-core, dat het effect in de praktijk wellicht niet al te groot is.

Is het niet veel verstandiger dat de CPU ontwerpers zich richten op zo snel mogelijke single-core CPU's (serieel)? Dat maakt het voor de programmeurs een stuk eenvoudiger.

[bantoo]

Nee dat is het niet, het maakt alleen luiheid makkelijker, ik raad je aan om de geschiedenis achter het hele Core verhaal nog even te lezen en wat de problemen waren met singlecores, ze schalen niet. Dat software niet schaalt is geen technische limitatie maar gebrek aan fatsoenlijke programmeurs en tijd.

[alexbl69]

Dat snap ik wel, maar de afgelopen decennia hebben uitgewezen dat programmeurs altijd lui zijn cq tijdnood hebben, en dat zal niet snel veranderen.

Mijn stelling is dus dat het waarschijnlijk in de praktijk effectiever is om de hardware dusdanig te construeren dat we zo weinig mogelijk last hebben van programmeurs in tijdnood, in plaats van dat we een gedragsverandering bij die bedrijfstak proberen te krijgen.

Let wel: ben het qua programmeurs helemaal met je eens. Platformen die er langen zijn (spelconsoles) worden in de loop der jaren steeds beter benut. Kan me uit mijn jeugd de C64 nog herinneren. Daar werden op het eind games voor uitgegeven die je nooit voor mogelijk had gehouden.

[Dreamvoid]

Daar loop je tegen thermische beperkingen aan, aangezien verbruik ongeveer kwadratisch schaalt met de kloksnelheid, maar lineair met core count, kan je op een gegeven moment beter meer cores gaan plaatsen dan de klok opschroeven van 1 core, ondanks het efficiency verlies van multicore vs single core.

Maar idd, parallelisatie is makkelijk gezegd, moeilijk gedaan.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[Sir Isaac]

Die vergelijking gaat niet op. Bij parallelle communicatie heb je alle bits die je verstuurd tegelijk nodig en moet alles dus synchroon lopen. CPU-cores werken vrij onafhankelijk van elkaar. Er lopen verschillende processen of in het ergste geval zijn ze aan verschillende delen van dezelfde data set aan het rekenen. De onderlinge timing doet er dan niet toe.
Overgens is PciE wel een parallelle bus.

[bwerg]

Ja, natuurlijk heeft een multicore-systeem extra overhead. Zowel bij de CPU die dit moet ondersteunen, als het OS dat de threads af moet handelen. Maar de overhead die je krijgt doordat de programmeur multicore moet ondersteunen is vaak vrij klein, als je gewoon de 'normale' scheidingen maakt, zoals een aparte thread voor GUI etc. Dat heb je in Java zo gefixt.

En ja, voor erg trage, laaggeklokte CPU's is het inderdaad slimmer om niet meerdere cores te gebruiken, maar voor één snelle core te gaan. Maar het lijkt me duidelijk dat dat voor de huidige desktop-CPU's gewoon onmogelijk is. Een 3,5GHz quadcore zou je moeten vervangen door een 14GHz single core om evenveel instructies te kunnen afwerken, of laat het 10GHz zijn als je minder overhead hebt. We zitten al lang tegen de limiet aan bij single-threaded systemen, en dat is bij mobiele hardware ook al bijna het geval. Je hebt wel gelijk dat er te snel aan zoveel mogelijk cores wordt gewerkt, wat soms overdreven is (zie de quadcore in de one X, die volgens reviews en benchmarks niet beter is dan de dualcore in de one S). Maar in de toekomst zullen we er toch naartoe moeten, dus dat het misschien een jaartje te vroeg gebeurt lijkt mij niet verkeerd.

[Reactie gewijzigd door bwerg op 27 juli 2024 20:18]

[TomONeill]

Sportief van Intel om dit soort dingen uit te zoeken. @alle reacties die gaan over "mijne is beter dan intel", daar gaat het bericht totaal niet over.
Nu hopen dat fabrikanten of Google hier iets mee gaan doen.

[SunnieNL]

Kan me vergissen.. maar Intel is zelf ook fabrikant.
Van anderen hier hoor ik altijd dat Android zo open is en iedereen er aan kan werken, dan zou ik zeggen.... Intel maak er wat van. Doe wat voor de communitie en los het probleem zelf op als je denkt te weten hoe het wel moet. Draag dat voor en mogelijk wordt het opgenomen in het geheel...

[Dreamvoid]

Dat doen ze al, Intel werkt met Google actief samen aan de x86 versie van Android. De ARM versie optimaliseren, dat moeten de ARM fabrikanten zelf regelen, maar Intel hoopt natuurlijk dat de verbeteringen die de ARM fabrikanten brengen, ook interessant zijn voor de x86 build.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[knirfie244]

Je kan het ook zien als: Ze hebben een probleem geconstateerd en hopen dat het op deze manier opgelost word in Android, op tijd voor wanneer ze eind van het jaar en begin volgend jaar met respectievelijk hun dualcore tablet en dualcore smartphone processors komen.

[Reactie gewijzigd door knirfie244 op 27 juli 2024 20:18]

[Verwijderd]

Sportief? Volgens mij is het niets minder dan een slimme manier om te zeggen: android heeft niets aan dure quad-cores, koop Intel single-cores!
Niets sportiefs aan, meer strategisch

[Dreamvoid]

Met Oak Trail gaat Intel ook naar dual core SoC's (met 4 threads ook nog) dus dan loop je tegen dezelfde problemen aan.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[Verwijderd]

Nee want ze hebben zelf al Android geoptimaliseerd voor hun processors.. Kwestie van die versie naar de fabrikanten sturen met Intel processors en Intel heeft een behoorlijke voorsprong op de andere processors.

[watercoolertje]

Intel kan dat wel roepen, maar waarom gaat mijn quadcore dan vierkant voorbij elke score die die Intel chip sneer weten te zetten Zelfs mijn dualcore deed dat al....

Nu moeten we niet vergeten dat hun chips per Mhz veel sneller zijn dat wel (op gelijke snelheid bijna vergelijkbaar met 2x zo veel cores op ARM Cortex A9).

edit: niet dat ik niet geloof dat het niet beter kan, alles kan beter, want niks is perfect! Maar om dat nou van Intel te moeten horen die toevallig alleen maar single cores aanbieden...

[Reactie gewijzigd door watercoolertje op 27 juli 2024 20:18]

[QQ2]

Wat intel volgens mij aangeeft is dat de scheduler in Android niet heel efficient is. Met andere woorden als je dezelfde rekenkracht in 1 core had gehad zou hij, volgens intel, nog veel sneller geweest zijn.

Daarnaast noem je 'score' dus ik vermoed dat je een benchmark gebruikt. Het is natuurlijk goed mogelijk dat die wel alle cores aanspreekt maar dat dit bij regulier gebruik niet of niet efficient gebeurt.

Natuurlijk zal intel dit nieuws niet zonder doel van eigen belang de wereld in sturen maar dat wil niet zeggen dat hun argument nergens over gaat

[watercoolertje]

Natuurlijk zal intel dit nieuws niet zonder doel van eigen belang de wereld in sturen maar dat wil niet zeggen dat hun argument nergens over gaat

Dat is in mijn edit dan ook benadrukt, dat er wel een kern van waarheid in zal zitten, maar dat het vooral is aangedikt...

Ik had het inderdaad voornamelijk over benchmarks, maar de reviews geven eigenlijk hetzelfde aan, gewoon een mid end toestel en dus niet te vergelijken met de Quadcores...

En de ene benchmark is de andere niet, er zijn er genoeg die wel degelijk een redelijk beeld kunnen geven van de real life prestaties. Velleamo (browser snelheid, kwa scrollen/netwerk/DOM opbouwen) bijoorbeeld, antutu zit er ook nooit ver naast (die meet bijv de snelheid van de schijfruimte en het ram, en GPU).

edit:Er is zeker nog ruimte voor verbetering, browsermark (benchmark) haalt bijna 200.000 puntjes, en dat is met 4 cores op 1.7Ghz, en als ik dan continu kijk hoe zwaar de CPU belast is is dat maar met 40 tot 50%. Ik denk dus dat er maar 2 cores geburikt worden, en dat de score mogelijk nog (bijna) verdubbeld kan worden als dat niet meer zo is!

[Reactie gewijzigd door watercoolertje op 27 juli 2024 20:18]

[bwerg]

En de ene benchmark is de andere niet, er zijn er genoeg die wel degelijk een redelijk beeld kunnen geven van de real life prestaties.

En toch vertrouw ik benchmarks niet, hierin. Die zijn vaak gevoeliger voor heel snelle hardware dan voor efficiënte scheduling. Een niet-responsief toestel kan nog steeds hoge gemiddelde FPS halen of een hoge GPU-score. Natuurlijk zijn de real-life prestaties prima, maar android-toestellen hebben vaak de snelste mobiele hardware aan boord dus dat zegt niet veel over scheduling.

[Dreamvoid]

Sommige benchmarks geven alleen de rauwe hardware power onder ideale omstandigheden aan (SpecINT enzo) en zeggen weinig over real life performance, andere benchmark (SunSpider etc) zijn juist alleen applicatie performance en geven aan wat de complete combo hardware+OS scheduler+software stack performt, waardoor je moeilijk kan zeggen of verschillen nou uit de hardware komen, het OS of de applicatie. Allebei zijn interessant, maar voor verschillende redenen.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[knirfie244]

Ik weet niet welke benchmarks jij dan bekeken hebt, maar de intel Atom kan gewoon zeer goed met met de Tegra 3, en wints zelfs in enkele benchmarks...


Van alle SoC makers kan Intel deze uitspraak juist het beste doen, ze hebben waarschijnlijk de meeste ervaring en kennis van de Android code.

[MeNTaL_TO]

Ook in performance/watt?

[Dreamvoid]

Juist, die Medfields zijn een stukje zuiniger. Maar de kracht van Medfield is vooral single-threaded performance, het is overall geen directe concurrent voor een high-end chip als Tegra 3 of Snapdragon S4. Medfield is een goedkope mid-range SoC die concurreert met de dual core OMAP4/Exynos 4-serie/Tegra 2/etc. De echte concurrent voor Tegra 3 is Oak Trail (2 cores, 4 threads).

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 20:18]

[Ge Someone]

Vraagt Intel eigenlijk niet om optimalisatie vooral voor Intel multicores?

[FireDrunk]

Als je alle Threads laat lopen én je start een nieuwe applicatie die even flink gaat rommelen, slurp je toch meteen je batterij leeg? Misschien stopt Google wel expres al die threads.

M.a.w: Wie weet wat de achterliggende gedachte is...

[bwerg]

Lijkt me sterk. Dan heb je meerdere cores, maar als je ze allemaal gebruikt wordt je telefoon te onzuinig en daarom gaat hij zorgen dat er alsnog minder cores gebruikt worden? Wat doet die vierde core dan eigenlijk, als hij niet bedoeld is voor belasting? Overigens betwijfel ik of dat inderdaad zuiniger is voor de batterijen, want je doet het werk gewoon trager dus de CPU zal ook langer belast worden voordat een taak klaar is. Wat wel een logische verklaring zou kunnen zijn, is dat een quadcore terugklokt als hij volledig belast wordt (of in turbo-mode gaat zodra minder cores belast worden, het is maar hoe je het ziet), maar ik neem aan dat intel niet zo stom is om dat over het hoofd te zien.

Als je trouwens alle cores volledig belast, en je start nog een thread, dan verandert er voor de CPU helemaal niets: er worden nog steeds vier cores benut. Alleen zal het OS soms even andere threads de beurt moeten geven maar dit zorgt er niet voor dat het verbruik omhoog gaat. Inzakkende prestaties bij multithreading is dus gewoon ongewenst.

[Reactie gewijzigd door bwerg op 27 juli 2024 20:18]

[Verwijderd]

De truuk is dat 2 cores op halve kracht grofweg de helft verbruikt van 1 core op volle kracht. Het verbruik van een chip neemt namelijk kwadratisch toe met de klokfrequentie.

[pizzaislekker]

Kleine aanvulling en verduidelijking op je bewering: Het verbruik van een chip neemt lineair toe met de klokfrequentie, maar kwadratisch met het verhogen van het voltage. Voor het verhogen van de klokfreqentie is vaak wel een verhoging van het voltage noodzakelijk.

[BeosBeing]

Misschien stopt Google wel expres al die threads.

Dat was wel de bedoeling toen alle toestellen nog singlecore waren.
Ook met een dualcore is het prima om één core te gebruiken voor OS en de ander voor de App. Met Tegra3 kan ik me voorstellen dat je het iets anders wilt regelen en volgens mij heeft Google dat inderdaad ook gedaan.

Vanuit welke basis dat Intel is gaan testen weet ik niet maar het porten kost ook tijd en ik kan me voorstellen dat de port is gedaan op basis van een toen beschikbare Android-versie die inderdaad nog niet op multicores was voorzien. Stel dat men nu 2.3 of 3.x heeft geport naar x86, dan is dat op zich een prima prestatie maar dan heeft de uitspraak alleen betrekking op die (en oudere) versies van Android terwijl dit bij 4.0 misschien totaal niet meer speelt.

In dat geval klopt de uitspraak an sich wel maar de daarmee gegeven boodschap niet want die zou dan eigenlijk moeten zijn dat Intel nog achter loopt met het porten en dat daarom Android nog niet optimaal loopt met hun Medfield cpu..

[ArgantosNL]

zo slecht doen andriod telefoons op een multi-core toch niet, het is niet een verdubling van de prestaties maar dat heb je zelfden. Het gaat hier ook nog over een x86 port waar de resultaten tegen vallen? Ik zet mijn vraagtekens er bij of het nou echt zo slecht is of dat het niet bewust is gedaan voor het energie gebruik.

[Sir Isaac]

Wel opvallend. De linux kernel heeft meerdere schedulers om uit te kiezen bij compilatie, en draait prima op systemen met 4 of nog veel meer cores. Wat is dan de oorzaak van het niet optimaal schalen van andoid?

[Dreamvoid]

Dat de meeste Android applicaties niet rechtstreeks low-level met de kernel babbelen, maar in de Dalvik VM draaien. Het gaat hier zo te zien vooral om de efficiency van de combinatie Dalvik + Linux.

[H!GHGuY]

De linux kernel heeft slechts 1 scheduler.
Er is ooit een voorstel gedaan om pluggable schedulers te hebben, maar dit werd hard afgeschoten.

De Linux kernel heeft wel meerdere I/O schedulers, maar dit is een compleet ander beest...

[Verwijderd]

edit niet goed gelezen