Compilar C / C ++ en Apple M1





Intrigado por los impresionantes puntos de referencia del M1, saqué mi último Mac Mini para medir mi velocidad de compilación en C / C ++. Medimos el build2



local (sin un repositorio de paquetes), que incluye principalmente código C ++ (611 unidades de traducción) con algunos bloques C (29) y enlaces entre ellos (19). Este punto de referencia solo requiere un compilador C ++ y está incluido en el conjunto de pruebas Phoronix , por lo que se puede comparar con una gran cantidad de procesadores.



El punto de referencia de Phoronix actualmente usa build2 0.12.0, tenemos 0.13.0 (versión actual), aquí la compilación es aproximadamente un 10% más lenta.


Después de configurar Mac OS e instalar las herramientas de línea de comandos para XCode 12.2, tenemos todo lo que necesitamos:



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





A juzgar por _LIBCPP_VERSION



el __version



archivo de título libc++



, esta versión de la vainilla de Clang Clang de Apple divergió de algún lugar en el proceso de desarrollo 10.0.0.



También puede haber notado que el nombre del procesador en el triplete de Apple Clang es diferente del estándar aarch64



. En realidad config.guess



muestra lo siguiente:



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





Para evitar el uso de dos nombres para el mismo, Build2 canonizado arm64



en aarch64



, por lo buildfiles



que siempre vemos en aarch64.


Comprobemos la cantidad de subprocesos de hardware en sysctl



:



$ sysctl -n hw.ncpu
8
      
      





Aquí hay 8 subprocesos, estos son 4 núcleos productivos y 4 de eficiencia energética. En la primera ejecución, usamos todos los núcleos. Obviamente esto da el mejor resultado:



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





Fue una agradable sorpresa que build2 0.13.0 funcionara sin problemas, aunque se lanzó antes que M1. Dado que ARM tiene un orden de memoria débil, esto también sirvió como una prueba adicional para la implementación multiproceso de build2 y el uso intensivo de atomics.


Primero, comparemos el M1 con mi estación de trabajo en un Intel Xeon E-2288G de 8 núcleos (esencialmente un i9-9900K más ECC). La misma construcción en vainilla Clang toma 131 segundos. Aunque este es el mejor resultado, el rendimiento del M1 sigue siendo impresionante. Especialmente si se tiene en cuenta que durante la compilación, la estación de trabajo literalmente arroja aire caliente y zumba como un avión, y el M1 susurra silenciosamente con una corriente de aire caliente apenas perceptible.



Un punto de referencia de un solo subproceso evalúa el rendimiento de la CPU en compilaciones incrementales:



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





El núcleo del E-2288G tarda 826 segundos. Entonces, el núcleo Xeon de 5 GHz es en realidad más lento que el núcleo M1 de 3,2 GHz.



Otro resultado interesante es una ejecución de cuatro hilos, que usa solo los núcleos M1 eficientes:



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





Aunque es algo más lento que la prueba de ocho núcleos, utiliza menos memoria. Por lo tanto, esta opción tiene sentido en sistemas con RAM insuficiente (como en todas las máquinas M1 modernas).



Aquí hay un resumen de todos los resultados:



TIEMPO DE NÚCLEOS / HILOS DE CPU
-------------------------
E-2288G 8/16 131s
M1 4 + 4 163 s
M1 4 207s
M1 1691s
E-2288G 1 826s


Está claro que, en muchos aspectos, esta es una comparación de manzanas a naranjas (estación de trabajo versus dispositivo móvil, diseño antiguo y tecnología de proceso versus moderna, etc.).



Ahora agreguemos algunos resultados interesantes del punto de referencia de Phoronix. En particular, conviene tomar los indicadores de las últimas estaciones de trabajo y procesadores móviles de Intel y AMD. Aquí está mi selección (puede hacer la suya propia, solo recuerde agregar un 10% adicional a los resultados de Phoronix; también tenga en cuenta que la mayoría de las pruebas usan GCC en lugar de Clang):



TIEMPO DE NÚCLEOS / HILOS DE CPU
------------------------------------------
Desgarrador de roscas AMD 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

* .


Tenga en cuenta que los resultados para los mejores dispositivos móviles Intel (1185G) y AMD (4900HS) lamentablemente aún no están disponibles y las cifras citadas se extrapolan en función de los relojes y otros puntos de referencia.



Es fácil ver en la tabla de arriba que el Apple M1 es un procesador impresionante, especialmente cuando se trata de consumo de energía. Además, es el primer procesador ARM de nivel de escritorio convencional. En comparación, la misma compilación en una Raspberry Pi 4B tarda 1724 segundos, ¡más de 10 veces más lento! Aunque no podemos arrancar Linux o Windows aquí, existe alguna evidencia de que se ejecutan en máquinas virtuales con un rendimiento decente. Como resultado, la canalización de construcción continua basada en ARM puede convertirse en estándar.



Habiendo visto los puntos de referencia del M1, uno no puede evitar preguntarse cómo lo hizo Apple. Aunque hay mucha especulación con algunos elementos de magia negra y brujería, este artículo sobre M1 en Anandtech (y otro allí junto al enlace) me pareció una buena fuente de información técnica . Destacar:



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 tiene un kernel inusualmente ancho que ejecuta múltiples instrucciones en paralelo y / o fuera de orden. Se especula que debido a la mala ordenación de la memoria de ARM y la codificación de instrucciones de tamaño fijo, Apple pudo hacer un kernel mucho más amplio.


También sería interesante ver cómo Apple puede escalar este diseño a más núcleos.



All Articles