Samsung kondigt 1GHz Cortex A9-dualcore aan

Samsung heeft aangekondigd dat het een cpu heeft ontwikkeld met een dualcore-Cortex A9 als basis. De processor heeft als codenaam Orion en draait op een kloksnelheid van 1GHz. Massaproductie begint in de eerste helft van 2011.

De Orion-processor is gebakken op Samsungs eigen 45nm-procedé en beschikt naast twee cores over 1MB L2-cache, wat volgens de fabrikant moet helpen bij multitasking. Daarnaast kan de Orion-cpu 1080p-video encoderen en decoderen. Verder is Samsungs nieuwe cpu in staat om beeld op twee schermen weer te geven, waarbij daarnaast nog via hdmi een extern scherm kan worden aangesloten.

Volgens Samsung heeft het de grafische prestaties van zijn processor fors verbeterd ten opzichte van de Hummingbird-cpu; de fabrikant claimt dat de gpu in de Orion vijf keer sneller is dan de PowerVR SGX540, die de Hummingbird aan boord heeft.

Samsung gebruikt zijn Hummingbird-processor onder andere voor de smartphone Galaxy S en de tablet Galaxy Tab. Deze cpu heeft een Cortex A8-core en draait op 1GHz. Het was al bekend dat Samsung aan een opvolger werkte; de Orion stond vermeld in een roadmap die onlangs opdook. Welke producten van de nieuwe dualcore-processor gebruik gaan maken is niet bekend.

Reacties (67)

Volgens Samsung heeft het de grafische prestaties van zijn processor fors verbeterd ten opzichte van de Hummingbird-cpu; de fabrikant claimt dat de gpu in de Orion vijf keer sneller is dan de PowerVR SGX530, die de Hummingbird aan boord heeft.

De Hummingbird heeft een SGX540 aanboord. De enige manier om de GPU nog sneller te maken is door over te gaan naar meerdere cores.

Wel interessant natuurlijk, maar is het echt nodig? Het is niet alsof er software is die er gebruik van maakt, en het verbruikt alleen maar meer energie. Samsung meet de snelheid in triangles/sec, en de Hummingbird doet al 80Mt/s (volgens Samsung). Met 5x dat zit je op hetzelfde niveau als een PS3 of xbox360...

[Reactie gewijzigd door knirfie244 op 7 september 2010 22:47]

Deze kloksnelheden zijn die nou te vergelijken met de kloksnelheden van INTEL?
Of zijn deze op een andere manier berekend?

Nee, (al is het spreken over een processor van Intel ook nietszeggend).
Deze processors kunnen (door het ontwerp) per Mhz minder calculaties uitvoeren dan desktop/laptop processors (dit is de zogenaamde IPC die hoger is)

http://en.wikipedia.org/wiki/Instructions_Per_Cycle

Edit:
Het zou echter zomaar wel kunnen zijn dat deze processors krachtiger zijn per opgenomen watt energie dan hun grote desktop broertjes.

[Reactie gewijzigd door procyon op 7 september 2010 17:29]

Ook deze vergelijking gaat scheef. Met IPC kun je alleen processoren vergelijken met dezelfde instructieset. De x86 heeft slechts 5 registers voor algemeen gebruik terwijl de ARM er 13 heeft. De ARM hoeft dus veel minder tussenresultaten in het werkgeheugen of op de stack te zetten en kan dus meer doen met minder instructies.

Als je goed wilt vergelijken dan zul je dus met benchmarks zoals drystone en whetstone aan moeten komen. Waarbij je dan ook nog eens dezelfde optimalisatie en C-library moet gebruiken.

Waarom hanteren ze dan deze eenheid? En niet zoals jij aangeeft bijv. de IPC/m of zo?

Waarom hanteren ze dan deze eenheid? En niet zoals jij aangeeft bijv. de IPC/m of zo?

Marktwaarde; de meeste consumenten zien dat een foon een processor heeft met meer MHz dan een andere en gaan voor die. Ik ben daar overigens ook toe geneigd ook al weet ik dat het aantal MHz's niet alles zegt...

Daarbij komt, er IS simpelweg geen eenduidige manier om de snelheid van een CPU aan te geven. We willen echter zo graag dat deze manier er wel is, dat we dus maar ongeveer doen alsof deze manier er is.

Apple heeft overigens een flink poosje reclame gemaakt tegen de Mhz hype. Dat was dan wel omdat het goed in hun straatje uitkwam (Apple gebruikte toen PPC en Intel CPUs clokte hoger), maar misschien heeft het grote publiek hier toch nog wat van onthouden.

waarom hanteert intel deze sneheids indicatie, dacht je dat een pentium 4 3ghz even snel was als een core i5 op 3ghz.

en hoe zou dat zijn met een amd phenomII - of een OC'd athlon xp.

je zult uiteindelijk zien dat geen enkele van de genoemde op gelijke klock ook gelijk presteerd. wel kan je zeggen dat een 1ghz A waarschijnlijk sneller is dan een 600mhz A

verder zal het afhangen van de gekozen ARM versie ... ofwel de generatie van de cpu...

omdat ze niet de zelfde instructies op de zelfde manier uitvoeren.
Bij instructie X is ARM sneller, bij instructie Y is x86 (intel/amd) sneller.
Je kan ze totaal niet vergelijken.

Klok-voor-klok is een Cortex A9 core vergelijkbaar-tot-marginaal-beter met een "Pineview" Atom op integer performance, maar fors langzamer floating point. Maar de truc is dat dit duals zijn, en 2x1GHz (makkelijk vergelijkbaar dus met een singlecore Atom N450 op 1.7 GHz) geeft alsnog een behoorlijk acceptabele performance, zeker als je er extra chips bijzet voor gpu/fpu/video decoding zoals nVidia doet met de Tegra-chips. De memory bandbreedte opschroeven helpt ook, dat is op het moment de beperkende factor in veel ARM SoC's. Een x86 systeem heeft meestal supersnel 64-bit DDR3 geheugen, terwijl de ARM smartphones/tablets het hooguit met 32 bit LPDDR1 mogen doen (6-8x langzamer).

Hmm uit de SpecINT nummertjes hier zit de Atom toch wat sneller in integer performance, de single core 1.5 GHz Moorestown Atom komt er 2x sneller uit dan een 2x1GHz Cortex A9. Maar goed, dat is de nieuwe Moorestown Atom, niet de huidige Pineview.

[Reactie gewijzigd door Dreamvoid op 7 september 2010 18:38]

Wie geloof die Intel-reclame nu?

SpecInt draait maar op 1 core, en waarom heeft men niet vergeleken met een A9 die op 1,3 mHz draait? Per mHz zijn ze dus net zo snel. Had de benchmark op meerdere kernen kunnen draaien, dan was de A9 fors sneller geweest.

De SunSpider benchmarks zijn waardeloos als niet wordt weergegeven welke browser / javascript-engine gebruikt is.

Laadtijden van websites zijn ook totaal waardeloos als niet wordt verteld welk OS / browser.

Bij de laatste tabellen wordt niet eens verteld met welke SoC vergeleken is, alleen DeviceA / B enz.

Leuke reclame, maar totaal waardeloos voor wie iets wil zeggen over verschillen.

Als een Cortex A9 "fors langzamer" is op floating point dan een Intel, zie ik hier graag benchmarks van, omdat ARM beweert dat dit een euvel uit de A8 is dat in de A9 verholpen zou moeten zijn.

Overigens is de A9 op bepaalde gebieden complexer dan de Atom, de A9 heeft out-of-order execution.

Heb je daar een linkje/benchmark van? Ik ben wel erg nieuwsgierig, het zou me niks verbazen dat door het lean-en-meane ontwerp van ARM deze wel eens een hogere IPC zou kunnen hebben dan een Atom.

"Lean and mean" (=low-complexity, simpele branch prediction, etc) betekent meestal juist slechte klok-voor-klok prestaties. Alle moderne trucs die de performance-per-kloktik omhoog krikken maken je cpu complexer en groter, en dus onzuiniger (per GHz, niet "per performance") vergeleken met een ontwerp dat dit allemaal niet heeft.

[Reactie gewijzigd door Dreamvoid op 7 september 2010 18:58]

Dus "lean and mean" betekent in principe wel meer prestatie per Watt?

Nee, anders zou iedereen nog met het supersimpele ontwerp uit 1980 werken, maar dan op hogere klok en op een kleiner procede gebakken. Er worden steeds nieuwe 'trucs' toegevoegd, die net iets meer in performance opleveren dan ze "per watt" kosten. Zo krijg je een "performance-per-watt" die steeds hoger wordt. Maar je moet ook blijven innoveren, want de trucs die werkten op een 16 MHz chipje werken doorgaans niet ideaal meer op 1 GHz (waar Intel bv achterkwam met de P4/Netburst). En omgekeerd werken trucs die op >2 GHz een briljant idee zijn, niet meer zo efficient als je terugklokt naar 500 MHz. Trucs die werken in cpu's met veel (duur/stroomvretend) L2 cache werken ook niet meer als je de cache uitzet. Idem met geheugenbandbreedte/snelheid, etc.

En daarom zijn goedkope chips op lage klok, met weinig/geen cache, etc vaak simpele ontwerpen (zoals ARM), en grote, snelle chips op hoge klok complexe x86 cores. Het wordt interessant op het snijvlak van de twee: de laatste jaren wordt ARM steeds complexer gemaakt (zowel de core zelf als door het toevoegen van allerlei extra chips: SoC) en hoger geklokt, terwijl Intel juist zijn best doet om x86 te steeds verder te versimpelen en zuiniger te krijgen bij een gelijk blijvende kloksnelheid. En aangezien de komende tijd verwacht wordt dat het segment waar de meeste cpu's worden verkocht niet meer de PC markt is, maar de netbook/tablet/smartphone markt, is dit erg interessant: hier wordt de grote slag tussen PC gigant Intel versus de grote jongens uit de embedded/telefoonmarkt uitgevochten.

N.B. Bedenk ook dat je in de meeste gevallen helemaal niet puur de beste performance-per-watt wilt - maar tot op zekere hoogte gewoon de beste performance. Of het laagste verbruik. Of de laagste prijs.

[Reactie gewijzigd door Dreamvoid op 7 september 2010 19:07]

Nee, anders zou iedereen nog met het supersimpele ontwerp uit 1980 werken, maar dan op hogere klok en op een kleiner procede gebakken.

Een deel van je verhaal klopt en een deel van je verhaal klopt niet, zo is een ontwerp uit 1980 (en eerder!) niet alleen maar simpel. Het ontwerp kun je nog wel simpel noemen als je kijkt naar iets als de on-chip cache, die werd namelijk toen niet gebruikt, maar als je kijkt naar de geïmplementeerde instructies dan is een processor uit 1980 juist complex. Het idee was namelijk dat je complexe zaken beter door de hardware kon laten uitvoeren, zodat de assembler simpel kon blijven en de programmeur met weinig instructies toch heel erg krachtige zaken kon laten gebeuren. Anno 2010 is die complexiteit bij de x86-series juist een belasting en zolang Intel (en AMD) deze niet loslaat zal er altijd enige (nodeloze) ballast meegesleept worden.

Een ARM-processor is dan wel simpel als je kijkt naar de aanwezig instructies (waarbij ik me voor de vergelijking t.o.v. x86 even beperk tot de integer-instructies en FPU's/multimedia-extensies laat voor wat ze zijn, maar dat wordt opgevangen door de compilers. Inmiddels wordt er, behoudens zeer reken-intensief werk, namelijk niet meer in assembler geprogrammeerd. Door heel slim om te gaan met de aanwezige ruimte voor instructies, heeft de ontwerper een redelijk elegante instructieset weten ner te zetten.

Een ander verschil tussen de x86-serie en de ARM serie is het verschil dat je alle instructies op een ARM conditioneel kunt uitvoeren (of juist niet uitvoeren natuurlijk), terwijl je op een x86-serie beperkt bent tot het conditioneel uitvoeren van sprongen (JMP of Branch instructies). Doordat je op een ARM alle instructies wel/niet uit kan laten voeren [afhankelijk van de processorvlaggen) heb je niet direct een branch-predictor nodig of kun je met een simpelere branch-predictor werken - een sprong is nu eenmaal een kostbare operatie die zaken als een pipeline (en eventueel cache) weer "leeg" maken en deze moeten weer wel gevuld worden.

Maar je moet ook blijven innoveren, want de trucs die werkten op een 16 MHz chipje werken doorgaans niet ideaal meer op 1 GHz (waar Intel bv achterkwam met de P4/Netburst).

Juist het ontwerp van de P4 toonde pijnlijk aan dat de x86-instructieset op bepaalde punten gewoon niet slim opgezet was. Als ik me goed herinner had de(ze) P4 namelijk een erg lange pipeline en die moet wel iedere keer gevuld worden als je een sprong maakt - de software was juist geschreven op een veel kortere pipeline en dus ging er veel tijd verloren na iedere sprong en was een 1GHz processor dus mogelijk trager dan een 250 toto 500 MHz processor met een veel kortere pipeline - voor dezelfde soort code uiteraard. Als de code weer aangepast wordt en dus voor de P4 geschikt gemaakt kan de software weer veel sneller worden.

Juist het grote verschil (in dit geval voor wat betreft de pipeline) t.o.v. de eerdere processors zorgde dus voor een "minder goed" werkende Intel Pentium 4.

En aangezien de komende tijd verwacht wordt dat het segment waar de meeste cpu's worden verkocht niet meer de PC markt is, maar de netbook/tablet/smartphone markt, is dit erg interessant: hier wordt de grote slag tussen PC gigant Intel versus de grote jongens uit de embedded/telefoonmarkt uitgevochten.

Als Intel niet los komt van de bagage uit het verleden en dus onbeperkte compatibiliteit na blijft streven, zal men altijd op power-efficiency op een achterstand blijven - naar mijn mening uiteraard.

Het probleem dat Intel hierbij heeft is dat de consument snel verwacht dat op een x86-notebook/tablet MS-Windows draait en bijna alle Win32-toepassingen die men kan bemachtigen zitten ze hier ook met een probleem. Als ze de compatibiliteit met het verleden loslaten hebben ze geen voordeel meet t.o.v. ARM (en andere embedded processor-fabrikanten) en moeten ze dus nog harder hun best doen om een deel van de markt te veroveren.

N.B. Bedenk ook dat je in de meeste gevallen helemaal niet puur de beste performance-per-watt wilt - maar tot op zekere hoogte gewoon de beste performance. Of het laagste verbruik. Of de laagste prijs.

Nu telefoons meer en meer smartphones worden en consumenten verwachten dat ze lang op een batterij-lading kunnen werken, maar ook filmpjes e.d. kunnen bekijken is een hoge(re) performance per Watt nog steeds relevant.

Als je slechts 1 dag met een telefoon kan werken en deze moet opgeladen worden, dan is dat minder fijn dan wanneer je 5 dagen met een telefoon kan werken - bij eenzelfde soort gebruikt bedoel ik dus...

Als Intel niet los komt van de bagage uit het verleden en dus onbeperkte compatibiliteit na blijft streven, zal men altijd op power-efficiency op een achterstand blijven - naar mijn mening uiteraard.

Maar dat geldt uiteraard ook voor de ARM instructieset uit 1983. Er zijn sindsdien heel wat architecturen gekomen en gegaan (IA64 was de laatste uitdager), en zowel x86 als ARM zijn beide flexibel genoeg gebleken om zich telkens weer te handhaven. Uiteindelijk moet je ook niet teveel waarde hechten aan een instructieset - dat is uiteindelijk alleen maar een interface bovenop het onderliggende silicon. Instructiesets kunnen uitgebreid worden, of versimpeld - en dat doen de bedrijven erachter dan ook.

Als Intel niet los komt van de bagage uit het verleden en dus onbeperkte compatibiliteit na blijft streven, zal men altijd op power-efficiency op een achterstand blijven - naar mijn mening uiteraard.

Maar met Moorestown Atom heeft nu al Intel geen power-efficiency achterstand meer. De vraag is alleen of het commercieel gaat werken: willen smartphone bouwers wel aan x86? Ze zijn ARM gewend, alle huidige software zou geport moeten worden, of er moet allerlei desktopsoftware voor kleine schermpjes worden omgebouwd. Ik denk dat Intel het moeilijk gaat krijgen om x86 naar smartphones te krijgen, niet omdat hun cpu's zo slecht zijn, maar vanwege de achterstand op softwaregebied. Tablets zijn de enige waar het veld nog open ligt. Bij netbooks heeft Intel nu 100% marktaandeel, dat kan alleen maar omlaag.

[Reactie gewijzigd door Dreamvoid op 8 september 2010 01:12]

x86 en ARM zijn beiden al redelijk op leeftijd, maar x86 draagt meer overtollige bagage mee uit het verleden (om er een paar te noemen: realmode, 16-bit protected mode, BCD instructies, string-instructies).

De originele ARM-instructieset is maar beperkt van "voortgaand inzicht voorzien", hij was gewoon direct erg goed. De belangrijkste "fout" die er in zat was dat de adresruimte beperkt was, inmiddels reeds lang gecorrigeerd.

Wel zijn er natuurlijk vele instructies aan toegevoegd voor allerhande toepassingen.

[Reactie gewijzigd door dmantione op 8 september 2010 08:36]

Kleine voetnoot: de Cortex core kan geen ARM instructies uitvoeren! De Cortex maakt gebruik van de 16 bits ARM-thumb instructieset.

Kleine voetnoot: de Cortex core kan geen ARM instructies uitvoeren!

Dat leek me sterk en even zoeken leverde het volgende op voor de Cortex-A9:

ISA Support:

• ARM
• Thumb®-2 / Thumb
• Jazelle® DBX and RCT
• DSP extenstion
• Advanced SIMD NEON™ unit (Optional)
• Floating Point Unit (Optional)

Bron: http://www.arm.com/produc...rs/cortex-a/cortex-a9.php

De Cortex-A9 kan dus wel gewoon de 32-bit ARM instructies uitvoeren (ware het niet dat de legacy 26-bits adressering uit 1983 niet meer ondersteund wordt, maar alleen de 32-bit adressering die sinds de ARM6 (uit 199x) aanwezig is...

"Bij netbooks heeft Intel nu 100% marktaandeel, dat kan alleen maar omlaag."

Oa. HP heeft/had netbooks met AMD-processors. Juist de markt van netbooks is het slagveld, omdat daar alle markten bijeen komen (laptops, tablets, e-readers, smartphone).

OK strikt gezien niet 100%, maar wel heel dichtbij. AMD-based nettops zijn tot nu toe commercieel niet succesvol, vrijwel alle verkochte netbooks zijn Atom-based (of Celeron/Pentium CULV, maar zijn dat nog netbooks?). Leuk voor Intel, maar dat betekent dat het alleen maar slechter kan worden. AMD komt met de nieuwe generatie, ARM gaat het proberen.

Omgekeerd is het natuurlijk in de smartphone/tablet markt - Intel heeft nu 0% marktaandeel, slechter wordt het niet.

Hmm uit de SpecINT nummertjes hier zit de Atom toch wat sneller in integer performance, de single core 1.5 GHz Moorestown Atom komt er 2x sneller uit dan een 2x1GHz Cortex A9. Maar goed, dat is de nieuwe Moorestown Atom, niet de huidige Pineview.

Het blijft natuurlijk de vraag of deze waarden ook als 100% basis genomen kunnen worden, want in het artikel waar je aan refereert staat namelijk het volgende:

Keep in mind that SPECint is just as much of a compiler benchmark as it is a hardware benchmark, so real world performance could very well differ.

Hieronder heb ik al geschreven dat het bij een test als SunSpider ook uitmaakt hoe de JavaScript-engine geschreven is voor de uitkomst van de test, maar dat geldt dus ook voor een test als SpecINT. Verder vraag ik me ook af of de test alle aanwezig cores benut.

Enig zoekwerk (naja Google) leverde het volgende op:

If a single CPU has multiple cores, only a single core is used; hyper-threading is also typically disabled,

Bron: http://en.wikipedia.org/wiki/SPECint

Verder is voor een tablet en voor een smartphone ook nog eens de MIPS/Watt ratio heel erg belangrijk. Als een x86-processor 25% sneller is (voor real world toepassingen) maar slechts half zo lang op een batterij-lading werkt dat is de ARM-processor toch nog interessanter. Als je 1 dag kunt doen met een batterijlading van je iPhone of slechts een 1/2 dag, dan is die 1 hele dag toch interessanter

Ik ben me heel goed bewust dat die cijfers van Intel komen - daarom denk ik dat die "2-3x sneller" claims ook niet reeel zijn. Maar klok-voor-klok net zo snel, dat is niet zo moeilijk te geloven. Dat haalde de 1st gen Atom ook al ten opzichte van de oude Cortex A8. Als je bij ARM's promo materiaal kijkt zie je ook alleen maar hun favoriete bench (CoreMark).

Wat betreft het verbruik: Intel claimt voor Moorestown een 0.6 mW/MHz, en ARM voor de A9 ergens tussen de 0.5-0.6 mW/MHz (A8 was 0.59) dus qua performance/watt zit er weinig meer tussen. Maar ook hier weer: dit verbruik zegt ook weer niet alles, wat je wilt weten is hoeveel ze verbruiken in idle (waar een telefoon/tablet 99% van de tijd in staat), en daarvan zijn er nog geen cijfers beschikbaar - niet van Intel maar ook niet van ARM.

MIPS per watt zegt ook weer niet alles: hoe complex zijn die instructies? Als ik dezelfde berekening op cpu X in 3 instructies kan doen, en op cpu Y in 2 instructies, dan kunnen ze nog zo goed dezelfde MIPS/Watt rating hebben, doe mij dan maar cpu Y.

[Reactie gewijzigd door Dreamvoid op 8 september 2010 11:46]

Ze zijn perfect te vergelijken met de kloksnelheden van Intel. Zowel deze als een Intel 1Ghz processor doen even veel stappen per seconde.
Wat voor werk ze verrichten per kloktik is alleen anders. Of je nou met een vrachtwagen of een brommertje 50 km/ rijd, beiden rijden even snel. Die vrachtwagen zal alleen wat meer mee kunnen nemen.

Ah op die fiets.
Dan vind ik het vreemd dat deze (IPC) niet genoemd wordt bij vermeldingen van nieuwe processoren..

Ik kijk zelf ook altijd naar benchmarks, maar 'normale' mensen snappen er niets meer van, als ze in de winkel een PC zien (destijds P3 3.4ghz) en een half jaar later een dualcore zien met 1.6ghz dan wordt vaak verondersteld dat de P3 sneller is, omdat deze een hogere kloksnelheid heeft...

omdat zelfs IPC niets zegt, een ARM instructieset is anders dan een x86 instructie set,

dus dan moet je op apps nivo gaan vergelijken, hoelang heeft het nodig om een document te openen, of hoelang heeft het nodig om in een db het juiste telnr te vinden. dergelijke verglijkingen hebben zin, elke andere vergelijking is bij voorbaat al zinloos als je totaal verschillende cpu's met elkaar wilt vergelijken.

Daarvoor zijn benches als Sunspider (Java performance), SpecINT (integer performance) , WL33 (web page downloads), CoreMark (integer performance), SpecFP (floating point performance) bedacht.

[Reactie gewijzigd door Dreamvoid op 7 september 2010 18:43]

In het geval van de Sunspider-benchmark (die overigens niet Java, maar JavaScript performance meet) en de WL33-benchmark (ik ken deze niet, maar als je beschrijving klopt maakt dat niet uit) zit je weer met het probleem dat de implementatie van de JS-engine en/of de browser wel uitmaakt voor de uitkomst van de test.

Als je nu een slimme JIT hebt voor JavaScript code die je op de ARM-processor meet en op de x86-serie heb je een JS-engine zonder JIT, dan kan een trage ARM-processor mogelijk rondjes draaien rond een x86-processor. Dat heeft dan niets met de processor, maar met de implementatie van de software te maken.

Ook benchmarkts die bovenop een VM (denk aan de Java VM en de dotnet-VM) draaien kun je moeilijk maatgevend noemen.

Ook benchmarkts die bovenop een VM (denk aan de Java VM en de dotnet-VM) draaien kun je moeilijk maatgevend noemen.

Maar dat is wel hoe de meeste platforms tegenwoordig opgebouwd zijn, en wat dus maatgevend is voor welke cpu je als smartphone/tablet bouwer kiest voor je apparaat. Het uiteindelijke doel is om apps zo snel mogelijk te laten draaien. Een geweldige cpu core die in een omgeving moet werken met een slome geheugenbus, brakke gpu, inefficient OS, en crappy VM/JIT compiler - zal minder goede keus zijn dan een matige cpu in een supersnelle omgeving. Dat is ook altijd het moeilijke van 'real life' benchen tegenover specifieke onderdelen benchen. Zie de Itanium/IA64, waar razendsnelle synthetische benches volledig teniet werden gedaan doordat het extreem moeilijk was om 'in real life' effectieve code te compilen.

Snelle cpu core ≠ snelle applicaties.

[Reactie gewijzigd door Dreamvoid op 8 september 2010 11:55]

Op app niveau vergelijken (real life apps tenminste) is voor de eingebruiker immers het belangrijkst.
Immers het enige wat er werkelijk toe doet voor de eindgebruiker is hoe snel zijn Word werkt, of hoe soepel zijn game draait. Of dat nu open 1MHz 8 bits CPU of een 10GHz 128 bit CPU is maakt eigenlijk niets uit.

Voor CPU's vergelijken is ook dit echter weer niet sluitend. Je vergelijkt dan immers ook de compiler/optimalisatie.
Om CPU's te vergelijken via apps zou je dan eigenlijk de apps voor beide arhcitecturen helemaal opnieuw moeten bouwen, en voor de architectuur optimaliseren...waarbij de functionaliteit natuurlijk wel identiek moet blijven.
Voor een benchmark als SpecINT is dat nog wel te doen, maar voor een real live app zoals een game is dat in principe misschien mogelijk, maar commercieel gezien in ieder geval nooit rendabel. Daarom zal een app die is ontwikkeld voor een x86 architectuur en geport naar ARM in de praktijk een voordeel hebben op x86 (en omgekeerd natuurlijk hetzelfde).

En vaak hadden ze dan per ongeluk ook gelijk ook omdat er destijds nauwelijks software was die het kon ondersteunen.

mooie overclock P3@3.4ghz!, je zal wel bedoelen P4@3,4GHz, en ja, een C2D@2GHz is sneller

Of je nou met een vrachtwagen of een brommertje 50 km/ rijd, beiden rijden even snel. Die vrachtwagen zal alleen wat meer mee kunnen nemen.

Niet alleen dat, de vrachtwagen zal ook aanzienlijk meer brandstof verbruiken.
Voor de desktop wat minder belangrijk, voor mobiel des te meer.

Dat is het nou juist, het gaat niet alleen om die 50 km p/u, maar juist ook om die hoeveelheid vracht.
Je kan wel met 200 km p/u per uur 2 blikjes bier vervoeren en dat dus, over dezelfde afstand/tijd als de vrachtauto, 4 keer doen (terug weg is niet boeiend in deze vergelijking), maar als die vrachtauto 16 blikjes per keer vervoert is hij toch 2x zo snel.
Dus inderdaad zegt die 1Ghz helemaal niks en is het pure marketing.

Ze zijn juist helemaal niet te vergelijken. Kloksnelheid is een equivalent van het toerental van een verbrandingsmotor, het aantal instructies per kloktik met de overbrengingsverhouding. En een vrachtwagen die in de hoogste versnelling staat, zal bij 2000rpm veel harder rijden dan een brommer in de hoogste versnelling bij 2000rpm.
Dus kloksnelheden tussen verschillende procesor platformen zijn niet te vergelijken.

een andere processor architectuur kan je nooit vergelijken megahertz-voor-megahertz. Dat is afwachten tot er benchmarks uit zijn die vergelijkbaar zijn met bestaande benchmarks .

Nee totaal niet, is een hele andere architectuur en instructieset.
Desktop, server en laptop cpu's zijn allemaal gebaseerd op X86. En dit is totaal iets anders. (wat het wel is weet ik ook zo 123 niet, kan iemand mij daarbij op aanvullen?)

wel jammer dat het verbruik nergens te vinden is. Als het verbruik 5x zo hoog is, en niet goed naar beneden schaalt, ben je voor mobiele toepassingen alsnog niet zoveel met je véél krachtigere cpu...

The Cortex-A9 power-optimized hard macro implementation delivers its peak performance of 4000 DMIPS while consuming less than 250mW per CPU when selected from typical silicon.

Google is weet alles , daarnaast staat het gewoon op de officiele site van ARM waar ook nog een heel deel andere specificaties staan

Onder het tablad Performance staat nog 'Total power at target frequency', onder het kopje 'Cortex-A9 Dual Core Hard Macro Implementations' staat nog 1.9 W.

Een tablad ernaast staat ook iets niet oninteressant, er staat namelijk dat de Cortex-A9 tot 4 cores heeft!

[Reactie gewijzigd door ObAt op 7 september 2010 17:42]

Maar dit is het design van ARM zelf.

Wat de cpu's doen die daadwerkelijk gemaakt worden aan de hand van deze instructies / designs / etc moet je zien.

Qualcomm, TexasInstruments, Samsung.. ze maken allemaal CPU's (en SoC's) die gebaseerd zijn op een CortexA8 core, maar toch verschillen ze (een beetje) megahertz-voor-megahertz. Als je vervolgens het hele SoC gaat vergelijken (en dus ook de GPU die er dan bij zit) zitten er al helemaal grote verschillen tussen.

Dus staar je niet teveel plat over wat ARM zelf zegt wat hun CortexA9 kan / is... het gaat er om wat de chipmakers er uiteindelijk mee weten te doen

Om precies te zijn: ARM maakt modular cores waarbij je element wel of niet in je design kunt doen (bijv. minder cache) om zo de 'sweet-spot' voor energie/performance te halen voor het design wat je voor ogen hebt.

mijn google wist het niet .

Gezien het verbruik van een singlecore cortex A8 1 gighz op "less than 300mW" ligt, lijkt het me dat het verbruik dus wel een stuk hoger zal liggen dan op de singlecore cpu. Nu maar hopen dus dat de 2de core uitgezet kan worden, of dat wordt een extra energieslurper in je telefoon.

klopt dat de cortex-A9 ontworpen is om als quad-core te kunnen gebruiken.
niemand zag er echter nog brood in om een quad-core in een tablet of telefoon te stoppen vanwege de hogere energie verbruik en overkill.

iedereen blijft nu nog even met de dual-core variant spelen dus

Ik denk dat het verbruik mss zelfs lager is. Je weet wel, technologische vooruitgang? Bij Intel zie je dat elke generatie net zo zuinig of zuiniger is bij een dubbele aantal cores

Erg mooi! Voor smartphones misschien een beetje overkill, maar voor de volgende generatie tablets precies wat het nodig heeft.

Ik kan me heel goed voorstellen dat de tablet uiteindelijk krachtig genoeg worden om je gewone pc te vervangen. Zet je zet tablet op een dockingstation, met daaraan een monitor, netwerk kabel, toetsenbord en muis en een hdd. Eventueel met 2 verschillende GUIs (wel of geen docking).

Maar vanuit concurrentie oogpunt gezien loopt samsung toch wel een paar maand achter. De tegra 2 komt nu op de markt, de quallcomm komt naar ik meen eind dit jaar uit (dualcore), TI heeft dacht ik zij. OMAP dualcore ook rond het einde van het jaar klaar en Apple zal bij de iPad 2 ook wel met een dual Core komen.

De enige concurrent is de Tegra 2. De vraag is of Tegra 2 qua verbruik beter of slechter dan de nieuwe a9.

Qualcomm overtuigt mij nog steeds niet met haar Adreno GPU's.

Uh, er zit toch twee Cortex A9 cores in de Tegra2 (Tegra 250)?

A9 is het design van arm, niet specifiek deze soc van samsung. De tegra 2 heeft ook 2 A9 cores namelijk.

Design ja, maar je bent vrij als fabrikant te doen wat je wil qua productie en andere extra features of verbeteringen.

De PC markt heeft andere belangen dan deze kleine multimedia apparaten. Ik gok dan ook dat ze minder geschikt zijn voor het werk. Bovendien gebruiken we nog steeds erg veel Windows die niet op ARM-chipsets werkt.

Of het overkill is, is maar de vraag. Zoals de tijd ons geleerd heeft is niets snel genoeg en willen we altijd sneller. Bovendien wil je in dit soort apparaten niet het maximale eruit halen maar hem zo efficiënt mogelijk laten draaien.

Overkill? nee: nu is flash mogelijk

is wel overkill voor flash.
hier op <912mhz snapdragon werkt vrijwel alles wat ik er tegenaan gooi soepel.
of het nou gaat om een flashgame, of een youtube filmpje.

ik wil helemaal niet dat flash mogelijk is

De Galaxy S heeft een PowerVR SGX540. En in het persbericht wordt er geen melding gemaakt van een PowerVR SGX530.

Damn het idee dat deze chip 5x zo snel is als wat er in de GS zit. Kippevel moment!!

Dat hangt er dus van af welke gpu er nou bedoelt word in het artikel.... Is die 5x sneller als een 530 dan is die 40% sneller dan een 540 die zelf 3x sneller is dan een 530... De tekst in het artikel is hoe dan ook fout

5x sneller als een 540 zou echt ziek zijn, de 540 is momenteel de snelste gpu in te telefoons...

Denk dat meerdere tweakers dit al hebben aangekaart, maar leuk al die extra power etc. Maar heb liever een telefoon die 2 dagen op een accu kan lopen ipv 1.
Vind dat fabrikanten hier qua ontwikkeling bij chips/smartphones niet echt op letten.

je kunt natuurlijk dan ook weer underclocken, als je het on-demand instelt heb je bij telefoons helemaal voordeel.

Nou zeg. Heb ik net een galaxy s, is de cpu al weer veroudert. Helaas zal het zo altijd blijven gaan...

Tegen de tijd dat je abonnement afloopt zal deze dualcore eindelijk wel in de winkel liggen

Duurt natuurlijk ook nog even voordat je daadwerkelijk een telefoon kan kopen met deze cpu

damn, en de hummingbird is al zo verdomde snel voor in een foon

Toch ben ik benieuwd of mobiele besturingssystemen (android/iOS/WP7) wel efficiënt met dualcore processoren om kunnen gaan. Dat zag je ook in het begin met de dualcore processoren in PC's: die waren door veel software nog niet ondersteund en werd vaak nog steeds maar 1 kern gebruikt...

het zal mij niet verbazen als Android 3.0/gingerbead, dit wel zou kunnen, aangezien google de ontwikkeling ook wel ziet

Neem aan dat ze van de PC geleerd hebben, en zich daar dus bij de bouw van een OS al zoveel mogelijk op richten (vooral op alles netjes over treats verdelen), Voor programmeurs bij Android hoeft het niet uit te maken, als de Dalvik-VM dat werk uit handen neemt van het verdelen is dat een update aan het OS en niet aan de Apps...

Anyway, neem aan dat het op de smartphonemarkt sneller zal gaan als op de PC markt, zal natuurlijk niet een directe overschakeling zijn en er kunnen best 1 a 2 jaren aan voorbij gaan voor het echt optimaal is, maarja ik ben al verkocht, het feit dat ik een dual-core in me telefoon kan hebben doet me al kwijlen