Kompilieren von C / C ++ unter Apple M1





Fasziniert von den beeindruckenden Benchmarks des M1, nahm ich meinen neuesten Mac Mini heraus, um meine Kompilierungsgeschwindigkeit in C / C ++ zu messen.



Wir messen den lokalen Build2 (ohne Paket-Repository), der hauptsächlich C ++ - Code (611 Übersetzungseinheiten) mit einigen C-Blöcken (29) und Verknüpfungen zwischen diesen (19) enthält. Dieser Benchmark erfordert nur einen C ++ - Compiler und ist in der Phoronix-Testsuite enthalten , sodass er mit einer großen Anzahl von Prozessoren verglichen werden kann.



Der Phoronix-Benchmark verwendet derzeit Build2 0.12.0, wir haben 0.13.0 (aktuelle Version), hier ist der Build etwa 10% langsamer.


Nach dem Einrichten von Mac OS und der Installation der Befehlszeilentools für XCode 12.2 haben wir alles, was wir brauchen:



$ clang++ --version
Apple clang version 12.0.0 (clang-1200.0.32.27)
Target: arm64-apple-darwin20.1.0
      
      





Gemessen an _LIBCPP_VERSION



dem Titel __version



Datei libc++



, diese Version von Apples Clang Clang Vanille wich von irgendwo in dem Entwicklungsprozess 10.0.0.



Möglicherweise haben Sie auch bemerkt, dass sich der Prozessorname im Apple Clang-Triplett vom Standardnamen unterscheidet aarch64



. config.guess



Zeigt eigentlich folgendes:



$ ./config.guess
aarch64-apple-darwin20.1.0
      
      





Mit zwei Namen für die gleiche, build2 zu vermeiden kanonisiert arm64



in aarch64



, so buildfiles



wir immer in sehen aarch64.


Überprüfen wir die Anzahl der Hardware-Threads in sysctl



:



$ sysctl -n hw.ncpu
8
      
      





Hier gibt es 8 Threads, dies sind 4 produktive Kerne und 4 energieeffiziente. Im ersten Durchlauf verwenden wir alle Kerne. Offensichtlich ergibt dies das beste Ergebnis:



$ time sh ./build2-install-0.13.0.sh --local --yes ~/install
163s
      
      





Es war eine angenehme Überraschung, dass build2 0.13.0 problemlos funktionierte, obwohl es früher als M1 veröffentlicht wurde. Da ARM eine schwache Speicherreihenfolge aufweist, diente dies auch als zusätzlicher Test für die Multithread-Implementierung von build2 und die starke Verwendung von Atomen.


Vergleichen wir zunächst den M1 mit meiner Workstation auf einem Intel Xeon E-2288G mit 8 Kernen (im Wesentlichen einem i9-9900K plus ECC). Der gleiche Aufbau auf Vanille Clang dauert 131 Sekunden. Obwohl dies das beste Ergebnis ist, ist die Leistung des M1 immer noch beeindruckend. Besonders wenn man bedenkt, dass die Workstation während des Kompilierens buchstäblich heiße Luft ausstößt und wie ein Flugzeug summt, und der M1 raschelt leise mit einem kaum wahrnehmbaren warmen Luftstrom.



Ein Single-Threaded-Benchmark bewertet die CPU-Leistung in inkrementellen Builds:



$ time sh. /build2-install-0.13.0.sh --local --yes-j 1 ~ / install
691s
      
      





Der E-2288G-Kern benötigt 826 Sekunden. Der 5-GHz-Xeon-Kern ist also tatsächlich langsamer als der 3,2-GHz-M1-Kern.



Ein weiteres interessantes Ergebnis ist ein Vier-Thread-Lauf, bei dem nur die effizienten M1-Kerne verwendet werden:



$ time sh ./build2-install-0.13.0.sh --local --yes -j 4 ~/install
207s
      
      





Obwohl es etwas langsamer als der Acht-Kern-Test ist, benötigt es weniger Speicher. Daher ist diese Option auf Systemen mit unzureichendem RAM sinnvoll (wie bei allen modernen M1-Maschinen).



Hier ist eine Zusammenfassung aller Ergebnisse:



CPU CORES / THREADS TIME
-------------------------
E-2288G 8/16 131s
M1 4 + 4 163s
M1 4 207s
M1 1 691s
E-2288G 1 826s


Es ist klar, dass dies in vielerlei Hinsicht ein Vergleich zwischen Äpfeln und Orangen ist (Workstation versus mobiles Gerät, altes Design und Prozesstechnologie versus modern usw.).



Fügen wir nun einige interessante Ergebnisse aus dem Phoronix-Benchmark hinzu. Insbesondere sollten die Indikatoren der neuesten Workstations und mobilen Prozessoren von Intel und AMD übernommen werden. Hier ist meine Auswahl (Sie können Ihre eigene auswählen, denken Sie daran, zusätzliche 10% zu den Phoronix-Ergebnissen hinzuzufügen; beachten Sie auch, dass die meisten Tests GCC anstelle von Clang verwenden):



CPU CORES / THREADS TIME
--------------------------------------
AMD Threadripper 3990X 64/128 56s
AMD Ryzen 5950X 16/32 71s
Intel Xeon E-2288G 8/16 131s
Apple M1 4 + 4 163s
AMD   Ryzen        4900HS   8/16      176s*
Apple                 M1    4         207s
AMD   Ryzen        4700U    8/8       222s
Intel Core         1185G    4/8       281s*
Intel Core         1165G    4/8       295s

* .


Bitte beachten Sie, dass die Ergebnisse für das beste mobile Intel (1185G) und AMD (4900HS) leider noch nicht verfügbar sind und die angegebenen Zahlen basierend auf Uhren und anderen Benchmarks extrapoliert werden.



Aus der obigen Tabelle ist leicht ersichtlich, dass der Apple M1 ein beeindruckender Prozessor ist, insbesondere wenn es um den Stromverbrauch geht. Darüber hinaus ist es der erste Mainstream-Desktop-ARM-Prozessor. Im Vergleich dazu dauert der gleiche Build auf einem Raspberry Pi 4B 1724 Sekunden, mehr als zehnmal langsamer! Obwohl wir hier weder Linux noch Windows booten können, gibt es Hinweise darauf, dass sie auf virtuellen Maschinen mit angemessener Leistung ausgeführt werden. Infolgedessen kann die ARM-basierte Pipeline für den kontinuierlichen Aufbau zum Standard werden.



Nachdem man die Benchmarks des M1 gesehen hat, muss man sich fragen, wie Apple das gemacht hat. Es gibt zwar viele Spekulationen mit einigen Elementen der schwarzen Magie und Hexerei, aber dieser Artikel über M1 auf Anandtech (und ein anderer dort über den Link) schien mir eine ziemlich gute Quelle für technische Informationen zu sein . Highlights:



TSMC 5

10 ( 11x5G, 14  E-2288G) 7  AMD/TSMC.



LPDDR4-4266 RAM

Intel AMD .



L1

M1 L1 .



L2

Intel AMD, L2 , L3, M1 L2.





M1 hat einen ungewöhnlich breiten Kernel, der mehrere Anweisungen parallel und / oder außer Betrieb ausführt. Es wird spekuliert, dass Apple aufgrund der schlechten Speicherreihenfolge und der Befehlscodierung mit fester Größe von ARM einen viel breiteren Kernel erstellen konnte.


Es wäre auch interessant zu sehen, wie Apple dieses Design auf mehr Kerne skalieren kann.



All Articles