Gerucht: LG test octacore-processor

Volgens geruchten is LG van plan om binnenkort een processor te introduceren die beschikt over acht cores. Daarbij zou mogelijk de recent aangekondigde Mali-T760-gpu worden ingebouwd. Er verschenen eerder al geruchten over een LG-soc.

Volgens de Koreaanse nieuwssite Digital Times is LG al bezig om zijn octacore-soc te testen. De site meldt dat er vier Cortex A15-cores zijn ingebouwd met een maximale kloksnelheid van 2,0GHz, terwijl er ook vier zuinigere Cortex A7-cores aanwezig zijn die maximaal op 1,4GHz draaien. De soc zou op 28nm worden gebakken en gefabriceerd worden door TSMC. Volgens Digital Times is het mogelijk dat LG ervoor kiest om de recente Mali-T760-gpu in te bouwen, al wordt ook een variant uit de T600-serie als mogelijkheid genoemd. Het is onduidelijk wanneer LG de chip officieel wil gaan aankondigen.

Naar verluidt moet er ook een quadcore-versie van de LG-soc uitkomen. Deze zou niet beschikken over de Mali-T760-gpu, maar over de minder krachtige Mali-T604. Verder zijn alle vier de cores van het Cortex A15-type en ligt de kloksnelheid op maximaal 2,2GHz. LG zou van plan zijn om de quadcore-variant in smart tv's te gebruiken, terwijl de octacore juist bedoeld is voor gebruik in mobiele apparaten zoals smartphones en tablets.

Het is niet de eerste keer dat er geruchten verschijnen over een eigen processor van LG. Begin dit jaar gingen er al geruchten, terwijl recentelijk bleek dat de Koreaanse fabrikant zelf soc's op de markt wil brengen onder de codenaam Orion. Er werd verwacht dat de recent uitgebrachte LG G2 van een eigen soc zou worden voorzien, maar de fabrikant koos toch voor de Snapdragon 800 van Qualcomm.

Reacties (32)

[Verwijderd]

Ik weet niet heel veel af van mobiele CPU's maar... als die octacores uitkomen op consumenten mobieltjes word het dan niet ontzettend lastig om het software matig te optimalizeren om goed gebruik te kunnen nemen van de cores?

[epic_gram]

Rekenkracht is de laatste jaren echt een tweede prioriteit geworden. Wat sinds de opkomst van mobiele apparaten zoals laptops, smartphones en tablets veel belangrijker is, is verbruik.

Aangezien stroomverbruik (en dus warmteproductie) exponentieel toeneemt wanneer je de klokfrequentie verhoogt, wil je een zo laag mogelijke frequentie. Dit betekend dat 8 cores op 10% zuiniger zijn dan 1 core op 80%. SOC's, maar ook CPU's, klokken zichzelf terug wanneer ze niet zoveel rekenkracht nodig hebben. Dat is dus de rede dat er nu octacores in telefoons zitten.

Juist daarom is het ook belangrijk dat SOC's heel snel zijn. Een hype in CPU-land is het zogenaamde rush-to-idle. Processen worden zo snel mogelijk door een SOC afgehandeld, dus even volle kracht, om vervolgens weer idle te kunnen draaien. Dat idle draaien gebeurd in deze soc met 4 langzamere, en ook zuinigere cores. Ik verwacht dat dit in de praktijk niet veel zuiniger is, maar vanuit marketingsperspectief is het vast handig om een octocore te maken met 4 verouderde en langzamere CPU's. Daarbij is het ook goedkoper.

Een moderne smartphone is ontzettend snel, en een gemiddelde gebruiker zal nooit 100% van deze SOC's vragen.

Tot slot, wat betreft schaing over meerdere cores... Google werkt aan hun java-engine, en er zijn al ontzettend grote stappen gezet in het schalen van apps naar meerdere cores. Het belangrijkste werk hierin blijft echter nogsteeds voor de app-ontwikkelaar, maar hiervoor staan er voor android studio (een experimentele ontwikkelomgeving voor android) al verschillende nieuwe opties in de rij.

[Reactie gewijzigd door epic_gram op 25 juli 2024 00:20]

[Wulfklaue]

Ik verwacht dat dit in de praktijk niet veel zuiniger is, maar vanuit marketingsperspectief is het vast handig om een octocore te maken met 4 verouderde en langzamere CPU's. Daarbij is het ook goedkoper.

Foutje? Refereer je naar de A7 die gebruikt word als "verouderde en langzamere CPU's"...

De A7 is een vrij recente ARM design. Geïntroduceerd rondom hetzelfde moment als de A15 design.

Je zou idd verwachten dat de A7, ouder is, aangezien we intussen al voorbij de A8/A9 zijn, en volop gebruik wensen te maken van de A15. Technisch gezien is de A7, een mix van A8/A9 en A15 technologie, waarbij zoveel mogelijk rekenkracht gegeven word, op een zo zuinig mogelijk ontwerp.

Voor de meeste taken is een A7, meer dan genoeg. Maar zodra je zware taken draait, ja, dan is een A15 or Krait altijd leuk.

Vergeet wel niet, dat 8 cores op 10%, is niet zuiniger dan 1 core op 80% ... Er is een verbetering als je idd data over meerdere cores kan splitsen, en als dit lage voltage cores zoals de A7 zijn. Maar als we spreken over 1 A7 core 80%, en 8 A7 cores op 10%, dan mag je zeker zijn dat je meer stroom zal zuipen dan alles op die ene core te doen!

Er is een zekere economische efficiëntie dat afhangt van de core design ( A7/A15), de hoeveelheid cpu kracht dat nodig is, en welke oplossing de meest geschikte is. Hou rekening ook, threads afsplitsen is daarom niet gratis he! Als je een berekening kan uitvoeren op 1 core, of je moet die zelfde berekening afsplitsen over x threads, dan heb je automatische overhead ook.

Het grote probleem ook met multi thread is, dan als programma's niet ontworpen zijn ervoor, dat je compiler maar beperkt kan afsplitsen... Ik denk dat er niet veel mensen zijn, dat zoveel tijd in hun applicaties steken, dat deze kunnen tot 8 thread's gaan. Zeker als je ziet dat de meeste taken perfect op een single core kunnen draaien. Games, grafische programma's, encoders, en zo spullen, zijn gediend ermee. En zelf dan nog, hoeveel kan je echt afsplitsen!

Multi core oplossingen zijn nu al hoeveel jaar op de PC markt? Dual thread applicaties zijn nog altijd meer uitzondering dan standaard. Laat staan 4 of meer core versies.

[zerokill]

Aangezien stroomverbruik (en dus warmteproductie) exponentieel toeneemt wanneer je de klokfrequentie verhoogt, wil je een zo laag mogelijke frequentie. Dit betekend dat 8 cores op 10% zuiniger zijn dan 1 core op 80%. SOC's, maar ook CPU's, klokken zichzelf terug wanneer ze niet zoveel rekenkracht nodig hebben. Dat is dus de rede dat er nu octacores in telefoons zitten.

Klein detailtje in je betoog: frequentie is evenredig met opgenomen vermogen, niet exponentieel. Specifiek de volgende formule:
P = C * V^2 * f

(Zie het boek Digital Integrated Circuits voor als je geïnteresseerd bent)

[Reactie gewijzigd door zerokill op 25 juli 2024 00:20]

[joco]

java is by default al zeer makkelijk te gebruiken naar meerdere cores.

Het zit hem puur in hoe je de app maakt. Het is dus puur iets voor de ontwikkelaars om zo veel mogelijk in de background te doen.

Nu is het al zo dat alles wat je met I/O doet op de main thread in android, klapt er nu meteen al uit met een melding "dit mag niet, moet in background" dus alles met i/o wordt nu gelukkig al geforceerd naar achtergrond taken. Alleen jammer is dat die I/O taken nu net I/O bound zijn.. dus nagenoeg niet veel doen met de cpu.

Het is gewoon heel erg lastig om een single user applicatie echt multi threaded te maken. Gebruik makend van 2 cores dat is nog wel te doen, zeg maar alle acties, alle kliks van een gebruiker gaan direct naar een achter grond thread zo dat de ui meteen weer responsive is. Dat is redelijk eenvoudig te doen, alleen moet je er dan wel rekening mee houden dat een gebruiker al weer op de volgende button kan drukken terwijl jij nog bezig bent met de vorige klik...

De meeste apps doen nu eenmaal niet zo veel, het is meer van toon het volgende scherm, laad data in (buiten wereld of van de sql db op de telefoon) en toon dat.
Het is veel meer dat het systeem dus de UI zo snel mogelijk moet tonen..

[TIGER79]

Het is gewoon heel erg lastig om een single user applicatie echt multi threaded te maken.

ik verwacht niet dat een multi-user applicatie simpeler is om te maken, en nee een "echte" (bestaan er ook geen echte?) multi threaded applicatie is niet moeilijk te maken. Ja het is complex maar de meeste dingen zijn onderhand thread-safe en je hebt je mooie tools zoals de Thread Classe en Runnable interface van Java en vanuit Android natuurlijk Asynctasks en Handlers... Genoeg mogelijkheden dus, en dan hebben we het nog niet gehad over Services...

Gebruik makend van 2 cores dat is nog wel te doen

ik denk dus dat jij hier multi-threading bedoelt, zover ik weet stuur je als ontwikkelaar echt niet specifiek een cpu aan... En jah single core cpu's ondersteunen ook multi-threading hoor....

laad data in (buiten wereld of van de sql db op de telefoon) en toon dat.
Het is veel meer dat het systeem dus de UI zo snel mogelijk moet tonen..

Dit zijn natuurlijk geen problemen inherent aan telefoontjes (en/of Android), daarvoor zijn er al jaren patterns voor bedacht zoals lazy loading (wat erg goed werkt binnnen Android, bijv in een ListView)....

[Reactie gewijzigd door TIGER79 op 25 juli 2024 00:20]

[joco]

ik verwacht niet dat een multi-user applicatie simpeler is om te maken, en nee een "echte" (bestaan er ook geen echte?) multi threaded applicatie is niet moeilijk te maken. Ja het is complex maar de meeste dingen zijn onderhand thread-safe en je hebt je mooie tools zoals de Thread Classe en Runnable interface van Java en vanuit Android natuurlijk Asynctasks en Handlers... Genoeg mogelijkheden dus, en dan hebben we het nog niet gehad over Services...

Mulit user applicaties fully threaded maken is enorm simpel
Dat is het vaak al default, Multi user apps zijn vaak applicaties die runnen op een server. Dat soort apps. Elke user (elke request) heeft daar altijd al zijn eigen thread. (dus een "core").
Die zijn schalen inherent al goed over multi core systemen heen.

Als ik hier op de knop "plaats reactie" druk, en dat doen er op deze website nog 10 anderen exact op dezelfde tijd. Dan gaat dat dus mooi over 10 cores heen (als de server er zo veel heeft en dat lijkt me wel)

ik denk dus dat jij hier multi-threading bedoelt, zover ik weet stuur je als ontwikkelaar echt niet specifiek een cpu aan... En jah single core cpu's ondersteunen ook multi-threading hoor....

Daarom zei ik ook CORES! en niet dat ik pure over multi threading bedoel.
Multi threading met I/O heeft dus wel heel veel zin, want dan wacht tenminste de hoofd thread daar niet op.
Ik bedoel dus dat meerdere threads (die dus echt over meerdere cores gaan) gebruiken in een single user applicatie is gewoon lang niet altijd simpel. en ja jouw voorbeelden bracht ik al aan, geen idee waarom je die ook weer naar voren brengt.

Dit zijn natuurlijk geen problemen inherent aan telefoontjes (en/of Android), daarvoor zijn er al jaren patterns voor bedacht zoals lazy loading (wat erg goed werkt binnnen Android, bijv in een ListView)....

Dit had ik al aangegeven, dat gebruik maken van 2 cores nog wel te doen is door alle laad en klik acties van gebruikers dus in een thread /lazy te doen. Dat moet je sowieso doen, de UI/Main thread moet je zo min mogelijk belasten met code.
Maar dit zijn laad acties dus vaak I/O daar gebruik je niet echt "cores" mee, Je zorgt dan vaak de het wachten op de buitenwereld niet gebeurd in de UI/Main thread. Maar je cores gaan daar niet plotseling heel erg van zweten.

Daar komt bij dat heel veel dingen gewoon sequentieel zijn, doe dit dan dat, dan dit en dan weer dat. Dat is heel lastig om uit elkaar te trekken.
Maar voor een gewoon redelijk standaard android app, zal het vrij lastig zijn om echt gebruik te maken van 4 of meer threads die dan ook echt de 4 cores even vol echt nodig zijn. Maar goed dit is ook allemaal niet echt nodig want er zijn natuurlijk ook processen op de achtergrond die mee draaien (services ja) en soms ook wat willen doen naast het OS zelf.
Maar we hebben het hier over een single user app die op android draait. Dan is het gewoon nagenoeg niet mogelijk om vol gebruik te maken van 4 of meer cores.

[TIGER79]

najah ik volg je niet meer, waar ik op doel is dat een app (of eigenlijk een app-ontwikkelaar) zich totaal niet druk hoeft te maken over hoeveel cores er aangestuurd worden, dat doet namelijk het OS zelf... Je hebt alleen controle over je eigen gespawnde threads die nog bovenop de standaard ui-thread komt... Al zou je je willen druk maken daarover kun je als ontwikkelaar niet specifieke cpu cores aanspreken...
Ik ontwikkel sinds 1.5 voor Android, toen gebruikte ik al multithreeading voor lazy loading van enorm lange lijsten met plaatjes, en dat op een 724 mhz single core toestel, en dat hield echt niet in dat dan opeens de klik en laad acties waar jij het over hebt niet meer soepel verliepen... Dan komt het echt wel meer neer op dat je weet wat je aan het doen bent dan de onderliggende processor-architectuur(single/multi), want zo lees ik namelijk jou tekst

Dit had ik al aangegeven, dat gebruik maken van 2 cores nog wel te doen is door alle laad en klik acties van gebruikers dus in een thread /lazy te doen. Dat moet je sowieso doen, de UI/Main thread moet je zo min mogelijk belasten met code.

Je wekt hiermee namelijk de impressie dat je twee cores nodig hebt om uberhaupt lazy loading te kunnen doen in een andere Thread, wat niet klopt....
En sorry maar multi-user apps zijn iets anders dan client-server apps, wat jij bedoelt denk ik... En dat in de server-kant altijd een aparte thread voor iets wordt opgestart : dat ligt er echt wel aan hoe deze geprogrammeerd is, dat is namelijk niet altijd het geval, net als bij de UI-Thread van Android kan je bij zeer korte operaties gewoon gebruik maken van de main thread....
Dan nog indien men gebruik maakt van multi-threading (waar dan ook, server of andere platform) hoeft dat niet te betekenen dat er sprake hoeft te zijn van meerdere cores... Jou voorbeeld van 10 aanvragen 10 cores slaat volgens mij ook daadwerkelijk nergens op... Kan net zo goed zijn dat er 10 Threads aangemaakt zijn en dat die op 4 cores worden uitgevoerd, het lijkt mij dat jij steeds impliceert dat 1 Thread op 1 Core moet draaien, wat simpelweg niet klopt...

[Reactie gewijzigd door TIGER79 op 25 juli 2024 00:20]

[joco]

Ik zeg helemaal niet dat de app ontwikkelaar moet kijken naar de hoeveelheid cores
Het enige wat ik constant aangeef is dat het voor een app ontwikkelaar heel moeilijk is om 4 cores echt iets te laten doen in een doorsnee app. Want je kunt gewoon niet zo veel threads te gelijk aan maken (die het os dus verdeeld over de cores) dat ze echt wat aan het doen zijn,
Dus met andere woorden voor pure apps heb je echt totaal niks aan die veel cores, want app ontwikkelaars kunnen er toch niet echt gebruik van maken

Lazy loading kun je wel redelijk doen als je maar 1 core hebt. Maar dit komt weer door dat je I/O hebt wat dus niks doet met de cpu. Dus andere threads die op die zelfde core lopen kunnen gewoon bezig gaan.
Maar stel je nu eens voor dat je echt maar 1 core hebt in je cpu, en dat je lazy loading niet alleen I/O doet maar echt seconden lang ook 100% van die core dus pakt (en dus van de cpu) dan zal ook de main/ui thread echt gaan bokken, dat merk je meteen. Want die komt er gewoon bijna niet meer door.

Vroeger was dat altijd een ramp op mijn ontwikkel bak. Toen we nog geen dual core's hadden. Maakte je een programeer foutje zodat je app echt flink stond te loopen, Dan kwam je daar met je debugger bijna niet meer door heen omdat er geen core over was die weer dat kon afhandelen, de sprong naar dual core was daar in tegen gigantische verbetering. Maar de sprong naar quad heb ik eigenlijk totaal niet gemerkt, Behalve dat de core zelf ook flink sneller werd.

over die server: Als het echt te gelijk binnen komt (daar heb ik het dus echt over) dan gaat het os ze echt wel over alle cores die er zijn verdelen. Ze kunnen wat heen en weer springen (ligt een beetje aan de instelling en als je numa werkt of niet)
Maar als je in een cpu monitor kijkt zul je zien dat elke core spiked.

Maar natuurlijk als er 10 request binnen komen en er zijn maar 4 cores wordt dat natuurlijk gewoon verdeeld over die 4 cores (dus alle cores krigjen er minimaal 2 te verwerken)

Ik zeg nergens dat thread en cores 1 op 1 hoeven te zijn, Alleen als threads echt wat doen gaat het os ze op een vrije cpu core gooien zolang er cpu cores zijn.

[Damic]

Je hebt nu toch ook al 2 of 4 of zelfs 5 cores zodus dat word al ondersteund

[Verwijderd]

De vraag is hoe goed het ondersteund wordt. NB: ook in normale pc's, die veel zwaardere multitasking doen dan mobiele apparaten, valt het vaak nogal tegen hoe goed de cores benut worden.

[Verwijderd]

Dat is nog maar de vraag op Desktop en Laptop gebied is de meeste software er zeker niet klaar voor, of dat bij telefoons en de besturingsystemen anders zal zijn betwijfel ik ten zeerste.

Vroeger was alles precies andersom de software was geschreven en de hardware moest nog volgen.

[HerrPino]

Ik zou ook wel eens willen weten of er daadwerkelijk een groot verschil is tussen een 2 of 8 core processor op een mobieltje. 1 core voor de voorgrond thread en 1 gedeeld met de achtergrond threads lijkt me redelijk genoeg. Als je meer nodig hebt moet je je volgens mij op een telefoon serieus gaan afvragen of het OS niet onnodig vertragend werkt of dat je niet teveel wil ... immers het blijft een telefoon, het is geen desktop pc. Op Android bijvoorbeeld zijn grote gedeeltes (naar mijn weten) in Java geschreven. Dit is leuk en zo (weinig nuttig overigens aangezien de apps niet buiten Android werken) maar is onnodig vertragend, zeker op een systeem waar je zo lang als mogelijk met je batterij wilt doen.

[joco]

tja dus jij vind java al "traag". terwijl de "movement" naar steeds meer html + javascript is....
Dat is nog een slag anders, dat is zelfs pure scripting..

Java brengt wel een beetje meer dan over meerdere platformen heen. Ja dat heeft niet veel zin nee, maar het is wel een zeer bekende taal, met veel externe en open source libraries. Het brengt veel mee bv garbange collection.

Daarnaast vergeet je 1 ding, er zijn binnen android wel meerdere platformen,, je hebt ARM en je hebt Intel, Nu is het dus zo dat het mereneel van alle apps meteen draaien, het maakt dus niet uit. Dit is voor de markt wel erg gunstig Intel voelt de adem van ARM en ARM de adem van Intel, Dus zo moeten beide echt voorruit gaan.

En zo veel vertragend is het niet. het enige wat je hebt een is een compile slag van te voren en laten zie die nu net bezig zijn om te fixen, Dat de compile slag bij installatie gaat dus daarna is het gewoon een native app..

[knirfie244]

Zo een octacore is er al lang, deze zit bijvoorbeeld ook in de Galaxy S4 in sommige landen. Daarnaast maakt ook de Meizu MX3 gebruik van deze SoC. Software hoeft er niet zozeer voor geoptimaliseerd te worden. Het is vooral de kernel die er mee overweg moet kunnen gaan, en weten hoeveel van welke cores er geactiveerd moeten worden en welke threads er op een A7 en op een A15 moeten draaien.

[bstard]

Het doet wel erg denken aan de megapixels race van paar jaar terug.

[Dr_Luigi0]

Een octacore lijkt me persoonlijk een beetje overkill voor een smartphone, vooral omdat er maar weinig processen die zoveel rekenkracht nodig hebben. En apps zullen ook niet zo heel veel sneller draaien. Software die goed geoptimaliseerd is voor de hardware lijkt me beter.

[Cilph]

Het voordeel ligt ook niet zozeer bij het aantal cores per applicatie, meer dat je al je applicaties kan verdelen over de cores. User interface krijgt een core, alle IO krijgt een core, jij krijgt een core, iedereen krijgt een core!

[Bulkzooi]

Het nadeel is alleen dat het opstarten van apps maar op 1 core gebeurd. Single threaded performance is (nog altijd) veruit de belangrijkste spec.

Voor background tasks en multitasking zijn meerdere cores wel handig inderdaad. Verder is het belangrijk dat de browser (belangrijkste app) meerdere cores goed gebruikt en volgens mij doen ze dat.

[Reactie gewijzigd door Bulkzooi op 25 juli 2024 00:20]

[ariekanari]

LG zou van plan zijn om de quadcore-variant in smart tv's te gebruiken, terwijl de octacore juist bedoeld is voor gebruik in mobiele apparaten zoals smartphones en tablets.

Voor televisies met smarttv en/of ingebouwde mediaspeler is een snellere processor heel erg welkom. O, en vooral nuttige, bruikbareapps: die tientallen Koreaanse spelletjes op Samsung-tv's voegen niets toe.

[Hermanvh]

Ligt dat niet heel erg aan het OS, dat zou je volgens mij best moeten kunnen instellen?

[joco]

ik gebruik de browser bijna nooit..
(of het moet indirect zijn dus de webpane binnen een app, dat zou natuurlijk kunnen)

[suljo]

niet alleen een beetje overkill hoor, maar zolang de (niet tweakers) consumenten niet beginnen te snappen dat meer niet altijd beter is gaan de fabrikanten er steeds meer cores in blijven steken. de ironie van het verhaal is dat die zelfde consument na aankoop begint te klagen over een slechte batterijduur

overigens snap ik niet waarom lg dit nodig heeft als ze tenminste een echte multitasking hadden zoals sommige samsung apparaten(wanneer geroot,met stock custom rom en met de app multiwindow, zie xda) dat je meerdere zware apps naast elkaar kunt open doen. kan je dit gebruiken. inplaats van zich op cpu te concentreren kunnen ze zich beter concentreren op nieuwe soorten baterijen. zoals bijvoorbeeld de zwavelzuur batterij. of in het geval van samsung dat de batterij niet opeens te groot is voor de gsm.
http://www.sammobile.com/...-charge-holding-capacity/

[Verwijderd]

Dit is dus duidelijk een dual quad core processor. 4x Cortex A15 + 4x Cortex A7 naar referentie van ARM in de big.LITTLE configuratie geplaatst. Trouwens kan die quad core in Smart TV's van LG dan nog sneller datagraaien (nieuws: LG erkent versturen privacygevoelige data Smart TV en belooft firmware-fix)?

[Anton.net]

Ik weet dat vooruit gaan nodig is, maar wat is nu weer juist het nut van 8 cores in een smartphone?
-Slorp batterij op
-Is duurder
-Software is totaal niet aangepast aan 8 cores
-In werkelijkheid zul je er niet veel van merken

Schermen en processors zitten nu wel goed in smartphones, batterij en geheugen is een ander verhaal..

[kidde]

Denkt u ook dat een team voetballers als totaal minder energie verbruikt als ze 5 spelers hebben in plaats van 11?

Juist dat iedereen zijn / haar taak heeft zorgt ervoor dat het efficienter gaat. Daarom hebben nieuwere hybride auto's drie motoren (!) in plaats van een enkele: Het blijkt dat de auto met twee electromotoren (een grote en een kleinere) en een verbrandingsmotor zuiniger rijdt dan eentje met alleen een verbrandingsmotor.

Stel, een dualcore smartfoon met 2 Cortex A9 (of Krait?) CPU's van 500mW per stuk: Totaal max. opgenomen vermogen: 1 Watt. Die draait altijd minimaal op 500mW, ook bij Whatsappjes en Facebook ontvangen terwijl de foon in standby staat.

Stel, een octacore smartfoon met 4 Cortex A7 CPU's van 250mW per stuk en 4 Cortex A15 CPU's van 750mW: Totaal max. openomen vermogen 4Watt. Sluprt batterijen, zegt u.

Er draaien wat achtergrondprocessen op de ene 'langzame' CPU en WhatsApp / Facebook op de tweede langszame: Die gebruikt in dit voorbeeld dan maar 400mW per stuk, en kan dus langer mee (standby) op hetzelfde batterijtje als de dualcore.

De reden dat octacores een slechte naam hebben, is omdat de Linux-kernel er nog niet klaar voor was, maar met de ondersteuning van Heterogeneous MultiProcessing (Apple / Microsoft ondersteunen dit (nog) niet eens voor zover bekend) door Linaro is dit verleden tijd.

[computerjunky]

Tja die dingen worden wel steeds sneller maar zuiniger h maar.

En aangezien veel android apps niet kunnen load balancen is het een slecht idee om zoveel ongebruikete power in een device te stoppen.
Deze apps zullen met zoveel power in notime je accu leeg zuigen en dat is niet bevordelijk voor de accuduur die toch al niet al te best is.

Ach ja we gaan het zien.
Mijn volgende apparaat moet in iedergeval in games toch wel langer meegaan dan 5,5 a 6 uur anders hoef ik m echt niet
mijn huidige LG gaat krap 3 uur mee en dat is niet eens met alle ames sommige games die gewoon de cores op max forceren ondanks dat het 2d games zijn slurpen m in 1 uur 45 min leeg.

[Reactie gewijzigd door computerjunky op 25 juli 2024 00:20]

[hyperjumpers]

Wat voor LG mag dat dan wezen? Als je een spel speelt op een verouderde telefoon (waarvan de batterij vaak al veel te verduren heeft gekregen en dus minder word) gaat deze vaak snel leeg omdat de hardware het spel gewoon niet kan draaien..

[computerjunky]

LG 4x HD en dit licht aan de spellen niet aan de accu aangezien ik dit op al mijn 3 deviced heb.
indtalleer de doa game eens een 2d game die meer vreet dan de batman game omdat hij volgens cpu monitor constant op 100% aan het draaien is.
of dit andrid is wat niet kan loadbalancen of de game weet ik niet maar `10% is absurd voor wat de game voorsteld.
en zo zijn er nog tich games op de playstore te vinden.
Doe mij maar een dualcore 1 ghz met dual mali400 snel zat en veel zuiniger.

[[Remmes]]

En Apple houd het nog steeds bij een dual... Oftewel is dit dan echt nodig om Android goed en zuinig te laten draaien ?

[computerjunky]

Het is niet zuiniger en al helemaal niet nodig 2x 1ghz draait alles al soepel en de gpus vreten ook veel te veel en zijn ook veel te snel voor de games in de play store.

mijn tegra 3 telefoon heeft 2 cores uitgeschakeld en de overige 2 cores draaien op 650 mhz en alles is 100% soepel en snel zat.
de rest kan gewoon niet sneller door het OS of de apps of het geheugen in de telefoons wat gewoon niet snel is.
Dus al deze power in telefooons is onnodig en een verkoop praatje en geeft fabrikanten een vrijbrief om slechte roms te maken omdat het iet meer opvalt dat een rom traag is met zoveel power.
Behalve dan dat het je accu leeg vret omdat er meer berekend word maar dat lijkt niemand wat te intereseren.