AMD EPYC – études de performances STREAM, HPL, InfiniBand et WRF

---

Résumé

Le HPC and AI Innovation Lab dispose d’un nouveau cluster avec 32 systèmes AMD EPYC interconnectés avec Mellanox EDR InfiniBand. Comme toujours, nous effectuons des évaluations de performances sur notre dernier cluster et nous souhaitions partager les résultats. Ce blog présente les résultats pour la bande passante des mini-tests de performance STREAM, HPL et InfiniBand pour la latence et la bande passante, ainsi que les résultats de WRF obtenus à partir de ses jeux de données de référence.

Nous sommes intéressés par les performances en situation réelle de l’application HPC sur EPYC. Si vous avez des jeux de données que vous souhaitez essayer sur EPYC, prenez contact avec votre équipe de compte Dell pour accéder à l’Innovation Lab.
 

---

Architecture AMD EPYC

Les processeurs AMD EPYC prennent en charge huit canaux de mémoire, jusqu’à 16 modules DIMM (Dual in-line Memory) par socket avec deux barrettes DIMM par canal, et jusqu’à 32 cœurs par socket. En outre, une plate-forme avec des processeurs AMD fournit jusqu’à 128 voies PCI-E pour les périphériques comme les GPU et les disques NVMe.
Les CPU eux-mêmes sont des modules multipuces assemblés à partir de quatre puces. Chaque puce comprend jusqu’à huit cœurs Zen, deux canaux de mémoire DDR4 et 32 voies d’E/S. Les cœurs Zen sur une puce sont répartis en deux groupes de quatre, et chaque groupe de quatre cœurs, appelé complexe de cœurs, partage le cache L3. Au sein d’un socket, les quatre puces sont reliées entre elles via une interconnexion cohérente, appelée Infinity Fabric. Ceci est illustré dans la Figure 1.


Figure 1 : Structure du socket EPYC. CCX est un complexe de cœurs d’un maximum de 4 cœurs qui partagent le cache L3. M* sont les canaux de mémoire, deux canaux gérés par chaque puce. P* et G* sont des voies d’E/S. ∞ est l’Infinity Fabric.



Sur un système à socket unique, chaque puce fournit jusqu’à 32 voies PCI-E à l’aide des voies d’E/S P* et G* illustrées dans la Figure 1. Cela donne au socket un total de 128 voies PCI-E, comme illustré dans la Figure 2. Lorsqu’un processeur est utilisé dans une configuration à deux sockets (2S), la moitié des voies d’E/S de chaque puce est utilisée pour se connecter à l’une des puces de l’autre socket à l’aide des voies d’E/S configurés comme Infinity Fabric. Cela laisse au socket les voies d’E/S P* pour un total de 64 voies PCI-E et, par conséquent, toujours 128 voies PCI-E pour la plate-forme. Ceci est illustré dans la Figure 3


Figure 2 : Voies EPYC 1S PCI-E




Figure 3 : Structure EPYC 2S




Figure 3 : Structure EPYC 2S

 

---

Test de performance STREAM

Une première étape pour évaluer EPYC est de mesurer la bande passante de la mémoire de la plate-forme en utilisant le test de performance STREAM. Ces tests ont été effectués sur un serveur Dell EMC PowerEdge R7425 avec deux processeurs AMD EPYC 7601 (32c, 2,2 GHz), 16 barrettes DIMM de 16 Go à 2400 Mt/s, exécutant Red Hat® Enterprise Linux® 7.5.

La présentation de l’accès à la mémoire non uniforme (NUMA) de l’EPYC peut être contrôlée par une option du BIOS appelée « entrelacement mémoire » et mappée à l’aide d’utilitaires Linux tels que numactl et lstopo.

L’option d’entrelacement mémoire par défaut est « entrelacement mémoire canal ». Dans ce mode, les deux canaux de chaque puce sont entrelacés. Cela représente quatre nœuds NUMA par socket et huit nœuds NUMA pour le système d’exploitation sur un système 2S.

L’option « entrelacement mémoire puce » est une option qui permet d’entrelacer de la mémoire sur les quatre puces d’un support, c.-à-d. huit canaux de mémoire. Cela représente un nœud NUMA par socket et deux nœuds NUMA sur un système 2S.

« Entrelacement mémoire socket » entrelace la mémoire sur les deux sockets, ce qui donne un nœud NUMA sur une plate-forme 2S. Cela équivaut à la désactivation de NUMA.    

Si vous utilisez la configuration par défaut « entrelacement mémoire canal », rappelez-vous que chaque socket comporte quatre puces, chaque puce fournit deux canaux de mémoire, et le BIOS présente huit nœuds NUMA sur une plate-forme 2S. L’exemple de sortie de la commande numactl dans la Figure 4 illustre ces huit nœuds NUMA sur une plate-forme 2S, un nœud NUMA par puce.


Figure 4 : Sortie de numactl sur 2S EPYC


Physiquement, il existe quatre distances NUMA sur la plate-forme, comme indiqué dans la Figure 4 : vers le nœud NUMA lui-même (distance « 10 » en rouge), vers les trois nœuds qui partagent la même puce (distance « 16 » en bleu), vers le nœud de l’autre socket connecté directement via un lien Infinity Fabric (distance « 22 » en vert), vers les trois autres nœuds du socket distant qui sont accessibles via deux tronçons à l’aide de ’Infinity Fabric entre les deux sockets, plus le lien Infinity Fabric interne (distance « 28 » en noir).

Certaines implémentations et versions du BIOS peuvent simplifier cette disposition physique et ne présenter que trois distances NUMA au système d’exploitation. Cette simplification consiste à masquer la différence entre le nœud NUMA 0 (par exemple) et les nœuds NUMA 4,5,6,7 en présentant les nœuds NUMA 4,5,6,7 comme équidistants au nœud NUMA 0. Cette implémentation est illustrée dans la Figure 5. La configuration NUMA est une option réglable dans la prochaine version du BIOS PowerEdge R7425. La simplification des distances des nœuds NUMA ne modifie pas la disposition physique réelle des cœurs, elle est surtout utile au planificateur du système d’exploitation. Pour les tâches HPC et MPI qui prennent en compte NUMA, ces configurations différentes ne devraient jouer aucun rôle.


Figure 5 : Sortie de numactl sur 2S EPYC avec des distances NUMA simplifiées


En plus des 8 nœuds NUMA sur une plate-forme à deux sockets, la Figure 4 et la Figure 5 montrent également la mémoire et les cœurs associés à chaque nœud NUMA. Chaque nœud NUMA dispose de 32 Go de mémoire sur deux barrettes DIMM de 16 Go (16 barrettes DIMM sur le serveur, huit par socket, 1 barrette DIMM par canal). Chaque nœud NUMA contient les huit cœurs de la puce locale. L’énumération du cœur sur la plate-forme Dell EMC utilise la répartition alternée (round robin), en passant d’abord par tous les nœuds NUMA, puis en remplissant chaque nœud NUMA.

De plus, la sortie de la commande lstopo peut être utilisée pour indiquer clairement l’ensemble des quatre cœurs qui constitue un complexe de cœurs. Voici les quatre cœurs sur une puce qui se partagent le cache L3. Par exemple, la Figure 6 montre que le nœud NUMA 0 dispose de huit cœurs et que sur ce nœud, les cœurs NUMA 0, 16, 32, 48 partagent un cache L3 et les cœurs 8, 24, 40, 56 partagent un cache L3.


Figure 6 : Sortie de lstopo sur 2S EPYC


Figure 7 : Bande passante de la mémoire de la plate-forme AMD EPYC

En gardant ces informations de configuration NUMA à l’esprit, consultez les résultats du test de performance de la bande passante de la mémoire qui sont présentés dans la Figure 7, avec le BIOS défini sur « entrelacement mémoire canal ». Notez que les modules de mémoire à deux rangées de 16 Go 2667 MT/s utilisés dans ce banc d’essai sont exécutés à 2400 MT/s sur EPYC. La première série de barres de la Figure 7 montre que la bande passante de la mémoire de la plate-forme 2S monte à 244 Go/s lorsque tous les cœurs sont utilisés et à 255,5 Go/s lorsque la moitié des cœurs est utilisée. Le deuxième point de données est la bande passante de la mémoire d’un seul socket ; cela correspond à environ la moitié de celle de la plate-forme 2S, comme prévu. Le troisième point de données mesure la bande passante de mémoire d’un nœud NUMA, une seule puce. Rappelez-vous que chaque socket comporte quatre puces et que la bande passante d’une puce est environ ¼ de celle du support. Au sein d’une puce, il existe deux complexes de cœurs, et la simple utilisation des cœurs sur un complexe de cœurs fournit env. 30 Go/s. Lorsque les cœurs sont utilisés sur les deux complexe de cœurs sur une puce, la bande passante totale de la puce peut être atteinte, soit env. 32 Go/s.

La bande passante de la mémoire de la plate-forme 2S est impressionnante, 240 à 260 Go/s, et est due aux huit canaux de mémoire par socket de la plate-forme. De surcroît un seul cœur peut fournir env. 24,5 Go/s de bande passante de mémoire à la mémoire locale, ce qui est excellent pour la partie des applications à thread unique.

Pour examiner l’impact de la configuration NUMA sur l’accès à distance à la mémoire, la Figure 8 trace la bande passante de la mémoire relative lorsque les cœurs accèdent à la mémoire qui ne se trouve pas dans le même domaine NUMA. L’accès à la mémoire sur le même socket est env. 30 % plus lent, l’accès à la mémoire sur l’autre socket est env. 65 % plus lent. STREAM Triad montre qu’il n’y a apparemment aucun impact notable sur la bande passante de la mémoire lors de l’accès à la mémoire sur le socket distant sur un tronçon (node6 : 1 Infinity Fabric entre les sockets) ou deux tronçons (node4,5,7 : 1 tronçon Infinity Fabric entre les sockets + 1 tronçon local Infinity Fabric). Pour les applications sensibles à la bande passante de la mémoire, un bon emplacement de la mémoire est important pour les performances, même à l’intérieur du même socket.


Figure 8 : Incidence de l’accès à distance à la mémoire
 

---

Test de performance HPL

Nous avons mesuré ensuite la capacité de calcul d’EPYC, telle que mesurée par le benchmark HPL. EPYC peut prendre en charge les instructions AVX et des performances de 8 FLOP/cycle. Sur notre plate-forme, nous avons utilisé Open MPI et les bibliothèques d’algèbre linéaire BLIS pour exécuter HPL.

Les performances théoriques de notre système de test (deux processeurs EPYC 7601) sont de 64 cœurs * 8 FLOPS/cycle * 2,2 GHz de fréquence d’horloge, ce qui donne 1126 GFLOPS. Nous avons mesuré 1133 GFLOPS, ce qui représente une efficacité de 100,6 %.

Nous avons également exécuté HPL sur le EPYC 7551 (32c, 2,0 GHz), EPYC 7351 (16c, 2,4 GHz) et EPYC 7351P (1S, 16c, 2,4 GHz). Dans ces tests, les performances de HPL mesurées étaient de 102 à 106 % des performances théoriques.

Si l’efficacité dépasse 100%, c’est parce que EPYC est capable de supporter des fréquences turbo supérieures à la fréquence de base pendant la durée du test HPL.
 

---

Latence et bande passante InfiniBand

Nous avons ensuite vérifié les résultats de la latence InfiniBand et de la bande passante du micro-test de performance entre deux serveurs. La configuration utilisée pour ces tests est décrite dans le Tableau 1. Les résultats de la latence et de la bande passante se trouvent dans la Figure 9 et dans la Figure 10.


  Tableau 1 : Banc d’essai InfiniBand


Figure 9 : Latence InfiniBand, avec commutateur

Commande exécutée : MPIRun-NP 2--allow-Run-As-root-Host Node1, Node2-MCA PML UCX-x UCX_NET_DEVICES = mlx5_0:1-x UCX_TLS = rc_x-MCA coll_fca_enable 0-MCA coll_hcoll_enable 0-MCA btl_openib_if_include mlx5_0:1-Report-Bindings--bind-to Core--Map-by dist : span-MCA rmaps_dist_device mlx5_0 numactl-cpunodebind = 6 OSU-micro-Benchmarks-5.4.3/MPI/pt2pt/osu_latency

Nous avons pris soin d’attribuer le processus MPI au nœud NUMA le plus proche du HCA. Ces informations sont disponibles dans la sortie lstopo et, dans notre cas, il s’agissait du nœud NUMA 6. Les tests de latence ont été exécutés avec OpenMPI et HPC-X. Avec l’accélération OpenMPI et MXM nous avons mesuré une latence de 1,17 µs, avec OpenMPI et UCX nous avons mesuré une latence de 1,10 µs. Les résultats de la latence obtenus avec HPC-X sont présentés ici.

Dans la Figure 9, la latence sur les processeurs EPYC avec C-states activé est de 1,07 µs et la latence pour toutes les tailles de messages est d’env. 2 à 9 % meilleure avec C-states activé par rapport aux résultats avec C-states désactivé. L’activation de C-states permet aux cœurs inactifs d’être dans des C-states plus profonds, ce qui permet des fréquences turbo plus élevées sur les cœurs actifs, et cela se traduit par une latence réduite.

Les résultats de la bande passante sont présentés dans la Figure 10. Nous avons mesuré la bande passante unidirectionnelle de 12,4 Go/s et la bande passante bidirectionnelle de 24,7 Go/s. Les résultats pour EDR sont conformes aux attentes


Figure 10 : Bande passante InfiniBand

Commande exécutée : 

mpirun -np 2 --allow-run-as-root -host node208,node209 -mca pml ucx -x UCX_NET_DEVICES= mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --bind-to core -mca rmaps_dist_device mlx5_0 --report-bindings --display-map numactl --cpunodebind=6 osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_bibw

 

Tableau 2 : Résultats de osu_mbw_mr (un seul nœud NUMA)
Commande exécutée : 

mpirun -np 16 --allow-run-as-root –host server1,server2 -mca pml ucx -x UCX_NET_DEVICES=mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --report-bindings --bind-to core -mca rmaps_dist_device mlx5_0 numactl cpunodebind= osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

La configuration NUMA décrite à la Figure 3 et la Figure 6 nous a motivé à vérifier l’impact de la localisation des processus sur la bande passante. Pour ce test, nous avons utilisé le test de performance osu_mbw_mr qui mesure la bande passante unidirectionnelle d’agrégation entre plusieurs paires de processus. L’objectif de ce test est de déterminer la bande passante et le débit de messages atteints entre les nœuds NUMA individuels en utilisant l’ensemble des huit cœurs sur le nœud NUMA. Les résultats de ce test sont présentés dans le Tableau 2. La configuration du test a utilisé le profil Performances (C-states désactivé et turbo activé).

Les résultats indiquent que lorsque les processus s’exécutent sur le nœud NUMA qui est connecté à la HCA InfiniBand (nœud NUMA 6), la bande passante cumulée est de 12,3 Go/s. Lorsque des processus s’exécutent sur l’un des trois autres nœuds NUMA qui se trouvent sur le même socket que le HCA (socket 1), la bande passante cumulée est à peu près la même, soit env. 12,1 Go/s. Lorsque des processus sont exécutés sur les nœuds NUMA du socket qui est distant du HCA, la bande passante cumulée passe à env. 6,8 Go/s.

L’ensemble de résultats suivant énuméré dans le Tableau 3 illustre la bande passante unidirectionnelle entre les différents sockets. Pour ce test, tous les 32 cœurs disponibles dans le socket ont été utilisés. Nous avons mesuré 5,1 Go/s lors de l’exécution sur le socket local des HCA, et 2,4 Go/s lors de l’exécution sur le socket distant du HCA. En utilisant tous les 64 cœurs de nos serveurs de test, nous avons mesuré 3,0 Go/s lors de l’exécution de 64 processus par serveur.

Pour doubler ce résultat, nous avons exécuté un test à l’aide des 8 nœuds NUMA sur les deux sockets avec chaque nœud NUMA exécutant 2 processus, ce qui donne un total de 16 processus par serveur. Dans cette configuration, nous avons également mesuré 2,9 Go/s.

Ces résultats indiquent que la topologie du système a une incidence sur les performances de la communication. Cela est particulièrement intéressant pour les cas où un modèle de communication « tous vers tous » avec plusieurs processus communiquant entre les serveurs est un facteur important. Dans le cas d’autres applications, il est possible que la bande passante réduite mesurée lors de l’exécution des processus sur plusieurs domaines NUMA ne soit pas un facteur qui influe sur les performances au niveau de l’application.


  Tableau 3 : Résultats de osu_mbw_br (niveau sockets et système)
Commande exécutée : 

mpirun -np 64 --allow-run-as-root –rf rankfile -mca pml ucx -x UCX_NET_DEVICES= mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --report-bindings osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

 
Commande exécutée :

mpirun -np 128 --allow-run-as-root –rf rankfile -mca pml ucx -x UCX_NET_DEVICES= mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --report-bindings osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

 
Commande exécutée : 

mpirun -np 32 --allow-run-as-root –rf rankfile -mca pml ucx -x UCX_NET_DEVICES= mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --report-bindings osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

---

Performances de HPL au niveau du cluster

Les performances des structures InfiniBand validées, le test suivant consistait à exécuter rapidement HPL sur l’ensemble du cluster. Ces tests ont été effectués sur un système à 16 nœuds avec deux sockets EPYC 7601. Les résultats se trouvent dans la Figure 11 et indiquent l’évolutivité attendue de HPL sur les 16 systèmes.


Figure 11 : HPL sur 16 serveurs

 

---

Performances de WRF au niveau du cluster

Enfin, nous avons exécuté WRF, une application de prévision météorologiques. Le banc d’essai était identique au précédent, un système à 16 nœuds avec deux sockets EPYC 7601. En outre, nous avons effectué des tests sur un système de plus petite taille à quatre nœuds avec deux sockets EPYC 7551. Tous les serveurs disposaient de 16 RDIMM de 16 Go à 2400 MT/s et ont été interconnectés avec Mellanox EDR InfiniBand.


Figure 12 : WRF CONUS 12 km, un seul nœud

Nous avons utilisé WRF v3.8.1 et v3.9.1 et testé les jeux de données CONUS 12 km et CONUS 2,5 km. Nous avons compilé WRF et netcdf à l’aide des compilateurs Intel et utilisé Intel MPI pour l’exécution. Nous avons essayé différents schémas de processus et de « tiling », à l’aide des options de configuration dmpar et dm+sm avec OpenMP.

Nous collaborons avec AMD pour déterminer d’autres options de réglage du compilateur pour WRF.

Il n’y a eu aucune différence de performances mesurée entre WRF v3.8.1 et v3.9.1. En comparant dmpar et dm+sm, on constate qu’une combinaison judicieuse des processus et des « tiles » a permis d’obtenir les mêmes performances. Ceci est illustré dans la Figure 12.


Figure 13 : WRF CONUS 12 km, tests de cluster


Figure 14 : WRF CONUS 2,5 km, tests de cluster

Les tests au niveau du cluster ont été effectués avec WRF v3.8.1 et la configuration dmpar en utilisant tous les cœurs et 8 tiles par exécution.

CONUS 12 km est un jeu de données plus petit et les performances ont atteint un seuil après 8 nœuds, 512 cœurs sur EPYC. Ceci est illustré dans la Figure 13. Les EPYC 7551 et EPYC 7601 sont tous deux des processeurs de 32 cœurs ; la fréquence d’horloge de base du 7601 est 10 % plus rapide que celle du 7551, et sa fréquence turbo sur tous les cœurs 6 % plus rapide. Lors des tests WRF CONUS 12 km, les performances du système EPYC 7601 ont été de 3 % plus rapides que celles du 7551 sur les tests de 1, 2 et 4 nœuds.

CONUS 2,5 km est un jeu de données pour test de performance plus grand ; par rapport au système 1 EPYC, les performances évoluent favorablement jusqu’à 8 nœuds (512 cœurs), puis commencent à décliner. Toujours avec CONUS 2,5 km, le système EPYC 7601 exécute le test 2 à 3 % plus rapidement que le système EPYC 7551 sur les tests de 1, 2 et 4 nœuds, comme illustré dans la Figure 14.

 

---

Conclusion et étapes suivantes

EPYC fournit une bande passante de la mémoire et une densité de cœur par socket optimales. Du point de vue de HPC, nous attendons des applications qui utilisent la bande passante de la mémoire disponible et des cœurs de processeur qui puissent tirer le meilleur parti de l’architecture EPYC. À ce jour, EPYC ne prend pas en charge AVX512 ou AVX2 en un seul cycle ; par conséquent, en présence de code fortement vectorisé qui peut utiliser de manière efficace AVX2 ou AVX512, EPYC n’est peut-être pas idéal.

Des cas d’utilisation qui peuvent utiliser plusieurs disques NVMe bénéficieront également de NVMe directement rattachés, ce qui est possible sur EPYC grâce au nombre de voies PCI-E.

Les étapes suivantes comprennent d’autres tests de performances avec des applications HPC supplémentaires.