Compiler C / C ++ sur Apple M1





Intrigué par les impressionnants benchmarks du M1, j'ai sorti le dernier Mac Mini pour mesurer ma vitesse de compilation en C / C ++.



Nous mesurons le build2 local (sans référentiel de packages), qui comprend principalement du code C ++ (611 unités de traduction) avec quelques blocs C (29) et des liens entre eux (19). Ce benchmark ne nécessite qu'un compilateur C ++ et est inclus dans la suite de tests Phoronix , il peut donc être comparé à un grand nombre de processeurs.



Le benchmark Phoronix utilise actuellement build2 0.12.0, nous avons 0.13.0 (la version actuelle), ici la build est environ 10% plus lente.


Après avoir configuré Mac OS et installé les outils de ligne de commande pour XCode 12.2, nous avons tout ce dont nous avons besoin:



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





À en juger par _LIBCPP_VERSION



le __version



fichier titre libc++



, cette version de la vanille Clang Clang d'Apple a divergé de quelque part dans le processus de développement 10.0.0.



Vous avez peut-être également remarqué que le nom du processeur dans le triplet Apple Clang est différent de celui standard aarch64



. config.guess



Montre en fait ce qui suit:



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





Pour éviter d'utiliser deux noms pour le même, build2 canonisé arm64



dans aarch64



, donc dansbuildfiles



nous voyons toujours aarch64 dans.


Vérifions le nombre de threads matériels dans sysctl



:



$ sysctl -n hw.ncpu
8
      
      





Il y a 8 threads ici, ce sont 4 cœurs productifs et 4 cœurs économes en énergie. Dans la première exécution, nous utilisons tous les cœurs. Évidemment, cela donne le meilleur résultat:



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





Ce fut une agréable surprise que build2 0.13.0 ait fonctionné sans aucun problème, bien qu'il ait été publié avant M1. Comme ARM a un ordre de mémoire faible, cela a également servi de test supplémentaire pour l'implémentation multithread de build2 et l'utilisation intensive de l'atomique.


Tout d'abord, comparons le M1 à ma station de travail sur un Intel Xeon E-2288G à 8 cœurs (essentiellement un i9-9900K plus ECC). Le même build sur vanilla Clang prend 131 secondes. Bien que ce soit le meilleur résultat, les performances du M1 sont toujours impressionnantes. Surtout quand on considère que lors de la compilation, le poste de travail crache littéralement de l'air chaud et bourdonne comme un avion, et le M1 bruit tranquillement avec un flux d'air chaud à peine perceptible.



Un benchmark monothread évalue les performances du processeur dans les builds incrémentiels:



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





Le noyau E-2288G prend 826 secondes. Ainsi, le cœur Xeon 5 GHz est en fait plus lent que le cœur M1 3,2 GHz.



Un autre résultat intéressant est une exécution à quatre threads, qui n'utilise que les cœurs M1 efficaces:



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





Bien qu'il soit un peu plus lent que le test à huit cœurs, il utilise moins de mémoire. Ainsi, cette option a du sens sur les systèmes avec une RAM insuffisante (comme sur toutes les machines M1 modernes).



Voici un résumé de tous les résultats:



TEMPS DES CŒURS / FILS DU CPU
-------------------------
E-2288G 8/16 131s
M1 4 + 4 163
M1 4 207
M1 1 691
E-2288G 1 826s


Il est clair qu'à bien des égards, il s'agit d'une comparaison pommes-oranges (poste de travail contre appareil mobile, ancienne conception et technologie de processus par rapport à la technologie moderne, etc.)



Ajoutons maintenant quelques résultats intéressants du benchmark Phoronix. En particulier, il convient de prendre les indicateurs des dernières stations de travail et processeurs mobiles d'Intel et d'AMD. Voici ma sélection (vous pouvez faire la vôtre, n'oubliez pas d'ajouter 10% supplémentaires aux résultats de Phoronix; notez également que la plupart des tests utilisent GCC au lieu de Clang):



TEMPS DES CŒURS / FILS DU CPU
------------------------------------------
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

* .


Veuillez noter que les résultats pour les meilleurs mobiles Intel (1185G) et AMD (4900HS) ne sont malheureusement pas encore disponibles, et les chiffres cités sont extrapolés sur la base d'horloges et d'autres benchmarks.



Il est facile de voir dans le tableau ci-dessus que l'Apple M1 est un processeur impressionnant, surtout si l'on considère la consommation d'énergie. De plus, il s'agit du premier processeur ARM de bureau grand public. En comparaison, la même construction sur un Raspberry Pi 4B prend 1724 secondes, plus de 10 fois plus lentement! Bien que nous ne puissions pas démarrer Linux ou Windows ici, il existe des preuves qu'ils fonctionnent sur des machines virtuelles avec des performances décentes. En conséquence, le pipeline de construction continue basé sur ARM peut devenir standard.



Après avoir vu les benchmarks du M1, on ne peut s'empêcher de se demander comment Apple a fait cela. Bien qu'il y ait beaucoup de spéculations avec certains éléments de magie noire et de sorcellerie, mais cet article sur M1 sur Anandtech (et un autre là-bas par le lien) m'a semblé une très bonne source d'informations techniques . Points forts:



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 a un noyau inhabituellement large qui exécute plusieurs instructions en parallèle et / ou dans le désordre. Il y a des spéculations selon lesquelles, en raison du mauvais ordre de la mémoire d'ARM et du codage des instructions de taille fixe, Apple a pu créer un noyau beaucoup plus large.


Il serait également intéressant de voir comment Apple peut adapter cette conception à plus de cœurs.



All Articles