Warum ist Apples M1-Chip so schnell?
(erik-engheim.medium.com)- Der M1 ist keine einzelne CPU, sondern ein komplettes System, bei dem mehrere Chips in ein großes Silizium-Package integriert sind. Die CPU ist nur einer davon.
→ Ein SoC (System on a Chip), das CPU, GPU, Speicher, I/O-Controller usw. zusammenfasst
- Statt viele universelle Kerne einzubauen, werden Chips integriert, die auf bestimmte Aufgaben spezialisiert sind
→ CPU: Führt das Betriebssystem und Apps aus
→ GPU: Führt Grafikaufgaben aus, etwa die UI von Apps oder 2D/3D-Spiele
→ ISP (Image Processing Unit): Erhöht die Geschwindigkeit der Bildverarbeitung
→ DSP (Digital Signal Processor): Führt mathematisch intensivere Aufgaben als die CPU aus, zum Beispiel das Dekomprimieren von Musikdateien
→ NPU (Neural Processing Unit): Beschleunigt Machine Learning, Spracherkennung, Kameraverarbeitung usw.
→ Video Encoder/Decoder: Verarbeitet Videodateien/-formate mit geringem Stromverbrauch
→ Secure Enclave: Verschlüsselung, Authentifizierung, Sicherheit
→ UMA (Unified Memory Architecture): CPU, GPU und andere Kerne können Informationen schnell austauschen
Deshalb sind solche Chips bei Bild-/Videobearbeitung und beim Encodieren großer Videos so leistungsstark.
- Was ist an der Unified Memory Architecture (UMA) so besonders?
→ Frühere integrierte CPU/GPU-Chips waren langsam
Beide nutzten unterschiedliche Speicherbereiche auf unterschiedliche Weise.
Außerdem erzeugen GPUs viel Wärme, daher liefern große Karten mit großen Lüftern die höchste Leistung.
Dann müssen aber viele Daten zwischen beiden kopiert werden, weshalb ein Bus wie PCIe nötig ist.
→ Unified Memory reserviert den Speicher nicht getrennt für CPU und GPU, sondern beide nutzen ihn gemeinsam.
Anders als bei Shared Memory können CPU und GPU gleichzeitig darauf zugreifen; durch den Austausch von Positionsinformationen ist kein Kopieren mehr nötig.
- Wenn dieser SoC-Ansatz so gut ist, warum machen andere Hersteller das nicht?
→ Tun sie bereits. AMD begann mit APU-Formen, bei denen CPU und GPU auf demselben Silizium-Die sitzen.
→ In der Praxis ist es aber schwierig. Ein SoC bedeutet, den gesamten Computer auf einen Chip zu bringen, und passt deshalb besser zu Computerherstellern wie HP oder Dell.
→ Das Geschäftsmodell von Intel und AMD basiert auf universellen CPUs, die Nutzer in PC-Mainboards stecken.
Beim neuen SoC-Markt werden nicht physische Produkte verschiedener Anbieter zusammengesetzt, sondern IP (Intellectual Property).
→ Können Intel, AMD und Nvidia Dell oder HP wirklich IP lizenzieren?
→ Natürlich könnten Intel und AMD fertige SoCs verkaufen, aber dabei sind Interessenkonflikte zwischen CPU-Herstellern, PC-Herstellern und Microsoft möglich, etwa bei der Frage, was integriert werden soll.
→ Für Apple ist das dagegen einfach. Sie machen alles selbst. "They control the whole widget"
- Die grundlegendste Herausforderung beim Bau schneller CPUs
→ Der schnelle universelle CPU-Kern des M1, Firestorm, ist wirklich schnell. Genau das unterscheidet ihn von früheren ARM-Chips, die im Vergleich zu AMD/Intel langsamer waren.
→ Firestorm schlägt die meisten Intel-/AMD-Ryzen-Kerne in der Geschwindigkeit, was dem gesunden Menschenverstand nach eigentlich nicht passieren dürfte.
→ Welche Strategien gibt es, um eine schnelle CPU zu bauen?
-
Befehle nacheinander schneller ausführen
-
Mehrere Befehle parallel ausführen
In den 80ern war das einfach. Man musste nur die Taktfrequenz erhöhen, dann wurden Befehle schneller ausgeführt.
Computer tun in jedem Taktzyklus etwas, und dieses "etwas" ist sehr klein, sodass ein einzelner Befehl mehrere Taktzyklen benötigen kann.
Heute gibt es beim Erhöhen der Taktfrequenz jedoch Grenzen.
"Das Ende von Moores Gesetz"
Deshalb ist es heute wichtig, möglichst viele Befehle parallel auszuführen.
- Multi-core oder Out-of-Order-Prozessoren?
→ Für parallele Ausführung gibt es zwei Ansätze
- Mehr CPU-Kerne einbauen (aus Sicht der Entwickler: mehr Threads hinzufügen)
Theoretisch kann ein Prozessorkern mehrere Threads ausführen (Software-Threads).
Dabei wird zwischen den Threads umgeschaltet; sinnvoll ist das vor allem, wenn auf I/O oder Netzwerk gewartet werden muss.
Hardware-Threads machen die Ausführung schneller, aber Entwickler müssen Code schreiben, der das nutzt.
Für Server/Cloud ist dieses Modell geeignet.
Deshalb baut etwa Ampere ARM-CPUs für die Cloud wie den Altra Max mit 128 Kernen.
Apple ist genau das Gegenteil. Apple baut Geräte für einzelne Nutzer.
Die meiste Desktop-Software ist nicht darauf ausgelegt, viele Kerne zu nutzen.
Bei Spielen kann es bei 8 Kernen Leistungsgewinne geben, aber 128 Kerne wären reine Verschwendung.
Deshalb braucht man weniger, dafür leistungsstärkere Kerne.
- Out-of-Order-Ausführung (OoO) führt mehr Befehle parallel aus, ohne dass man sie wie bei Multithreading explizit nutzen muss.
Aus Sicht von Entwicklern wirkt es einfach so, als liefen die einzelnen Kerne schneller.
Daten aus einer bestimmten Speicheradresse zu holen ist langsam.
Ob man aber 1 Byte oder 128 Byte holt, macht bei der Verzögerung keinen Unterschied.
Daten bewegen sich über einen Datenbus; ist dieser Bus breit, können mehrere Bytes gleichzeitig gelesen werden.
Beim Ausführen verarbeitet die CPU mehrere Befehlsblöcke auf einmal, obwohl diese Befehle so geschrieben sind, dass sie der Reihe nach ausgeführt werden.
Moderne Mikroprozessoren führen Out-of-Order aus.
Sie analysieren also mehrere Befehle und prüfen, ob zwischen ihnen Abhängigkeiten bestehen.
01: mul r1, r2, r3 // r1 ← r2 × r3
02: add r4, r1, 5 // r4 ← r1 + 5
03: add r6, r2, 1 // r6 ← r2 + 1
In den obigen Befehlen haben 1 und 2 eine Abhängigkeit, aber Befehl 3 hat mit den vorherigen nichts zu tun.
Dann kann ein Out-of-Order-Prozessor den dritten Befehl parallel ausführen, weil keine Abhängigkeit besteht.
In der Praxis kann eine CPU Abhängigkeiten nicht nur zwischen ein oder zwei, sondern zwischen Hunderten von Befehlen erkennen.
Die CPU verbindet Befehle zu einem Knotengraphen und analysiert ihn, um festzustellen, welche Befehle parallel ausgeführt werden können und an welchen Stellen vor der Ausführung auf Ergebnisse gewartet werden muss.
Dass der Firestorm-Kern des M1 so enorme Geschwindigkeit erreicht, liegt daran, dass er eine sehr starke Out-of-Order-Ausführung besitzt.
Sie scheint besser zu sein als bei allen anderen im Mainstream-Markt, einschließlich Intel und AMD.
- Warum ist die Out-of-Order-Ausführung von AMD und Intel langsamer als die des M1?
→ Wovon oben die Rede war, heißt in Wirklichkeit ROB (Reorder Buffer) und ist kein gewöhnlicher Maschinenbefehlscode, den die CPU aus dem Speicher holt.
Diese Befehle gehören zur CPU Instruction Set Architecture (ISA), also zu dem, was wir x86, ARM oder PowerPC nennen.
→ Intern arbeitet die CPU mit einem völlig anderen Befehlssatz, den der Programmierer nicht sieht: micro-operations (Mikrobefehle, micro-ops oder μops). Mit diesen μops ist der ROB gefüllt.
→ Man kann sich ARM-/x86-Befehle als öffentliche API vorstellen und micro-ops als private API.
→ Bei CISC sind Befehle groß und komplex, daher braucht man micro-ops zwingend; bei RISC kann man sich dafür oder dagegen entscheiden.
(Zum Beispiel brauchen kleine ARM-CPUs keine micro-ops. Das bedeutet nicht, dass sie kein OoO können.)
→ Warum ist das wichtig? Weil für hohe Geschwindigkeit entscheidend ist, wie schnell und wie voll man den ROB machen kann.
→ Je schneller man ihn füllt, desto mehr Möglichkeiten gibt es, mehr Befehle parallel auszuführen, was die Leistung verbessert.
→ Maschinenbefehle werden vom Decoder in micro-ops zerlegt.
→ Intel-/AMD-Kerne haben 4 Decoder.
Apple hat dagegen wahnsinnige 8 Decoder, und sein ROB ist dreimal so groß, sodass er grundsätzlich dreimal so viele Befehle aufnehmen kann.
- Warum bauen Intel und AMD dann nicht einfach mehr Befehlsdecoder ein?
→ Hier beginnt der Gegenangriff von RISC. Entscheidend ist, dass im Firestorm-Kern des M1 ARM-RISC steckt.
→ x86-Befehle sind 1 bis 15 Byte lang, RISC-Befehle haben dagegen eine feste Größe.
→ Wenn alle Befehle gleich lang sind, kann man sie einfach abschneiden und an 8 verschiedene Decoder verteilen.
→ Bei x86 weiß man aber nicht, wann nach einem Befehl der nächste beginnt, daher bleibt nichts anderes übrig, als jeden Befehl tatsächlich zu analysieren.
→ Intel und AMD lösen dieses Problem mit brute force, indem sie an jedem potenziellen Befehlsanfang decodieren.
Das heißt, falsche Vermutungen oder Fehler müssen ständig verworfen werden.
Deshalb ist es schwierig, mehr Decoder hinzuzufügen, während es für Apple sehr leicht ist.
→ Das ermöglicht es grundsätzlich, bei gleicher Taktfrequenz doppelt so viele Befehle wie eine AMD-/Intel-CPU zu verarbeiten.
→ In der Praxis nutzt x86 die komplexen CISC-Befehle zwar selten und eher kurze, RISC-ähnliche Befehle, aber die 15-Byte-Befehle müssen trotzdem verarbeitet werden, daher bleibt die Komplexität bestehen.
- Aber der Zen3-Kern von AMD ist doch immer noch schneller, oder?
→ In Benchmarks ist Zen3 tatsächlich schneller als Firestorm, aber Zen3 läuft mit 5 GHz und Firestorm mit 3,2 GHz.
→ Apple erhöht die Taktfrequenz nicht weiter, weil der Chip sonst zu heiß würde.
→ Grundsätzlich ist der Firestorm-Kern Zen3 überlegen.
→ Zen3 kann für Spiele eingesetzt werden, verbraucht dabei aber mehr Strom und erzeugt mehr Wärme; "Apple hat sich einfach dagegen entschieden"
→ Wenn Apple mehr Leistung will, wird das Unternehmen mehr Kerne hinzufügen. So lässt sich mehr Leistung bei geringerem Stromverbrauch erzielen.
- Zukunft
→ AMD und Intel haben sich in zwei Punkten selbst in die Ecke gedrängt
-
Es gibt kein Geschäftsmodell, das heterogenes Computing und SoC-Design vorantreibt.
-
Komplexe x86-CISC-Befehle sind zu Legacy geworden und erschweren Verbesserungen bei der OoO-Leistung.
→ Natürlich ist das noch nicht Game Over. Man kann den Takt weiter erhöhen, stärker kühlen, mehr Kerne einsetzen usw.
→ Für Intel sieht es noch schlechter aus. Firestorm ist bei der Kerngeschwindigkeit bereits vorne, und die in Intels SoCs integrierte GPU ist schwach.
→ Viele Kerne sind natürlich gut für Server, aber Amazon und Ampere greifen mit 128 Kernen an. Intel und AMD müssen also an beiden Fronten kämpfen.
→ Zum Glück verkauft Apple seine Chips im Gegensatz zu AMD/Intel nicht auf dem Markt.
→ Noch ist es nicht so weit, aber PC-Nutzer werden langsam zu Apple wechseln, und Apple wird im PC-Markt einen größeren Anteil gewinnen.
17 Kommentare
Du schreibst wirklich sehr gut.
Vielen Dank, dass Sie das so verständlich und übersichtlich aufbereitet haben. Einfach großartig!
Vielen Dank für den guten Beitrag.
Vielen Dank!!
Ich wollte mir eigentlich ein M1-Gerät kaufen, aber stattdessen hätte ich wohl Aktien kaufen sollen..
Vielen Dank für den tollen Artikel!
Ich bin ebenfalls der Meinung, dass die Apple-Aktie ein hohes Zukunftspotenzial hat.
Irgendwann wird wohl wirklich ein Apple Car herauskommen.
Das Weak Memory Model wird offenbar immer wichtiger … Apple wird jetzt wirklich zu einem geschlossenen Unternehmen, das von den Chips über die Montage und Hardware bis hin zu OS und Apps alles selbst machen kann – ganz so, wie Jobs es sich erträumt hatte.
Ich denke auch darüber nach, mein nächstes Gerät als M1 Mac mini oder MacBook Air zu kaufen …
Ich wechsle auch von einem MacBook Pro von 2015 zum M1 … Es heißt, dass es Ende des Jahres oder Anfang nächsten Jahres kommt!
Wie ich heute gesehen habe, ist es in Korea bereits erschienen!
Wow! Guru, du bist wirklich der Beste!!
Vielen Dank ;)
In dem Artikel gibt es auch einen Vergleich zwischen RISC und CISC, den der Autor geschrieben hat, und den kann ich wirklich nur wärmstens empfehlen. Er erklärt ganz locker und verständlich, warum man überhaupt zu solchen Befehlsarchitekturen gekommen ist.
Ich glaube, die Person kann grundsätzlich sehr gut schreiben. Auch dieser Text ist ziemlich lang, liest sich aber sehr gut.
Wow, vielen Dank für den tollen Inhalt.
Vielen Dank!
Es fühlt sich an, als würde ich noch einmal einen Kurs über Computerarchitektur belegen, haha.
Letztlich ist Apple einfach so aufgestellt, dass das Unternehmen nur immer besser in dem werden kann, was es ohnehin am besten kann.
Was machen Intel und AMD jetzt nur..
In der heute veröffentlichten 16. Folge des GeekNews-Podcasts wurde der Memory-Order-Trick des M1-Chips kurz vorgestellt, aber dieser Artikel geht noch einmal ganz anders und deutlich detaillierter darauf ein.
Wahrscheinlich werden wir auch im Podcast nächste Woche wieder darüber sprechen ^^;