Suite à mes récents benchmarks AWS Graviton3 et en regardant Graviton3 par rapport à Intel Xeon et AMD EPYC, un certain nombre de lecteurs de Phoronix ont exprimé leur intérêt à voir quelques benchmarks de réglage du compilateur pour le Graviton3 autour de ses cœurs Arm Neoverse-V1 avec prise en charge SVE. Voici quelques points de repère pour ceux qui s’intéressent à l’impact du réglage du compilateur pour ce nouveau processeur cloud Arm hautes performances.
Les tests de cet article ont été effectués avec une instance Amazon EC2 c7g.8xlarge avec 32 cœurs d’une plate-forme Graviton3. Ubuntu 22.04 LTS fonctionnait sur cette instance EC2 avec son noyau Linux 5.15 d’origine tout en choisissant d’utiliser gcc-snapshot sur Ubuntu 22.04 pour fournir une nouvelle pile de compilateur basée sur GCC12.
De cette même instance Graviton3, un certain nombre des benchmarks C/C++ open source ont été effectués lors des tests avec les CFLAGS/CXXFLAGS suivants testés :
-O3-march=armv8.4-a pour ARMv8.4 comme Neoverse-V1 est basé.
-O3 0march=armv8.4-a+sve pour spécifier le support Arm SVE (Scalable Vector Extension) trouvé avec Neoverse-V1.
-O3-march-armv8.4-a+sve-mcpu=neoverse-v1 pour profiter également du réglage CPU spécifique au Neoverse-V1.
La prise en charge de l’extension vectorielle évolutive du bras (SVE) a été ajoutée dans GCC 11, y compris la possibilité de vectorisation automatique pour de nombreuses fonctionnalités SVE. Jetons un coup d’œil pour voir quelle différence ces indicateurs de compilateur ont sur les performances résultantes des binaires générés s’exécutant sur Graviton3 dans le cloud Amazon.
Les tests du compilateur sur Graviton3 étaient limités à ces trois configurations afin de conserver les coûts d’exploitation dans le cloud.
Les options du compilateur SVE ont fourni une certaine aide aux tests de l’encodeur d’image JPEG XL pour offrir de meilleures performances par rapport au ciblage Armv8.4 de base sans SVE. OpenJPEG a également bénéficié dans une certaine mesure de SVE.
Dans d’autres charges de travail, l’avantage SVE variait de gains légers à modérés.
La prise en charge de la vectorisation automatique SVE de GCC 12 a aidé une partie de l’audio encoder les repères.
Bien sûr, cela dépend fortement du logiciel testé de l’impact éventuel qu’il peut avoir sur Arm SVE et d’autres réglages Neoverse-V1.
Avec Zstd par exemple seul le réglage a aidé les performances de décompression pour le mode long alors que dans les autres configurations de compression Zstd testées, il n’y avait pas de différence mesurable.
Dans le cas de certains benchmarks comme Crypto++, le réglage-mcpu=neoverse-v1 a en fait eu un impact négatif sur les performances.
La vectorisation automatique de GCC et/ou SVE a eu un impact négatif sur les performances de la bibliothèque de traitement de signal numérique open source Liquid-DSP.
Ou dans les benchmarks de chiffrement Botan, le réglage Neoverse-V1 présentait un avantage notable pour certains des algorithmes de chiffrement.
Les performances de la bibliothèque de réseaux de neurones TNN Tencent variaient avec SVE.
Pour faire court, comme c’est souvent le cas, cela dépend en grande partie des bases de code particulières et des charges de travail que vous engagez-vous activement pour savoir si le réglage supplémentaire du compilateur en vaut la peine. Dans certaines charges de travail, GCC 12, tel que testé, a montré certains avantages avec sa prise en charge de la vectorisation automatique SVE, tandis que dans d’autres cas, pas tellement et dans certains cas, les performances ont régressé. Il sera intéressant de voir l’impact de l’utilisation des intrinsèques SVE réglés à la main par les principaux logiciels open source à mesure que de plus en plus de processeurs Arm se démarquent avec le support SVE/SVE2 ainsi que l’évolution des avancées sans fin du compilateur open source.
Ceux qui souhaitent voir tous les benchmarks de comparaison des drapeaux du compilateur testés pour l’instance Graviton3 peuvent voir cette page de résultats.
