Derivado de mis puntos de referencia recientes de AWS Graviton3 y de comparar Graviton3 con Intel Xeon y AMD EPYC, varios lectores de Phoronix expresaron interés en ver algunos puntos de referencia de ajuste del compilador para Graviton3 alrededor de sus núcleos Arm Neoverse-V1 con soporte SVE. Estos son algunos puntos de referencia para aquellos interesados en el impacto del ajuste del compilador para este nuevo procesador en la nube Arm de alto rendimiento.
Las pruebas en este artículo se realizaron con una instancia Amazon EC2 c7g.8xlarge con 32 núcleos de una plataforma Graviton3. Ubuntu 22.04 LTS se estaba ejecutando en esta instancia EC2 con su kernel Linux 5.15 estándar mientras optaba por usar gcc-snapshot en Ubuntu 22.04 para proporcionar una pila de compilador basada en GCC12 más nueva.
De esta misma instancia Graviton3, un número Se realizaron pruebas comparativas de C/C++ de código abierto mientras se probaban con los siguientes CFLAGS/CXXFLAGS:
-O3-march=armv8.4-a para ARMv8.4 como se basa Neoverse-V1.
-O3 0march=armv8.4-a+sve para especificar la compatibilidad con Arm SVE (Scalable Vector Extension) que se encuentra con Neoverse-V1.
-O3-march-armv8.4-a+sve-mcpu=neoverse-v1 para disfrutar también de ajustes de CPU específicos para Neoverse-V1.
En GCC 11 se agregó la compatibilidad con Arm Scalable Vector Extension (SVE), incluida la capacidad de vectorización automática para muchas funciones de SVE. Echemos un vistazo para ver qué diferencia tienen estos indicadores del compilador en el rendimiento resultante de los archivos binarios generados que se ejecutan en Graviton3 en la nube de Amazon.
La prueba del compilador en Graviton3 se limitó solo a esas tres configuraciones para conservar los costos operativos en la nube.
Las opciones del compilador SVE ayudaron un poco a las pruebas del codificador de imágenes JPEG XL para ofrecer un mejor rendimiento sobre la orientación básica de Armv8.4 sin SVE. OpenJPEG también se benefició hasta cierto punto de SVE.
En otras cargas de trabajo, la ventaja de SVE varió de ganancias leves a moderadas.
La compatibilidad con la vectorización automática de SVE de GCC 12 ayudó con parte del audio. codificar puntos de referencia.
Por supuesto, depende en gran medida del software bajo prueba cuánto impacto puede tener Arm SVE y otros ajustes de Neoverse-V1.
Con Zstd, por ejemplo el ajuste solo ayudó al rendimiento de descompresión para el modo largo, mientras que en las otras configuraciones de compresión Zstd probadas no hubo una diferencia apreciable.
En el caso de algunos puntos de referencia como Crypto++, el ajuste-mcpu=neoverse-v1 en realidad tuvo un impacto negativo en el rendimiento.
La vectorización automática de GCC y/o SVE tuvo un impacto negativo en el rendimiento de la biblioteca de procesamiento de señal digital de código abierto Liquid-DSP.
O en los puntos de referencia criptográficos de Botan, el ajuste de Neoverse-V1 fue una ventaja notable para algunos de los algoritmos criptográficos.
El rendimiento de la biblioteca de red neuronal Tencent de TNN varió con SVE.
Para resumir, como suele ser el caso, se reduce en gran medida a las bases de código particulares y las cargas de trabajo que usted participe activamente para ver si vale la pena el ajuste adicional del compilador. En algunas cargas de trabajo, GCC 12, según se probó, mostró algunos beneficios con su soporte de vectorización automática SVE, mientras que en otros casos no tanto y en algunos casos retrocedió el rendimiento. Será interesante ver el impacto del uso de intrínsecos SVE ajustados a mano por parte del principal software de código abierto a medida que más procesadores Arm marcan la compatibilidad con SVE/SVE2, así como también cómo evolucionan los avances interminables del compilador de código abierto.
Aquellos que deseen ver todos los puntos de referencia de comparación de banderas del compilador probados para la instancia Graviton3 pueden ver esta página de resultados.
