Apple Silicon im Test: Was der M1-Chip (nicht) kann
Es kam, was kommen musste: Nachdem Apple bereits seit zehn Jahren die Systems-on-a-Chip für die iPads und iPhones eigens entwickelt hatte, folgt mit dem M1 das erste Apple Silicon für Mac-Systeme. Das aktuelle Macbook Air (Test)(öffnet im neuen Fenster) halten wir für eines besten Notebooks - denn es ist schnell, lautlos und läuft äußerst lange. Grund genug, sich den M1-Chip näher anzuschauen.
Selbst entworfene Systems-on-a-Chip sind nicht neu für Apple, denn beginnend mit dem A6 von 2012 hat Apple auf Basis einer ARM-Architekturlizenz eigene CPU-Kerne entworfen und ab dem A8 von 2014 modifizierte Apple zudem die PowerVR-Grafik von Imagination Technologies; seit dem A11 Bionic von 2017 stammt die GPU komplett von Apple selbst.
Parallel zum Design eigener CPU-Kerne und Grafikeinheiten erfolgte die Entwicklung weiterer wichtiger IP-Blöcke, darunter etwa eine Neural Engine für künstliche Intelligenz und ein NVMe-Controller für SSDs. Der wiederum bildete die Grundlage für die etablierten T1-/T2-Chips, die unter anderem Sicherheitsfunktionen wie Verschlüsselung übernehmen und schon seit Jahren in Macbooks, Macs sowie iMacs stecken.
Im M1 rechnen acht CPU-Kerne, die sich in vier schnelle (Firestorm) und in vier effiziente (Icestorm) aufteilen. Auffällig sind die extrem großen L1-Instruktionen- und L1-Daten-Caches, welche die bis zu vierfache Kapazität aktueller AMD- und Intel-Prozessoren aufweisen. Auch 12 MByte L2 für die Performance- und 4 MByte L2 für die Effizienz-Kerne sind für ein Mobile-SoC enorm viel, kommen aber der Leistung zugute. Obendrein gibt es einen System Level Cache (SLC) unbekannter Größe für CPU, GPU und NPU.
Denn neben den CPU-Kernen hat Apple auch eine eigene Grafikeinheit im M1 untergebracht, diese nutzt acht Kerne. Mit einer theoretischen Rechenleistung von 2,6 Teraflops (FP32) sowie 82 GTex/s und 41 GPix/s befindet sich diese GPU in etwa zwischen einer Geforce GTX 1050 Ti und einer Geforce GTX 1060. Dazu packt Apple noch eine 16-kernige Neural Engine, die 11 Teraops an INT8-Performance für maschinelles Lernen (Inferencing) aufweist.
Weitere Funktionsblöcke im M1-Chip sind ein 128 Bit breites Interface, eine Secure Enclave für besonders schützenswerte Daten, ein Image Signal Processor (ISP) für Fotos und Videos, ein NVMe-Controller für Flash-Speicher, diverse Fixed-Functions für Decoding/Encoding wie H.265 und AV1, multiple PCIe-Gen4-Lanes, eine Display-Engine für 6K mit 60 Hz plus ein Controller für Thunderbolt 3 (40 GBit/s, kein eGPU-Support) respektive USB 4 (10 GBit/s).
All das summiert sich auf enorme 16 Milliarden Transistoren, die Apple in einem 5-nm-Verfahren beim Auftragsfertiger TSMC produzieren lässt. Der M1 wird mit schnellem LPDDR4X-4266-Arbeitsspeicher kombiniert, dieser sitzt auf dem gleichen Träger (on Package) und liefert gut 68 GByte/s. Zumindest derzeit bietet Apple das Macbook Air, das Macbook Pro und den Mac Mini einzig mit 8 GByte oder 16 GByte an, wenngleich größere DRAM-Chips verfügbar wären.
Schauen wir uns an, wie schnell der M1 in Benchmarks ist, wenn nativer ARM64-Code ausgeführt wird, und wie sich die Übersetzungsschicht Rosetta 2 schlägt, wenn x86-64-Bit-Programme ausgeführt werden, die eigentlich für Intel-Chips gedacht sind.
Schnell bis extrem schnell
Vorneweg seit gesagt, dass der M1 in seiner derzeitigen Form primär für Notebooks und Mini-PCs ausgelegt ist. Zwar kann der Chip mit bis zu 3,2 GHz für die Firestorm- und bis zu 2,1 GHz für die Icestorm-Kerne hoch takten und auch die Grafikeinheit fällt mit theoretisch 2,6 Teraflops sehr stark aus. In der Praxis aber begrenzt Apple das Potenzial: Der M1 darf sich im passiv gekühlten (!) Macbook Air kurzfristig 15 Watt genehmigen, bei längerer Last drosselt er auf 10 Watt - das zeigt Powermetrics.
Eigene Apps sind bei MacOS Big Sur vom Start weg für das Apple Silicon wie den M1 angepasst, beispielsweise sind Final Cut Pro oder Logic Pro auf ARM64 portiert. Für andere Entwickler gibt es Universal 2: Damit können passende Binaries erzeugt werden, wodurch die jeweilige App nativ auf Apple Silicon und nativ auf Intel x86 läuft. Als erste Partner haben Adobe bereits Photoshop als Beta und Blizzard schon World of Warcraft für den M1 umgesetzt.
Sind Anwendungen noch nicht angepasst, springt nach einmaliger Installation daher Rosetta 2 ein, eine Dynamic Binary Translation. Benannt ist diese nach dem Stein von Rosetta(öffnet im neuen Fenster) , welcher bei der Entzifferung von ägyptischen Schriften sehr hilfreich war. Der Performance-Verlust durch Rosetta 2 unterscheidet sich: Bei CPU-lastigen Apps reicht es für die Hälfte bis zwei Drittel der nativen Leistung, bei vielen Speicherzugriffen ist der Verlust gering(er) und bei bei starkem GPU-Fokus marginal.
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/01-cinebench-r23-(single)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/02-cinebench-r23-(multi)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/03-cinebench-r23-(multi,-sustained)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/04-geekbench-5-(single)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/05-geekbench-5-(multi)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/06-basemark-web-3.0-(edge,-safari)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/07-webxprt-3-v5-(edge,-safari)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/08-gfx-bench-5-(aztec-high-1440p)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/09-gfx-bench-5-(car-chase-1080p)-chart.png)
![Apple Macbook Air [Early 2020, Late 2020], Intel Whitebook (Bild: Golem.de)](https://scr3.golem.de/screenshots/2011/Apple-M1-Benches/thumb620/10-gfx-bench-5-(manhattan-1080p)-chart.png)
Im nativen Modus ist der M1 schlicht beeindruckend: Trotz eines Power-Budgets von kurzfristig 15 Watt und danach 10 Watt sowie passiver Kühlung ist das SoC mindestens so schnell wie Intels Ultrabook-Topmodell, der Core i7-1185G7, bei gleich 28 Watt. Die Singlethread-Leistung im Cinebench R23 und im Geekbench 5 liegt auf ähnlichem Niveau, die Multithread-Performance immer noch 20 Prozent darüber. Noch krasser wird die Differenz, wenn der Core i7-1185G7 mit den typischen 15 Watt läuft.
Der Core i5-1030NG7 aus dem erst im Frühling 2020 erschienen Macbook Air ist völlig chancenlos gegen den M1, und das trotz aktiver Kühlung, die bei längerer Last sehr laut wird. Apple hat das Wunder vollbracht, einen Chip zu entwickeln, der bei gleicher thermischer Verlustleistung locker die dreifache Geschwindigkeit erreicht und dabei auch noch lautlos auf Temperatur gehalten wird - im gleichen Gehäuse wohlgemerkt.
Wird ein Programm als Universal-App mit ARM64- und x86-Code ausgeliefert, lässt sich Rosetta 2 per Command+I forcieren. So können wir testen, wie stark die Übersetzungsschicht die Performance reduziert. Wie bereits ausgeführt, variiert das von Fall zu Fall, den bisherigen Core i5-1030NG7 schlägt der M1 dennoch durchweg.
Noch heftiger als bei CPU-Benchmarks fällt die Differenz aus, wenn die Grafikeinheit rechnet: Die Iris Xe des Core i7-1185G7 mit 28 Watt kann noch halbwegs mithalten, die ältere Iris Graphics des Core i5-1030NG7 bei 10 Watt hingegen fällt extrem weit ab. Im Aztec-Test mit hohen Details und 1440p-Auflösung etwa sprechen wir von der vierfachen Geschwindigkeit. Auch Spiele wie Shadow of the Tomb Raider laufen ähnlich deutlich schneller und das, obwohl der CPU-Code mit Rosetta 2 abgearbeitet wird.
Aus Zeitgründen außen vor sind Messungen mit Apples eigenem Final Cut Pro: Dort gibt es eine Funktion namens "Intelligent Anpassen" ( Smart Conform(öffnet im neuen Fenster) ), welche die Neural Engine des M1 für maschinelles Lernen nutzt, um Clips automatisch anzupassen, deren Seitenverhältnis sich vom Seitenverhältnis des Projekts unterscheidet.
Entwickeln auf Apples M1 mit Hindernissen
Dank Rosetta 2 ist der Wechsel von Intel-CPUs auf die ARM-Architektur in vielen Szenarien nicht spürbar. Und das gilt nicht nur für klassische Office-Arbeit, sondern tatsächlich auch für die Entwicklung und Programmierung - allerdings mit einigen Einschränkungen.
Apple unterstützt auf den M1-Chips selbstverständlich seine Entwicklungsumgebung Xcode und die dazugehörigen Kommandozeilenwerkzeuge. So ist es etwa problemlos möglich, mithilfe der mitgelieferten Werkzeuge kleinere C-Programme zu kompilieren wie zum Beispiel Curl, das problemlos auf sehr vielen Unix- und Posix-kompatiblen Systemen läuft und inzwischen auch auf Windows zu den Standardwerkzeugen gehört.
Apple hat auch noch nicht alles portiert
Interessant ist dabei, dass Apple selbst standardmäßig weiterhin ein älteres x86-Binary von Curl für seine Systeme verteilt und das, obwohl Curl eben wie von uns getestet nativ auf dem Apple Silicon läuft. Das gilt auch für einige weitere Werkzeuge in der Sammlung von Apple, andere wie etwa Ruby sind bereits native ARM-Binärdateien. Apple hat also offenbar seine eigenen Portierungsarbeiten der Werkzeuge noch nicht ganz abgeschlossen.
Wer oft Kommandozeilenwerkzeuge auf Macs nutzt, verwendet dafür sehr wahrscheinlich Homebrew(öffnet im neuen Fenster) . Auch das haben wir ausprobiert und werden beim ersten Start direkt mit einer Warnung konfrontiert, dass Homebrew nicht standardmäßig auf den ARM-Macs unterstützt wird. Die Software selbst ist zwar in Ruby geschrieben und lässt sich damit problemlos nutzen, die damit verwalteten Programme aber eben nicht immer.
Denn anders als zum Beispiel bei vielen Linux-Distributionen, die Binärdateien selbst erstellen und diese dann als Pakete verteilen, werden die von Homebrew verwalteten Programme direkt selbst auf dem eigenen Rechner kompiliert. Im Fall der neuen M1-Chips in den Apple-Macs setzt das aber eben auch den Support für diese CPU-Architektur voraus, was jedoch noch nicht immer gegeben ist.
Homebrew zeigt die Schwierigkeiten
Das Homebrew-Team selbst pflegt dazu auf Github eine Liste des Programm-Supports(öffnet im neuen Fenster) . Hier zeigt sich, dass gerade kleinere C-Programme bereits gut unterstützt werden. Dazu gehören neben dem bereits erwähnten Curl beispielsweise auch die Build-Werkzeuge der Autotools und CMake oder zahlreiche Bibliotheken wie Libgcrypt und Libssh. Das Homebrew-Projekt zählt darüber hinaus viele wichtige Projekte auf, die es selbst als Blocker beschreibt, da diese wohl erst nach viel Arbeit nativ auf dem M1 unterstützt werden können.
Dazu gehören alle Projekte, die auf einen Compiler aus dem GCC-Projekt angewiesen sind. Darauf hat bereits die R-Community hingewiesen , die auf den Fortran-Compiler setzt. Hier ist wohl frühestens im kommenden Sommer mit einer stabilen Unterstützung zu rechnen.
Das wirkt sich auf viele weitere Projekte aus, wie etwa Numpy oder Julia. Zwar hat Apple selbst hier in einigen Fällen versprochen, den Projekten aktiv bei ihren Portierungen zu helfen. Die Julia-Community behilft sich derzeit aber auch mit einigen Hacks(öffnet im neuen Fenster) , um zumindest vorübergehend den Port schneller abschließen zu können.
Support teilweise noch sehr unterschiedlich
Manche Programmiersprachen haben tendenziell noch Probleme mit der nativen Unterstützung: Am besten aufgestellt ist hier wohl noch Rust(öffnet im neuen Fenster) , das bereits als Beta-Version auf den ARM-Macs(öffnet im neuen Fenster) eingesetzt werden kann und bald stabil erscheinen dürfte. So konnten wir mit der aktuellen Rust-Beta das Programm Ripgrep kompilieren und ausführen.
Etwas schwieriger ist die Situation bei Go: Das ist zwar mit Vorabversionen lauffähig, stabile Versionen wird es vermutlich aber erst mit Go 1.16(öffnet im neuen Fenster) im kommenden Februar geben. Für OpenJDK und Java stehen ebenso zwar bereits ARM-Builds für MacOS bereit(öffnet im neuen Fenster) , offiziell abgeschlossen ist der Port ( JEP 391(öffnet im neuen Fenster) ) jedoch noch nicht.
Diese unterschiedliche native Unterstützung der Programmiersprachen selbst wirkt sich damit natürlich auch auf damit geschriebene Anwendungen aus, die eben oft noch nicht nativ für die neuen Macs bereitstehen und auch nicht schnell selbst kompiliert werden können. Und selbst wenn, ist dies meist erst seit wenigen Tagen oder Wochen möglich, wie etwa bei dem Electron-Framework(öffnet im neuen Fenster) . Darauf aufbauende Anwendungen benötigen wiederum noch Zeit für ihre eigenen Anpassungen und Tests.
Darüber hinaus gibt es aber eine Vielzahl an Werkzeugen, die durch Rosetta 2 zum Entwickeln genutzt werden können. Dazu gehört Microsofts Visual Studio Code, das bei uns flüssig läuft. Das gilt auch für weitere Software wie die Sprachen Go und R oder das OpenJDK. Hier sind jedoch noch teils deutliche Leistungseinbußen und der eine oder andere Fehler zu vermelden, abhängig vom tatsächlichen Programm. Eine Übersicht, welche Programme mit Rosetta 2 oder aber auch gar nicht laufen, bietet die Webseite Is Apple Silicon ready(öffnet im neuen Fenster) .
Noch keine gute Virtualisierung
Das derzeit größte Hindernis zum Wechsel auf ARM-Macs aus Entwicklungssicht ist wohl aber, dass Virtualisierungssoftware nicht mit Rosetta genutzt werden kann und derzeit noch nicht nativ verfügbar ist. Das gilt etwa für Parallels Desktop(öffnet im neuen Fenster) oder VMware Fusion(öffnet im neuen Fenster) . Beide Hersteller arbeiten zwar bereits an einem Port, haben aber noch keinen Termin für eine Verfügbarkeit genannt.
Etwas ausführlicher beschreibt das zugrunde liegende Problem das Docker-Team(öffnet im neuen Fenster) : Dazu müssen sich die Beteiligten um die Funktionsfähigkeit ihres eigenen Codes kümmern, der unter anderem an das neue Hypervisor-Framework von Apple(öffnet im neuen Fenster) angepasst werden muss. Auch Parallels hat bisher auf einen eigenen Hypervisor gesetzt und muss wegen der Änderungen an Big Sur nun auf den Apple-Hypervisor wechseln. Dieser unterscheidet sich aber eben in vielen Details zwischen der x86- und ARM-Implementierung.
Darauf aufbauend muss im Fall von Docker auch ein Linux-Kernel stabil gestartet werden können, der die Grundlagen der Docker-Container-Technik bereitstellt. Zudem ist das Docker-Team auf externe Abhängigkeiten angewiesen, vor allem die Sprache Go und Electron. Den Versuch, Docker auf dem M1 zu starten, quittiert die App mit einer großen Warnung und Docker lässt sich entsprechend nicht nutzen.
Virtualisierung prinzipiell möglich
Dass die Virtualisierung auf den ARM-Chips aber schon prinzipiell nutzbar ist, zeigt der Linux-Entwickler Jon Masters(öffnet im neuen Fenster) , der zuletzt für das ARM-Server-Startup Nuvia gearbeitet hat. Masters, der nun wieder bei Red Hat angestellt ist, ist es mit ein paar Kniffen gelungen, die Linux-Distribution Fedora für ARM auf dem M1 zu starten.
Darüber hinaus arbeitet auch der Red-Hat-Angestellte Peter Robinson daran, die Unterstützung des Linux-Kernels in der virtualisierten ARM-Umgebung der neuen Mac-Chips zu verbessern. Ähnlich muss wohl auch das Windows-Team vorgehen, das hier wahrscheinlich auch mit Parallels und VMware kooperieren dürfte. Denn Bootcamp steht auf den ARM-Macs nicht mehr bereit. Die Virtualisierung ist die einzige Option, Windows auf dem M1 auszuführen, auch wenn das noch nicht möglich ist.
Zumindest die native Docker-Unterstützung scheint zwar nicht mehr allzu weit entfernt zu sein. Wer aber ausgefeiltere Techniken benötigt und zum Beispiel auf eine volle grafische Unterstützung eines Windows- oder gar Linux-Gastsystems angewiesen ist, wird sich wohl noch einige Zeit gedulden müssen.
Ausblick auf kommendes Apple Silicon
Der M1 ist ein eindrucksvolles Debüt: Apple hat - wenngleich dank jahrelanger Erfahrung durch die iPads und iPhones - einen sehr beeindruckenden Chip entwickelt, der in allen Metriken überzeugen kann. Das SoC rechnet sehr schnell und dabei äußerst effizient, zudem geht der Funktionsumfang unter anderem aufgrund der Neural Engine und zusätzlicher IP-Blöcke weit über das hinaus, was bisher mit Intels Prozessoren möglich war.
Für Apple bedeutet das die volle vertikale Integration: Von der Hardware über die Firmware bis hin zum Betriebssystem samt Apps und Services kommt alles aus einer Hand. Das macht es einfacher, die einzelnen Komponenten ineinander zu verzahnen, was schlussendlich in einer geringeren Abhängigkeit von Dritten und einer höheren Gewinnmarge resultieren soll. Zu oft verzögerten sich in den vergangenen Jahren bei Intel diverse Designs, weil die Fertigung nicht so lief wie gedacht.
Weil allerdings der Wechsel von Intels x86 zum eigenen ARM64-basierten Apple Silicon umgesetzt wurde, gibt es Einschränkungen: Die eigene Software hat Apple zwar angepasst, erste Partner liefern bereits Universal-Apps aus und die Rosetta-2-Übersetzungsschicht sorgt dafür, dass x86-64-Bit-Programme mit vertretbarem Performance-Verlust ausgeführt werden können.
Für eigene Entwicklungen sollte aber beachtet werden, dass nicht alle Bibliotheken, Frameworks und Sprachen nativ vorliegen oder schon portiert wurden - das sollte jedoch in den kommenden Monaten folgen. Für die Virtualisierung etwa von Windows ist derzeit aber überhaupt nicht absehbar, ob oder wann entsprechende Software verfügbar ist.
M-Series wird fortgeführt
Bisher hat Apple einzig den M1 veröffentlicht, ungeachtet dessen ist dieser Chip nur der erste von vielen. Innerhalb von zwei Jahren soll bei allen Mac-Systemen der Umstieg von Intel x86 auf Apple ARM64 erfolgen - selbst beim iMac Pro und gar beim Mac Pro. Innerhalb dieser zwei Jahre wird wohl auch die notwendige Software auf ARM portiert werden. Für eigene Mac-Entwicklungen und -Arbeiten ist es also unumgänglich, sich mittelfristig mit dem ARM-Umstieg zu beschäftigen.
Schon gibt es erste Berichte, dass auf den M1 der M1X oder M2 folgt, wenngleich die tatsächliche Bezeichnung noch offen bleibt. Der M1X/M2 soll acht statt vier Firestorm-Performance-Kerne aufweisen, zudem dürfte Apple weitere Verbesserungen vornehmen.
Interessant wird dabei vor allem, auf welche Geschwindigkeit und Leistungsaufnahme das System-on-a-Chip skaliert wird, um auch in einem iMac Pro oder Mac Pro eingesetzt werden zu können. Die Performance der 28-kernigen Intel-CPU, ein Xeon W, können wir uns gut mit dem Apple Silicon vorstellen. Ob allerdings auch dedizierte Grafikkarten wie die Radeon Pro Duo VII - die immerhin aus vier GPUs besteht - durch eine Eigenentwicklung obsolet gemacht werden können, gilt es abzuwarten.
Andererseits dürfte es für Apple wohl kaum ein Problem darstellen, die eigenen GPUs auf PCIe-Gen4-Steckkarten auszulagern, wenn das denn tatsächlich gewünscht ist. Unter dem Codenamen Lifuka(öffnet im neuen Fenster) soll Apple eine dedizierte GPU für ein 5-nm-Verfahren entwickeln, die für reguläre iMac-Systeme gedacht ist. Der M1 war also nur der Anfang.
