Schwerpunkte

Arm-SoC mit höchster Rechenleistung

Apples M1-SoC demütigt komplette x86-Konkurrenz

11. November 2020, 15:17 Uhr   |  Frank Riemenschneider

Apples M1-SoC demütigt komplette x86-Konkurrenz
© Apple

Nachdem Apple die ersten Notebooks mit eigenentwickelten Arm-basierten CPUs vorgestellt hat, wird der vermeintliche „Wunderprozessor“ M1 lebhaft diskutiert. Tatsächlich geht mit dem M1 die dekadenlange Performance-Führerschaft der x86-CPUs vermutlich dauerhaft zu Ende. Wie wurde dies möglich?

Stand die Arm-Architektur generell für Energieeffizienz, wurde in den x86-Prozessoren von Intel und AMD das Non-Plus-Ultra bezüglich der Rechenleistung gesehen. Tatsächlich gibt es bis heute kein SoC-Design auf Basis von Arm Cortex-Cores, welches zumindest den High-End-x86-CPUs hier das Wasser reichen kann.

Die CPUs auf Apples neuem M1-SoC, das in den zukünftigen 13-Zoll-MacBooks seinen Dienst verrichten wird, ist eine Eigenentwicklung mit Hilfe einer Arm-Architekturlizenz, d.h. die Armv8-Mikroarchitektur ist die Basis, die CPUs sind jedoch von Apple selbst designt worden und unterscheiden sich von Arms eigenen lizensierbarer Cortex-IP signifikant. So schockierend die präsentierten Performance-Zahlen und Akkulaufzeiten für den x86-Wettbewerb auch sein mögen, es ist nicht das erste Mal, dass Apple eine ratlose Konkurrenz zurücklässt. Man erinnere sich nur an die Cyclone-CPU-Mikroarchitektur, die Apple 2013 auf seinem A7-SoC einführte. Es war das erste SoC auf Basis der 64-Bit-Armv8-Architektur, während die restliche Smartphone-Welt auf 32 bit setzte. Selbst Arm selbst brauchte ein Jahr länger, bis mit dem Cortex-A57 Arms erstes eigenes 64-Bit-Design vorgestellt werden konnte.

Während der MacBook-Präsentation wurde eine Folie mit einem echten Foto des Silizium-Chips des M1 gezeigt, was für Apple eher ungewöhnlich ist (Bild 1). Man erkennt als erstes das Packaging mit embedded DRAM anstelle des üblichen Package-on-Package, was den Vorteil hat, dass das DRAM seitlich vom SoC sitzt und die Chips damit besser gekühlt werden können. Der Chip selbst beinhaltet laut Apple 16 Mrd. Transistoren, deutlich mehr als z.B. AMDs Ryzen 3900X, der auf “nur” knapp 10 Mrd. Transistoren kommt.

Apple M1
© Apple

Bild 1: Der M1-Chip ist neben dem DRAM platziert, was zu einer besseren Wäremabfuhr führt.

Die bereits im iPhone 12 eindesignten High-Performance-CPUs „Firestorm“ sind statt in zweifacher beim M1 in vierfacher Ausführung vorhanden (Bild 2), der L2-Cache wuchs vom A14 von 8 auf 12 MB. Der L1-Cache beträgt riesige 192 KB, dazu später mehr. Die vier Energieeffizienz-CPUs „Icestorm“ befinden wie auch die jetzt 16 Cores umfassende NPU in der Nähe des System-Level-Caches oder L3-Cache, der von allen IP-Blöcken gemeinsam genutzt wird. Wie üblich bei derartigen SoCs wird ein großer Teil der Chip-Fläche von der GPU belegt, die vom M1 hat 8 Cores bzw. in einer minimalistischen Ausführung beim MacBook Air 7 Cores.

Was sofort ins Auge sticht, ist die Tatsache, dass nur ein vergleichsweise geringer Teil des SoCs von CPUs, GPU, NPU und Caches belegt wird, was daran liegt, dass die Funktionalität mehrerer diskreter Chips wie z.B. E/A- oder SSD-Controller auf den M1 integriert wurden.

Apple M1
© Apple/Elektronik

Bild 2: Die Cluster von CPUs, GPU, NPU und L3-Cache belegen nur etwas mehr als die Hälfte des M1-Chips, da zuvor diskrete Blöcke wie SSD-Controller auf das SoC integriert wurden.

Bild 3 sollte in groben Zügen die Mikroarchitektur der „Firestorm“-CPUs abbilden, soweit sie auf einem iPhone 12 Pro mit im Internet z.B. auf Github erhältlichen und selbstentwickelten Routinen evaluiert werden konnte. Apple selbst gibt bekanntlich überhaupt keine Informationen heraus, so dass viele Details im Dunkeln bleiben.

Einiges spricht dafür – gesichert ist es aber nicht - dass Apple im Frontend ein Arm’s predict-directed fetch genannten Verfahren, bei der Sprungvorhersage Daten direkt in die Befehlsabrufeinheit einzuspeisen, implementiert hat. Dies ist ein Ansatz, der einen höheren Datendurchsatz sowie eine geringere Stromaufnahme zur Folge hat.
Die Sprungvorhersage setzt dabei einen hybriden indirekten Prädiktor ein. Der Prädiktor ist von der Fetch-Einheit entkoppelt und seine wichtigsten Strukturen arbeiten unabhängig vom Rest der CPU.

Fest steht, dass Apples Sprungvorhersage offenbar erfolgreich vermutlich durch ein früheres Prefetching bei L1-Cache-Misses die gefürchteten Bubbles (=Pipeline-Stalls) bei angesprungenen Verzweigungen im Fall der Annahme, dass nicht verzweigt wird, verhindern kann. Daraus kann man schließen, dass die Bandbreite der Sprungvorhersage hinreichend groß ist, damit der Prefetcher möglichst viele  Instruktionen pro Taktzyklus holen kann. Wie groß genau, weiß allerdings nur Apple selbst.

Anzunehmen ist auch, dass die Firestorm-CPU eine Art Macro-Op-Cache (Mop) implementiert, einen Befehls-Cache für dekodierte Instruktionen, die sogenannten Macro-Ops, der an ähnliche Implementierungen in Intels und AMDs x86-CPUs erinnert. Im Fall eines Cache-Hits wird die Rename-Stufe in der Pipeline direkt aus dem Mop gefüttert, er ist somit quasi ein L0-Cache. Die Latenzzeit im Fall einer Sprungfehlvorhersage wird damit weiter reduziert. Wie groß ein solcher L0-Cache ist, kann ohne Apples Angaben hierzu nicht verifiziert werden.

Was allerdings feststeht ist, dass Firestorm mit einer Dekodiereinheit, die 8 Instruktionen parallel verarbeiten kann, das breiteste Design überhaupt aufweist. Zum Vergleich: Die x86-CPUs von AMD (Zen 3) und Intel arbeiten mit 4-fach-Dekodern (vermutlich auch wegen der varibalen Befehls-Länge im x86-Befehlssatz im Gegensatz zu Arms Befehlssatz mit Instruktionen fester Länge, was die Sache komplexer macht), gleiches gilt für Arms Cortex-A-CPUs, wobei der High-Performance-Core Cortex-X1 einen 5-fach-Dekoder beinhaltet. Es gibt aber noch kein reales Silizium mit Cortex-X1 auf dem Markt.

Gigantisch waren schon immer die Reorder-Puffer der Apple-CPU-Designs, womit entsprechend große Out-of-Order-Befehlsausführungsfenster möglich werden. Der Puffer dient als Mittel zur Herstellung der korrekten Berechnungsreihenfolge. Aktive Instruktionen sind zur Ausführung freigegeben (dispatched) oder bereits ausgeführt, jedoch noch nicht in ihrem Wert validiert (committed). Dieser Pufferspeicher ist logisch als FIFO-Speicher, in Hardware als Ringspeicher mit Kopf- und Endzeiger implementiert. Jede Instruktion landet in einem Eintrag am Ende des Speichers, sobald sie zur Ausführung ansteht. Je größer der Puffer ist, desto mehr Befehle können dort auf die Ausführung innerhalb einer Out-of-Order-Sequenz warten.

Übliche öffentlich bekannte Größen sind z.B. 224 Einträge beim Cortex-X1, 256 Einträge bei AMDs Zen-3- und 352 bei Intels neuesten 10-nm-Willow-Cove-CPUs. Bei der „Firestorm“-CPU sprechen wir laut einem auf Github gefundenen Analysetool von über 600 Einträgen, was eine unschlagbare Parallelität der Befehlsausführung ermöglicht. Wie Apple dies hinkriegt? Nicht nur ich wüsste es wohl nur zu gerne.

Apple M1
© Elektronik

Bild 3: Grobe Darstellung der "Firestorm"-CPU-Mikroarchitektur. Da von Apple keine Informationen zugeliefert werden, ist die Abbildung mit einigen Unsicherheiten verbunden.

Große Parallelisierung im Backend

Wenn derartig viele Instruktionen ausgeführt werden können, müssen natürlich auch entsprechend viele Ausführungseinheiten im Backend bereitstehen. Schon auf der Integer-Seite befinden sich 4 ALUs, die einfache arithmetische Operationen wie Addition, Logik-Operationen, Test/Compare-Operationen oder Verschiebeoperationen ausführen können, 2 weitere Einheiten, die zusätzlich auch noch multiplizieren können und eine Integer-Divisionseinheit. Eine achte und vermutlich auch neunte Einheit dienen dem Handling von Verzweigungen. Von diesem Typ weist Arms Cortex-X1 übrigens ebenfalls zwei Einheiten auf, das ist also prinzipell keine neue Erfindung.

Auf der Vektor- und Gleitkommaseite im Backend finden sich vier 128-Bit-NEON-Pipelines, welche vier Gleitkomma-Additionen und -Multiplikationen pro Taktzyklus ausführen können. Dies ist doppelt soviel bei AMD Zen-3 und sogar viermal so viel wie bei Intel. Allerdings sind Arms NEON-Vektor-Operationen mit 128 bit nur halb so lang wie bei den 256-bit-AVX-Operationen der x86-CPUs. Die Vektorfähigkeiten der 4 Pipelines weitstegehend identisch, wobei ähnlich wie z.B. bei Arms Cortex-A78 offenbar nur eine Pipeline auch Gleitkomma-Divisionen ausführen kann.

Riesige Caches

Das Laden und Speichern von Daten wird über 4 Einheiten abgewickelt, von denen allerdings nur eine Laden und Speichern kann. Eine weitere kann nur Speichern und zwei nur Laden. Damit können pro Taktzyklus maximal 3 Lade- und 2 Speicheroperationen abgewickelt werden.

Der L1-TLB nimmt 256 Pages ein und der L2-TLB sogar 3072 Pages. Beim Cortex-A78 gibt es zum Vergleich beim L2-TLB gerade mal 1024 Pages. Warum ist dies relevant?

Der Translation Lookaside Buffer (TLB) kann bei Verwendung von virtuellem Speicher zu erheblichen Geschwindigkeitsvorteilen führen. Wenn virtueller Speicher verwendet wird, muss zu den virtuellen Adressen die jeweils zugehörige physische Adresse ermittelt werden. Dabei wird die virtuelle oder logische Adresse in meist drei Arbeitsschritten mit Hilfe der Segment- und der meist baumartig organisierten Page-Tabelle zur physischen Adresse umgesetzt. Da dies zeitintensiv ist, werden die zuletzt ermittelten Werte für die Adresse der physischen Speicherseite im TLB zwischengespeichert, wodurch erneute Zugriffe auf Adressen in dieser Seite nicht aufwändig neu ermittelt werden müssen, sondern aus dieser Liste entnommen werden können.

Die meisten CPUs verzichten aus Kostengründen auf allzu große TLBs, zumal in vielen Anwendungsfällen eine kleine Anzahl an Pages aufgrund der räumlichen Lokalität ausreicht. Die räumliche Lokalität beschreibt das Phänomen, dass Programme bei aufeinander folgenden Speicherzugriffen auf Adressen zugreifen, die nah beieinander liegen. Da eine Page aus mehreren aufeinander folgenden Speicheradressen besteht, wird auf eine Page öfter hintereinander zugegriffen, so dass auch der zugehörige TLB-Eintrag oft hintereinander benutzt wird. Offenbar hat Apple jedoch ermittelt, dass dies in der Realität nicht immer der Fall ist und die Größe der TLBs entsprechend angepasst – die 5-nm-Fertigung war hier natürlich auch hilfreich, Siliziumfläche zu sparen.

Die L1-Caches waren bei Apple eigenen Designs schon immer exorbitant groß. Alleine der 192 KB große Befehlscache ist 3x größer als bei Cortex-A-CPUs. Die x86-CPUs weisen sogar nur 32 KB oder 48 KB auf. Der 12 MB große L2-Cache wird von allen 4 Firestorm-CPUs geteilt, der geteilte16-MB-L3-Cache steht dann allen IP-Blöcken zur Verfügung und wurde folgerichtig von Apple zentral auf dem Chip zwischen CPUs, GPU und NPU angeordnet.

Bei den “Icestorm”-Energieeffizienz-Cores stehen 128 KB-L1-Befehlscache, 64 KB-L1-Datencache und ein geteilter 4 MB großer L2-Cache zu Buche.

Energieeffizenz UND Performance

Mit laut einer Apple-Slide von 17,5 – 18 W TDP (Bild 4 zeigt wie dieser Wert ermittelt wurde, durch die limitierte Genauigkeit der Grafik auf der Slide kann der Wert nicht auf 1 mW genau abgelesen werden) liegt der M1 seitens der Leistungsaufnahme um Welten unterhalb der x86-Konkurrenz: Die einzige CPU, die ihn im Single-Thread-Modus im Benchmark GeekBench5 überhaupt noch mit minimalem Abstand schlägt, ist AMDs neuester Ryzen 9 5950X. Dieser ist aber gewiss kein Prozessor für Mobilgeräte sondern wird im Gaming-Desktop-PCs verbaut.

Apple M1
© Apple/Elektronik

Bild 4: Berechnung der TDP des Apple-M1 auf Basis einer Slide von Apple. Die gelben Informationen stammen von der Elektronik.

Hierbei gilt, dass Apple seine beim GeekBench 5 im Single-Thread-Modus aufgenommenen 5 W einschließlich SoC, DRAM und Schaltreglern erzielt, während AMDs CPU bei diesem Workload auf rund 50 W kommt (incl. dem zentralen I/O-Chip IOD im Package, der neben dem DRAM-Controller für die Chiplet-zu-Chiplet-Kommunikation und PCIe-Schnittstellen zuständig ist) und zwar ohne DRAM und Schaltregler. Da beim Messen ja nur ein Core aktiv ist, dürften sich die beim iPhone 12 erzielten Werte kaum von denen des M1 unterscheiden und ob es dann beim M1 vielleicht doch 5,1 W oder vielleicht sogar 5,2 W sein werden, macht ja in der Vergleichsbetrachtung zu den x86-Prozessoren auch keinen Unterschied mehr aus.

Was allerdings aus Sicht der x86-Konkurrenz besonders bedenklich erscheinen muss, ist der in der Historie erstmalige Verlust der Marktführerschaft bei der Rechenleistung gegen eine Armv8-CPU.

JahrIntel-CPUGeekBench 5
Score ST
Apple-Ax-CPU

GeekBench 5
Score ST

Rückstand/Vorsprung
Apple vs. Intel in %
Q2/2015Core i7-5775C1057A9558- 47,2 %
 Core i7-6700K1151A10776- 32,6 %
bisCore i7-7700K1229A11932- 24,2 %
 Core i7-9900K1342A121118- 16,7 %
 Core i7-10900K1417A131334- 5,8 %
Q3/2020Core i7-1185G71578M1/A14
(3,2/3,0 GHz)
1732/1634+ 9,8 %/+3,5 %

 

Die obige Tabelle zeigt die Entwicklung der Scores des GeekBench 5 im Single-Thread-Modus in den letzten 5 Jahren. Apple ging seinerzeit mit dem Dual-Core-Apple-A9 an den Start, dessen CPU auf einen Benchmark-Wert von 558 kam – fast die Hälfte von Intels Core-i7 5775C, der auf 1057 Punkte kam. Seitdem brachten sowohl Intel als auch Apple neue Modelle an den Start, und natürlich wuchs die Rechenleistung in beiden Fällen von Generation zu Generation. Die Werte haben wir für eine Firestorm-CPU ermittelt, die im M1 mit 3,2 GHz getaktet wird, also mit 200 MHz mehr als im A14-SoC im neuen iPhone 12. Diese Taktfrequenz bezieht sich auf den lüfterlosen Einsatz im MacBook Air, für den MacBook Pro darf man noch höhere Taktfrequenzen erwarten, die aber noch nicht bekannt sind. Zum Vergleich ist auch der Wert im iPhone 12 angegeben.

Intel konnte in 5 Jahren und über 5 Generationen seine beste Single-Thread-Rechenleistung laut GeekBench 5 um 33 % steigern, während Apple diese bei 3,2 GHz Notebook-Taktfrequenz um 210 % steigerte – also mehr als verdreifachte. Diese Aussage gilt übrigens auch für den SPECint-Benchmark, wobei der einzige Unterschied zwischen SPEC und GeekBench5 darin besteht, dass GeekBench weniger speicherlastig ist, d.h. es wird eher die reine CPU gemessen, während SPEC eher CPU und DRAM gemeinsam adressiert. Hier konnte Intel in 5 Jahren um knapp 30 % und Apple um 220 % zulegen, d.h. dank seiner DRAM-Anbindung mit 128-bit-Speicherbus zur CPU schneidet Apple hier im Vergleich sogar noch besser ab als beim Geekbench.

Der Vollständigkeit halber sei erwähnt, dass der M1 auch im Multicore-Betrieb Intels schnellste CPU schlägt und zwar noch deutlicher als im Single-Thread-Modus: Er kommt auch 7545 Geekbench5-Punkte, während der Core i7-1185G7 nur auf 6113 Punkte kommt. Apple ist hier also sogar 23 % schneller, was daran liegt, dass der M1 seine maximale Taktfrequenz auch bei Auslastung aller Cores fast unverändert halten kann, während dies bei der Intel-CPU aus thermischen Gründen nicht möglich ist.

Ein Vergleich mit AMDs Zen-3-CPU im Multicore-Betrieb des Ryzen 5950X stellen wir nicht an, da dieser 16-Core-Chip mit einer TDP von 142 W natürlich überhaupt nicht für den Einsatz in einem Notebook ausgelegt ist. Geeignet wäre hier z.B. ein akteuller Ryzen 7 Pro 4750U, der allerdings noch mit der Vorgänger-Mikroarchitektur Zen 2 leben muss und beim Geekbench5 nur auf 1162 (Single-Thread) bzw. 6509 (Multi-Thread) Punkte kommt.

Im Ergebnis hat Apple mit der M1-CPU erstmals Intel – und abgesehen von einer einzigen Desktop-PC-Gaming-CPU auch AMD -  überholt und zwar unabhängig vom eingesetzten Benchmark. Die für den Vergleich herangezogenen Intel-CPUs lieferten übrigens jeweils zu ihrer Zeit die höchste Single-Thread-Rechenleistung aller Intel-Prozessoren und wurden aus diesem Grund von uns ausgewählt. Apples bei der Macbook-Präsentation aufgelegte Slide (Bild 4), auf welcher bei einem Betriebspunkt von 10 W eine um 200 % höhere Rechenleistung des M1 gegenüber der Intel-Konkurrenz behauptet wird, kann man übrigens getrost vergessen: Hier wird der kleinste in Macbooks verbaute Intel-Prozessor zum Vergleich herangezogen, ein Core-i3. Das ist natürlich sehr unfair.

Für die Beantwortung der Frage, wie diese Werte bei der “Firestorm”-CPU möglich wurden, gibt es insbesondere zwei Punkte zu erwähnen: Als erstes das extrem breite Frontend mit 8 Befehls-Dekodern und einer massiven Parallelisierung der Befehlsausführung. Allgemein geht man davon aus, dass derart breite Designs mit dem Wunsch nach höheren Taktfrequenzen kollidieren. Der M1 kann jedoch seine maximale Taktfrequenz jenseits der 3 GHz sogar im Multithreading-Betrieb halten. Wie Apple das hinbekommen hat? Gute Frage. Als zweites stellt sich die Frage nach den riesigen Cache-Strukturen. Hier müsste man eigentlich mit erheblichen Latenzzeiten rechnen, tatsächlich ist das Gegenteil der Fall: Der L2-Daten-Cache des M1 weist eine um 25 % bzw. sogar 40 % geringere Latenzzeit als die neuesten CPUs von AMD und Intel auf. Wie Apple das hinbekommen hat? Auch dies ist eine gute Frage, die wohl nur Chip-Entwicklungschef Johny Srourji beantworten könnte.

Eine spannende Frage ist sicher auch die, warum andere Firmen mit Arm-Entwicklerlizenz wie Samsung oder Huawei mit ihren Eigenentwicklungen nicht mit Apple Schritt halten können und eine vielleicht noch spannendere Frage, warum Arm selbst mit seiner aktuellen Cortex-IP so weit von Apple entfernt ist, sowohl was die absolute Rechenleistung als auch was die Energieeffizienz (Rechenleistung/W) angeht. Selbst ein zukünftiger Cortex-X1 wird nur bei extrem hohen Taktfrequenzen weit jenseits der 3 GHz mit Firestorm mithalten können.

Wenn Apple weiterhin jedes Jahr in diesem Tempo an Rechenleistung zulegt, wird es für die x86-Anbieter nicht nur unmöglich sein, zu der Energieeffizienz von Apples SoCs aufzuschließen (dies kann man als gesichert ansehen), sondern vielleicht auch nie wieder die Spitze der CPU-Rechenleistung erklimmen. Dass eine Armv8-CPU dies einmal würde erreichen können, habe ich noch vor wenigen Jahren als ausgeschlossen angesehen. Aber wie heißt es so schön: Man lernt nie aus.

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Verwandte Artikel

Apple GmbH