News Apple: A9-SoC hat zwei Kerne, 3 MB L2 Cache und bis zu 1,8 GHz

[user4base]

Der Vergleich Desktop CPU (x86-Prozessor) und SoC (ARM) ist nicht so einfach.

Man muss bei einem Benchmark der auf verschiedenen Plattformen laufen soll, doch einige Kompromisse eingehen und sei es nur die Speichergröße die dann meistens nur ein paar wenige MB beträgt.

Solche kleinen Benchmark Apps schmeicheln zumeist den kleinen SoCs und die großen CPUs können ihre Vorteile gar nicht in die Waagschale werfen/nutzen. Beispielsweise bringen die großen L3 Caches der CPUs bei solchen "kleinen" Benchmarks überhaupt nichts (Sprungvorhersage, Cache Hits, ..). Genauso werden die Befehlssatzerweiterungen wie SSE/AVX/.. überhaupt nicht oder fast gar nicht berücksichtigt. Aber genau wenn es um größere komplexe Berechnungen über einen längeren Zeitraum geht, sind Desktop Systeme den S(ystemen)oC überlegen. Was bei der Leistungsaufnahme solcher kleinen Zwerge auch nicht verwunderlich ist. Mehr als ein Watt über mehrere Sekunden würde so einen Zwerg "grillen".

Um mal wieder einen Autovergleich zu starten.
Ich führe einen Beschleunigungstest durch von 0 auf 70 Km/h oder 100Km/h
Einmal mit einem PKW ... und einmal einem Motorroller und stelle fest, so viel schneller ist ein PKW bei so einem Beschleunigungstest gar nicht.
Meine Schlussfolgerung lautet daher: ein Motorroller hat die gleiche Leistung wie ein PKW und spätestens in ein, zwei Jahren wird der Motorroller den PKW "leistungsmäßig" abgehängt haben.

Das mag für so einen Beschleunigungstest durchaus gelten, dennoch spiegelt so ein Beschleunigungstest nur einen kleinen Teilbereich wieder, was die Leistungsfähigkeit in der Praxis betrifft. In der Praxis kann es durchaus vorkommen dass ich mit meiner Familie im Auto über die Autobahn mehrere 100 Km zu meinen Eltern fahre. Mit einem Motorroller würde das in eine Quälerei ausarten.
In der Praxis kommt es allerdings auch vor, dass man(n) mit der Vespa schnell zum Bäcker fährt um ein frisches Baguette zu holen und dabei schneller ist, als wenn man den PKW erst aus der Garage holt. Kann man jetzt schlussfolgern: deshalb ist eine Vespa "leistungsfähiger" als ein PKW, wohl kaum.

Die Benchmarkergebnisse einer App mit einem Bauchgefühlprozentsatz zu multiplizieren ist auch eine Möglichkeit.

 

[Sun_set_1]

Nö. Es kommt einfach auf die Software an. Wenn viel Mathe dabei ist, ist es einfacher zu parallelisieren wenn nicht geht es nicht so gut.

So ist z.B. Video Co- und Encoding super genial zu parallelisieren. Spiele auf der anderen Seite eher weniger, wobei es auch hier Ausnahmen gibt was dann aber mehr SImulationen sind als "Spiele".

Sorry habe doch tatsächlich vergessen das Leute Videos von 4K in x264 auf ihrem Handy encodieren.
Wie viele Apps hat man eigentlich gleichzeitig und aktiv auf einem Diplay laufen?
Denn ansonsten wäre es ja tatsächlich so, dass ein App-Prozess erstmal vom Kernel parallelisiert und nachher wieder zusammengeführt wird. Und das schafft Android immer mit dem Faktor, wie bei Geekbench, 0,85 ?

Respekt, das sollte man den Leuten bei SUN und ARM mal erklären, dass die von Ihnen erstellten Angaben zu Ihrer eigenen Architektur nicht richtig sind.

Generell sprechen wir hier schon über das gleiche, aber genauso wie die Leute sagen, "die SingleCore Perfomance ist nicht 100%ig entscheidend" genauso kann man sagen, "Die ermittelten Benchmark MultiCore Werte entsprechen umso weniger der Realität, desto mehr Kerne eingesetzt werden"

 

[Cool Master]

@user4base

Damit kann auch die Familie auf dem Roller mitfahren

http://allcar-india.blogspot.de/2013/02/green-wheels-this-chinese-stretched.html

Aber es stimmt natürlich was du schreibst. Deswegen würde ich auch nicht nach Benchmarks ein Handy kaufen. Entweder es sagt mir optisch und software technisch zu oder nicht

 

[Sun_set_1]

Aber es stimmt natürlich was du schreibst. Deswegen würde ich auch nicht nach Benchmarks ein Handy kaufen. Entweder es sagt mir optisch und software technisch zu oder nicht

/sign

user4base
Die Benchmarkergebnisse einer App mit einem Bauchgefühlprozentsatz zu multiplizieren ist auch eine Möglichkeit.

Nicht sicher ob das in meine Richtung ging, aber:

So zählt z. B. Oracle bei Mehrkernprozessoren jeden Prozessorkern auf einem Chip mit 0,25 (Sun UltraSPARC T1), 0,5 (Intel und AMD CPUs) oder 0,75 (HP, IBM und Sun RISC CPUs)

Und die 0,85 waren im 100 gerechnet von den Screenshots Cool Master.

1286 * 4 = 5144

Geekbench MC:

4 Cores = 4325

4325:5144*100 = 84,078 %.

Und ja, die Integerwerte wären dafür besser geeignet, ich war einfach zu faul zum googeln

 

[user4base]

@user4base
...
Damit kann auch die Familie auf dem Roller mitfahren

http://allcar-india.blogspot.de/2013/02/green-wheels-this-chinese-stretched.html

....

Cooooles Teil, Haben Will!
Damit könnte Tante Erna, Onkel Hubert und Oma Brunhilde auch noch mit. Das nenne ich mal Fortschritt bzw. eine vorhandene Technologie ausreizen. Wenn man da jetzt noch einen Beiwagen montieren könnte, dann könnte ich ja noch die Nachbarskinder....

@Sun_set_1
Nein, ging nicht in deine Richtung.
Jetzt aber, Mahlzeit.

 

[Sun_set_1]

Wenn man da jetzt noch einen Beiwagen montieren könnte, dann könnte ich ja noch die Nachbarskinder....

Das wäre dann Big.LITTLE

Mahlzeit und Guten

 

[G00fY]

Sieht vieles danach aus, dass Apple mit dem iPhone 7 zu einem Hexa-Core wechselt:
Apple's next-gen A10 chipset rumored to have hexa-core CPU

Klar alles Gerüchte, aber lustig falls gerade die Leute die aktuell noch Apple für die ST Leistung loben bald die Argumentation ändern müssen.

 

[Cool Master]

@G00fY

Wieso? Der Grund Tenor ist doch: Apple sieht aktuell nicht den Vorteil der Quad und Hexas. Und aktuell stimmt es ja auch. Der A9 macht doch eine gute Figur. Dazu kommt in einem Jahr kann sich viel ändern. Fürs iPhone kann ich mir es zwar nicht vorstellen, aber fürs iPad Pro durchaus.

 

[modena.ch]

Sechs dieser Monster kriegst du bei gleicher Fertigung und ich geh davon aus das 10NM nicht
nächstes Jahr bereitsteht, niemals in ein Tab oder gar Smartphone.
Entweder Chip verändern, wodurch er IPC verliert, dafür mehr Kerne bekommt. Oder neue Fertigung,
anders kaum zu machen.

@YforU

Beim Appupdate werden laut Anandtech unter Android 9-10 Threds gleichzeitig
gefahren. Also einen 8-10 Kerner kann ich damit sicher etwas auslasten.
Davon ab, dass die meisten dort getesteten Apps zumeist mehr als 4 Kerne
belastet haben. Also ja da leistet man gute Arbeit mit MT.

Und du kannst aufgrund eines Benches doch keine Schlussfolgerungen machen wie IPC in der Nähe von
Core i oder Zen oder ähnliche Energieeffizienz. Das ist völlig jenseits jedweder Realtität.
Was ist wenn der Bench rein im grossen Cache läuft und beim x86 nicht? Ist das noch vergleichbar?

Dieser ARM Zwerg mit seinen 2-3W würde bei den meisten Vergleichen, soweit überhaupt möglich,
gegenüber den meisten x86 Prozessoren gnandenlos verlieren.
Die Leistung kann und wird mit einem 3W ARM Chip und ähnlicher Fertigung nie im Leben an einen 10-15W x86 Chip ranreichen.
Von 45-140W sprechen wir noch gar nicht.

 

[Sun_set_1]

@Modena

Das ist richtig, aber zeig mir bitte mal eine Seite des Artikels bei Anandtech, wo das Multithreading aus Sicht des Outputs und Verlustleistung durch Parallelisierung betrachtet wird.

Da geht der Kollege nämlich leider gar nicht drauf ein, der ganze Artikel spielt sich aus Sicht des Inputs und nötigen / effizienterem Energieverbrauch ab. Es geht, ganz vereinfacht gesagt, darum, dass Android gut parallelisiert und das Konzept .LITTLE in viele Anwendungsfällen Energie sparen kann, da eben nicht immer die dicken Kerne angeschmissen werden müssen.

Bei aller Mühe die sich der Autor machte, wäre es doch ein einfaches gewesen Tools zu programmieren die andere Kerne deaktivieren und sich darauf beschränken nur jeweils einzeln einen dicken Kern und einzeln einen kleinen Kern auszulasten und voll zu beanspruchen.

Dann vergleicht man den rein rechnerischen Output von jeweils dann 4 Kernen (x4 rechen) mit dem wirklichen der bei Auslastung von jeweils allen Kernen erreicht wird.

Nur wenn man das dann im Vergleich zu Frameraten, I/O Operations /s usw usf stellt, die theoretischen und praktische Werte im Vergleich rechnet, kann man überhaupt erstmal eine Verbindung zur wirklichen Outputeffizienz (Leistung) herstellen. Ansonsten sagt der Anandtech Artikel eigentlich nur aus, dass Big.LITTLE unter Android sehr Energieeffizient arbeiten kann.

 

[iSight2TheBlind]

@G00fY
Ja, weil Apple dann die einzelnen Kerne natürlich nicht mehr mit 1,8GHz takten wird sondern stattdessen nur noch mit 600 MHz, weil 2 Kerne @ 1,8GHz = 6 Kerne mit 0,6 GHz^^

Das ist natürlich Unsinn!

Wenn wir Apple gerade für die Singlethreaded-Leistung loben, dann heißt das einfach, dass da sofern sich das Gerücht bewahrheit beim A10 die ST-Leistung auf dem gleichen Niveau bleiben würde (und möglicherweise nicht erhöht, wird ja von der Konkurrenz eh nicht erreicht) und einfach mehr Kerne und damit höhere MT-Leistung dazukommen würde.

Wo zerstört das unsere Argumentation?

Und wenn es vollwertige Kerne sind, heißt das doch nur, dass mit iOS 10 und dem iPhone 7 irgendetwas kommen muss, was die Mehrleistung bei MT-Anwendungen ausnutzen kann.

Naheliegender ist aber entweder irgend eine Form von Big.little-Architektur oder dass keine vollwertigen CPU-Kerne gemeint werden sondern spezielle Kerne für Sonderfunktionen.
So spricht Apple ja auch beispielsweise davon, dass sie den M9-Coprozessor anders als bei den vorherigen Generationen nun direkt in den SoC integriert haben.
Je nach Sichtweise wäre das ein (1) weiterer Core.

Motorola hat den SoC des Moto X doch auch als X8 Mobile Computing System bezeichnet und damit die zwei CPU-Kerne, die 4 GPU-Kerne, einen Kern für Spracherkennung und einen Contextual Awareness-Kern (d.h. das was bei Apple der M7 und M8 bisher gemacht haben, wobei der M9 nun auch für die Spracherkennung zuständig ist) gemeint.

Und wenn man das Gerücht so betrachtet (und dabei beachtet, dass NICHT Apple von einem Hexacore gesprochen hat und deshalb lügen müsse, wenn sie NUR einen doofen Spracherkennungsprozessor etc. damit meinen) ist es sogar recht realistisch.

Gegen einen dritten vollwertigen CPU-Kern spricht wenig, außer Platz/Strombedarf auf dem SoC, für die restlichen verbleibenden drei Kerne um ein Gerücht "Hexacore" zu erfüllen bleiben dann noch viele Möglichkeiten um Coprozessoren zu integrieren, wenn man den M9 bedenkt muss es dann sogar nur noch zwei weitere Coprozessoren geben.

Und bei Apple halte ich es für realistischer, dass da ein paar Coprozessoren für interessante Features hinzukommen (Spracherkennung = Siri, der M-Coprozessor für Bewegung, beispielsweise als Schrittzähler) als dass man einfach stumpf 4 normale CPU-Kerne dranklatscht um auf brachiale Weise mehr Leistung zu bekommen.

 

[D708]

Vergleichbarkeit ist bei Geekbench durchaus gegeben, das Dingen macht auf allen CPUs dasselbe und spuckt normierte Punktzahlen aus. Und da sowohl ARM als auch x86 General Purpose-ISAs mit recht ähnlichen Fähigkeiten sind, spielt das in diesem Fall einfach überhaupt keine Rolle

Hierbei muss allerdings erwähnt bleiben, das die Software ein Grund andere ist. Die Software spricht die Cpu ganz unterschiedlich an. Das ARM dem x86 unterlegen ist, ist hinreichend bekannt, aber halt nicht überall. Die Software spielt die Musik. Man kann es einfach nicht vergleichen.
Man sagt ja auch nicht, der Cpu wäre der GPU unterlegen, obwohl genau in manchen Anwendungsgebieten das der Fall ist. Vergleicht nicht irgendwelche Daten miteinander, das klappt nicht.

 

[Eusterw]

Also "gefühlt" ist mein iPad Air 2, an einem i3 von Intel (hab einen i3-3227 im Thinkpad), schon vorbei gezogen. Egal, ob im Netz surfen, bei Spielen, beim Hochfahren, kopieren oder sonst was.

Die Benchmarks sagen das gleiche, so weit hergegolt scheint das zumindest nicht...

 

[iAtNeH]

Um mal zu verdeutlichen, mit welch unglaublicher Geschwindigkeit sich die Handy-Prozessoren entwickeln, habe ich mal von ein paar repräsentativen Geräten des Mobilen Bereiches ein paar Benchmarks aus Geekbench zusammenkopiert.

Tja um das dannzu vergleich installierst du ein X86 OS auf ARM,
x86 und ARM zu vergleichen ist relativ sinnlos.

Genauso Mining GPU vs Asic

 

[D708]

Also "gefühlt" ist mein iPad Air 2, an einem i3 von Intel (hab einen i3-3227 im Thinkpad), schon vorbei gezogen. Egal, ob im Netz surfen, bei Spielen, beim Hochfahren, kopieren oder sonst was.

Die Benchmarks sagen das gleiche, so weit hergegolt scheint das zumindest nicht...

Gefühlt kann man auch besser Fussball spielen als die Krücken seiner lieblingsmannschaft. Einzig der echte Vergleich fehlt. Versuch mal einen x86 Prozzi auf nem ARM Prozzi zu simulieren. Da kommt fast nur schlechte Geschwindigkeit raus. Anderes herum geht das sehr gut. Jetzt fragt man sich, warum das so ist. (Software)

 

[Eusterw]

...das ARM dem x86 unterlegen ist, ist hinreichend bekannt...

Ja, das war immer so. Aber ist das auch heute (bzw. nächste Woche) noch so?

Guck doch mal in die von mir gepostete Tabelle. Während die Intel-Prozessoren Jahr für Jahr nur langsam an Geschwindigkeit zulegen (<10%, dafür aber konstant etwas Stromverbrauch zurücknehmen), explodiert die Leistung der ARM-Prozessoren geradezu (>50% Zuwachs seit mind. 6 Jahren). War ein Intel-i3 in 2010 in Geekbench noch 10x schneller als ein ARM, so ist mit dem A9, erstmal der ARM schneller als der Intel-i3.

Im Benchmark in 2010 war Intel mit dem i3 10x schneller.
Im Benchmark in 2015 ist Intel mit dem i3 plötzlich langsamer.

Zwar nur ein Benchmark. Aber im Benchmark hat ARM um den Faktor 10 aufgeholt. Laut Aussage von Apple, ist der A9X-ARM-Prozessor im iPad Pro, schneller als 87% aller ausgelieferten Notebooks. Warum wird diese Aussage angezweifelt? Nur weil es ein ARM ist und weil ARM immer lansammer sein MUSS?

Was wenn Apple das nächste MacBook ier den nächsten iMac (wo man nicht auf Stromverbrauch achten muss) mit einem Quad-Core A10 auf 2,5GHZ austattet? MUSS das dann langsamer sein? Nur weil das immer so war?

Die Aussage Intel ist IMMER 10x schneller war im letzten Jahrzehnt korrekt. Aktuell habe ich den Eindruck, das Intel eingeholt wurde. Guckt euch doch selbst mal die UnrealEngine auf dem iPad an. Ich würde mal vermuten, das lauft auf einem i3 auch nicht flüssiger (in so einer Auflösung).

 

[G00fY]

Bei aller Mühe die sich der Autor machte, wäre es doch ein einfaches gewesen Tools zu programmieren die andere Kerne deaktivieren und sich darauf beschränken nur jeweils einzeln einen dicken Kern und einzeln einen kleinen Kern auszulasten und voll zu beanspruchen.

Dafür braucht man mindestens den Quellcode des Kernels und muss diesen entsprechend modden um sowas zu erreichen. Ist also deiner Meinung ein leichtes?

Nur wenn man das dann im Vergleich zu Frameraten, I/O Operations /s usw usf stellt, die theoretischen und praktische Werte im Vergleich rechnet, kann man überhaupt erstmal eine Verbindung zum wirklichen Output (Leistung) herstellen. Ansonsten sagt der Anandtech Artikel eigentlich nur aus, Big.LITTLE unter Android Energieeffizient arbeiten kann.

Hört sich ziemlich wirr an was du da schreibst. In dem Artikel gings nicht um theoretische Werte, sondern einfach um die, in der Einleitung aufgeführte Frage, "how sense [multicore] designs make in real-world usages". Hab bislang keinen Artikel gefunden, wo dies mal derart akribisch und eben nicht anhand von synthetischen Benchmarks betrachtet wurde.

@iSight2TheBlind: Bleibt abzuwarten ob Apple bei gleicher Fertigung und ähnlicher Die Size die Single-Thread Leistung beibehalten kann. Lassen wir uns überraschen.

 

[Eusterw]

Tja um das dannzu vergleich installierst du ein X86 OS auf ARM,

Ist das nicht reichlich sinnlos, einen ARM auf ein x86 Betriebssystem los zu lassen?

Vergleich doch auf Android, das ist ein Betriebssystem, was sowohl für ARM, als auch für x86 optimiert ist. Da war Intel vor 2 Jahren den ARM noch leicht vorraus. Das das heute noch der Fall ist, bezweifel ich.

 

[MasterHAni]

Ist das nicht reichlich sinnlos, einen ARM auf ein x86 Betriebssystem los zu lassen?

Vergleich doch auf Android, das ist ein Betriebssystem, was sowohl für ARM, als auch für x86 optimiert ist. Da war Intel vor 2 Jahren den ARM noch leicht vorraus. Das das heute noch der Fall ist, bezweifel ich.

Deine Tabelle ist immernoch falsch und viele Werte sind Falsch!!!

Wegen deinem wunderschönen ThinkPad. Nichtmal dran gedacht das du andere stellen hast an denen es hackt. Ich glaube kaum das der prozie beim kopieren der Flaschenhals ist. Das ist ganz klar die Festplatte. Genauso wie beim Browser. Meistens auch die Festplatte weil die Zugriffszeiten so schlecht sind

 

[Sun_set_1]

Dafür braucht man mindestens den Quellcode des Kernels und muss diesen entsprechend modden um sowas zu erreichen. Ist also deiner Meinung ein leichtes?

Naja, wenn ich einen Artikel über 17 Seiten schreibe und dafür eigens 4 Tools programmiere, wäre der Aufwand dafür doch noch im Rahmen gewesen? Es sei denn natürlich, das Ergebnis hieraus gefährdet das gewünschte Ergebnis meines Artikels.

Hört sich ziemlich wirr an was du da schreibst. In dem Artikel gings nicht um theoretische Werte, sondern einfach um die, in der Einleitung aufgeführte Frage, "how sense [multicore] designs make in real-world usages". Hab bislang keinen Artikel gefunden, wo dies mal derart akribisch und eben nicht anhand von synthetischen Benchmarks betrachtet wurde.

Inwiefern wirr? Mir gehts, wir mehrmals geschrieben, um die Verlustleistung die durch Parallelisierung entsteht und darauf geht der Autor einfach nicht ein, was, für mich, den Artikel halb-fertig erscheinen lässt. Denn wie sagt man so schön, es gibt immer zwei Seiten der Geschichte.

Und was ich meine ist lediglich den Faktorwert der Kerne auszurechnen, nicht mehr und nicht weniger.

Einen Kern (je einmal Big und einmal Little) voll auslasten. Werte aufschreiben - mit 4 multiplizieren. Anschließend alle 4 Kerne auslasten, Werte aufschreiben und den praktischen im Vergleich zum theoretischen Output setzen.

Dann könnte man noch die Werte 4x Big + 4x Little (theoretische Leistung addieren) und in Relation zum wirklichen Output setzen, wenn alle 8 Kerne busy sind.

Dann hat man die Faktorwerte und auch den Parallelliserungsverlust (wasn Wort). Nur sollte man das auch Anhand von anderen Apps als Benchmarks testen, da Benchmarks hier aus besagten Gründen noch besser abschneiden als es in der Realität (wir haben da im Deutschen ein schönes Wort für Real-World) der Fall ist.

Dann, und nur dann, kann ich eine fundierte Aussage der Effizienz der Big.Little Architektur hinsichtlich der Output-Perfomance tätigen.