AMD EPYC – Ydeevneundersøgelse af STREAM, HPL, InfiniBand og WRF

---

Overblik

HPC og AI Innovation Lab har en ny klynge med 32 AMD EPYC-baserede systemer, der er forbundet med Mellanox EDR Infiniband. Som altid udfører vi ydelsesevalueringer på vores nyeste klynge og vil gerne fortælle om vores resultater. Denne blog dækker hukommelsesbåndbredderesultater fra STREAM, HPL, InfiniBand Micro-benchmarkydelse for ventetid og båndbredde og WRF-resultater fra benchmark-datasættet.

Vi er interesserede i HPC-programmets reelle ydeevne på EPYC. Hvis du har datasæt, du ønsker at prøve af på EPYC, skal du kontakte din Dell Kundeservice for at få adgang til Innovation Lab.
 

---

AMD EPYC-arkitektur

AMD EPYC-processorer understøtter otte hukommelseskanaler, op til 16 dual in-line-hukommelsesmoduler (DIMM'er) pr. sokkel med to DIMM'er pr. kanal og op til 32 kerner pr. sokkel. Derudover leverer en platform med AMD-CPU'er op til 128 PCI-E-baner til eksterne enheder som GPU'er og NVMe-drev.
Selve CPU'erne er multi-chip moduler, der er samlet af fire matricer. Hver matrice inkluderer op til otte Zen-kerner, to DDR4-hukommelseskanaler og 32 IO-baner. Zen-kernerne på en matrice er arrangeret i to grupper af fire, hvor hver gruppe af fire kerner, kaldet et kernekompleks deler L3-cachelageret. I en sokkel er alle fire matricer krydsforbundet via en sammenhængende tilslutning kaldet Infinity Fabric. Dette vises i Figur 1.


Figur 1 – EPYC-sokkellayout. CCX er et kernekompleks af op til 4 kerner, der deler L3-cachelageret. M* er hukommelseskanalerne, to kanaler, der håndteres af hver matrice. P* og G* er IO-baner. ∞ er Infinity Fabric.



I et enkeltsokkelsystem forsyner hver matrice op til 32 PCI-E-baner vha. P* og G* IO-banerne vist i Figur 1. Dette giver soklen en total på 128 PCI-E-baner som vist i Figur 2. Når en CPU anvendes i en konfiguration med to sokler (2S), anvendes halvdelen af IO-banerne i hver matrice til at tilslutte til en af banerne på den anden sokkel ved hjælp af G* IO-banerne, der er konfigureret som Infinity Fabric. Dette efterlader soklen med P* IO-baner til et samlet antal af 64 PCI-E-baner og dermed stadig 128 PCI-E-baner til platformen. Dette vises i Figur 3


Figur 2 – EPYC 1S PCI-E-baner




Figur 3 – EPYC 2S-layout




Figur 3 – EPYC 2S-layout

 

---

STREAM benchmark-ydelse

Som det første skridt til at evaluere EPYC, målte vi platformens hukommelsesbåndbredde ved hjælp af STREAM-benchmarket. Disse test blev udført på en Dell EMC PowerEdge R7425-server med Dual AMD EPYC 7601-processorer (32c, 2,2 GHz), 16*16 GB DIMM'er ved 2400 MT/s, der kørte Red Hat® Enterprise Linux® 7.5.

NUMA-præsentationen (non-uniform memory access) af EPYC kan styres med en BIOS-indstilling, der kaldes "hukommelsesindfletning" og afbildet med Linux-hjælpeprogrammer som f.eks. numactl og lstopo.

Standard hukommelsesindfletningsindstillingen er ”hukommelseskanalindfletning”. I denne tilstand er de to kanaler for hver matrice indflettet. Dette præsenterer fire NUMA-knuder pr. sokkel og otte NUMA-knuder til operativsystemet på et 2S-system.

"Hukommelsesmatriceindfletning" er en indstilling, hvor hukommelsen på tværs af alle fire matricer på en sokkel, dvs. otte hukommelseskanaler, er indflettet. Dette præsenterer en NUMA-knude pr. sokkel og to NUMA-knuder på et 2S-system.

"Hukommelsesmatriceindfletning" over begge sokler, der giver en NUMA-knude på en 2S-platform. Det ville svare til deaktiveret NUMA.    

Ved brug af standardkonfigurationen af "hukommelseskanalindfletning", husk, at hver sokkel har fire matricer, hver matrice forsyner to hukommelseskanaler, og BIOS'en præsenterer otte NUMA-knuder på en 2S-platform. Eksemplet på numactl-output i Figur 4 viser disse otte NUMA-knuder på en 2S platform, en NUMA-knude pr. matrice.


Figur 4 – numactl-output på 2S EPYC


Fysisk er der fire NUMA-afstande på platformen som fremhævet i Figur 4: til selve NUMA-knuden (afstand "10" i rødt) til de tre knuder, der deler den samme matrice (afstand "16" i blåt), til knuden på den anden sokkel, der er direkte forbundet via et Infinity Fabric-link (afstand "22" i grønt) til de tre andre knuder på fjernsoklen, som tilgås via to hop vha. Infinity Fabric mellem de to sokler samt det interne Infinity Fabric-link (afstand "28" i sort).

Nogle BIOS-implementeringer og -versioner kan forenkle dette fysiske layout og præsenterer kun tre NUMA-afstande til operativsystemet. Denne forenkling omfatter maskering af forskellen i afstand mellem NUMA-knude 0 (som et eksempel) og NUMA-knuder 4, 5, 6, 7 ved at præsentere NUMA-knuderne 4, 5, 6, 7 som ækvidistante i forhold til NUMA-knude 0. En sådan implementering er vist i Figur 5. NUMA-layoutet vil være en justerbar indstilling i næste udgave af PowerEdge R7425 BIOS. Forenkling af NUMA-knudeafstande ændrer ikke kernernes faktiske fysiske layout, det er primært af hensyn til OS-planlægningen. For HPC- og MPI-job, der er bekendte med NUMA, burde disse forskellige præsentationer være uvæsentlige.


Figur 5 – numactl-output på 2S EPYC med forenklede NUMA-afstande


Ud over de 8 NUMA-knuder på en platform med to sokler viser Figur 4 og Figur 5 også den hukommelse og de kerner, der er forbundet med hver NUMA-knude. Hver NUMA-knude har 32 GB hukommelse fra to 16 DIMM'er (16 DIMM'er i serveren, otte pr. sokkel, 1 DIMM pr. kanal). Hver NUMA-knude indeholder den lokale matrices otte kerner. Core-optællingen på Dell EMC-platformen er Round Robin, der går på tværs af alle NUMA-knuder først og derefter udfylder hver NUMA-knude.

Derudover kan lstopo-output bruges til klart at vise, hvilke sæt af fire kerner, der udgør et kernekompleks. Dette er de fire kerner på en matrice, der deler L3-cachen. F.eks. viser Figur 6, at NUMA-knude 0 har otte kerner og på denne NUMA-knude deler kernerne 0, 16, 32 og 48 L3-cachen, og kernerne 8, 24, 40 og 56 deler L3-cachen.


Figur 6 – lstopo-output på 2S EPYC


Figur 7 – AMD EPYC platform-hukommelsesbåndbredde

Med tanke på denne NUMA-layoutinformation præsenteres STREAM Triad benchmark-resultaterne for hukommelsesbåndbredde i Figur 7 med BIOS indstillet til "hukommelseskanalindfletning". Bemærk, at 16 GB 2667 MT/s Dual Rank-hukommelsesmodulerne, der anvendes i denne testbænk, kører med 2400 MT/s på EPYC. Det første sæt bjælker i Figur 7 viser, at hukommelsesbåndbredden for 2S-platformen er 244 GB/s, når alle kerner bruges, og 255,5 GB/s, når halvdelen af kernerne bruges. Det andet datapunkt er hukommelsesbåndbredden for en enkelt sokkel, og den er omkring halvdelen af den fulde 2S-platform, som forventet. Det tredje datapunkt måler hukommelses båndbredden for en NUMA-knude, en selvstændig matrice. Husk, at hver sokkel har fire matricer, og at båndbredden for en matrice er omkring en ¼. del af en sådan sokkel. I en matrice er der to kernekomplekser, og hvis man kun bruger kernerne i ét kernekompleks giver det ~ 30GB/s. Når kernerne i begge kernekomplekser på en matrice anvendes, kan den fulde båndbredde for matricen opnås, ~ 32 GB/s.

2S-platformens hukommelsesbåndbredde er imponerende, 240-260 GB/s, og er resultatet af de otte hukommelseskanaler pr. sokkel på platformen. Så meget desto mere fordi en enkelt kerne kan levere ~ 24,5 GB/s hukommelsesbåndbredde til lokal hukommelse, hvilket er perfekt for den enkelttrådede del af programmerne.

Figur 8 ser på påvirkningen af NUMA-layoutet på Remote Memory Access og indtegner den relative hukommelsesbåndbredde, når kerner, som ikke er i det samme NUMA-domæne, kommer ind i hukommelsen. Adgang til hukommelsen på den samme sokkel er ~30 % langsommere, adgang til hukommelsen på den anden sokkel er ~65 % langsommere. Ved brug af STREAM Triad ser det ud som om, der ikke er målbare virkninger på hukommelsesbåndbredden, når der opnås adgang til hukommelsen på fjernsoklen over et hop (node6, 1 Infinity Fabric mellem soklerne) eller to hop (node4, 5, 7 - 1 Infinity Fabric-hop mellem soklerne + 1 et lokalt Infinity Fabric-hop). For hukommelsesbåndbreddefølsomme programmer vil god hukommelseslokalitet være vigtig for ydeevnen selv indenfor den samme sokkel.


Figur 8 – Virkning af Remote Memory Access
 

---

HPL benchmark-ydelse

Derefter målte vi beregningsevnen for EPYC som målt af HPL-benchmarket. EPYC kan understøtte AVX-instruktioner og ydeevne med 8 FLOP/cyklus. På vores platform brugte vi Open MPI og BLIS lineære algebra-biblioteker til at køre HPL.

Vores testsystems teoretiske ydeevne (dual EPYC 7601-processorer) er 64 kerner * 8 FLOP/cyklus * 2,2 GHz clockfrekvens, hvilket giver 1126 GFLOPS. Vi målte 1133 GLOPS, som svarer til en effektivitet på 100,6 %.

Vi kørte også HPL på EPYC 7551 (32c, 2,0 GHz), EPYC 7351 (16c, 2,4 GHz) og EPYC 7351P (1S, 16c, 2,4 GHz). I disse test var den målte HPL-ydeevne 102-106 % af den teoretiske ydeevne.

Effektiviteten er over 100 %, fordi EPYC er i stand til at opretholde turbofrekvenser over basisfrekvensen under hele HPL-testen.
 

---

InfiniBand-ventetid og -båndbredde

Vi undersøgte dernæst mikrobenchmarkresultaterne for InfiniBand-ventetid og -båndbredde mellem to servere. Konfigurationen, der anvendes til disse test, er beskrevet i Tabel 1. Ventetids- og båndbredderesultaterne kan ses i Figur 9 og Figur 10.


  Tabel 1 – InfiniBand-testbænk


Figur 9 – InfiniBand ventetid, med switch

Kør kommandoen: 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

Der blev sørget for at fastgøre MPI-processen til den NUMA-knude, der er tættest på HCA’en. Disse oplysninger er tilgængelige i lstopo-outputtet, og i vores tilfælde var det NUMA-knude 6. Ventetidstest blev kørt med både OpenMPI og HPC-X. Med OpenMPI & MXM-acceleration målte vi ventetiden til 1,17µs, med OpenMPI & UCX målte vi ventetiden til 1,10µs. Ventetidsresultaterne, der blev opnået med HPC-X, vises her.

Af Figur 9 fremgår, at ventetiden for EPYC-processorer med C-tilstande aktiveret er 1,07µs, og ventetiden for alle meddelelsesstørrelser er ~2 til 9 % bedre med C-tilstande aktiveret sammenlignet med C-tilstande deaktiveret. Aktiverede C-tilstande giver inaktive kerner mulighed for at være i dybere C-tilstande, hvilket giver mulighed for højere turbofrekvenser på de aktive kerner, hvilket igen resulterer i reduceret ventetid.

Båndbredderesultaterne ses i Figur 10. Vi målte 12,4 GB/s envejsbåndbredde og 24,7 GB/s tovejsbåndbredde. Disse resultater er som forventet for EDR


Figur 10 – InfiniBand-båndbredde

Kør kommandoen: 

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

 

Tabel 2 – osu_mbw_mr-resultater – enkelt NUMA-node
Kør kommandoen: 

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

NUMA-layoutet beskrevet i Figur 3 og Figur 6 fik os til at kontrollere betydningen af proceslokalitet for båndbredden. Til denne test brugte vi osu_mbw_mr-benchmarken, der måler samlet envejsbåndbredde mellem flere procespar. Formålet med denne test er at bestemme den opnåede båndbredde og meddelelseshastighed mellem individuelle NUMA-knuder, når alle otte kerner på NUMA-knuden bruges. Resultaterne af denne test kan ses i Tabel 2. Testkonfigurationen brugte ydeevneprofil (C-tilstande deaktiveret og turboaktiveret).

Resultaterne viser os, at når processer kører på NUMA-knuden, der er forbundet til InfiniBand HCA’en (NUMA-node 6), er den samlede båndbredde 12,3 GB/s. Når processer kører på en hvilken som helst af de andre tre andre NUMA-knuder, der er på den samme sokkel som HCA’en (sokkel 1), er den samlede båndbredde ca. de samme ~12,1 GB/s. Når processerne køres på NUMA-knuderne i den sokkel, som er fjern fra HCA’en, falder den samlede båndbredde til ~6,8 GB/s.

Det næste sæt af resultater vist i Tabel 3 viser envejsbåndbredden mellem individuelle sokler. Til denne test blev alle 32 kerner, der var tilgængelige i soklen, brugt. Vi målte 5,1 GB/s, når kørslen blev foretaget på soklen lokalt på HCA’en, og 2,4 GB/s, når den blev foretaget på soklen fjern fra HCA’en. Ved brug af alle 64 kerner i vores testservere, målte vi 3,0 GB/s, når der blev kørt 64 processer pr. server.

For at kontrollere dette sidste resultat, kørte vi en test med alle 8 NUMA-knuder på tværs af begge sokler, hvor hver NUMA-knude kørte 2 processer, hvilket i alt blev til 16 processer pr. server. Med dette layout målte vi også 2,9 GB/s.

Disse resultater viser, at systemtopologien har en betydning for kommunikationsydeevnen. Dette er interessant i tilfælde, hvor et alt-til-alt kommunikationsmønster med flere processer, der kommunikerer på tværs af servere, er en vigtig faktor. For andre programmer er det muligt, at den reducerede båndbredde, der måltes ved kørsel af processer på flere NUMA-domæner, ikke er en faktor, der påvirker ydelsen på programniveau.


  Tabel 3 – osu_mbw_brde-resultater – sokler og systemniveau
Kør kommandoen: 

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

 
Kør kommandoen:

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

 
Kør kommandoen: 

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

---

HPL-ydeevne på klyngeniveau

Med vores InfiniBand-Fabric-ydeevne valideret, var den næste test hurtigt at køre HPL på tværs af klyngen. Disse test blev udført på et 16-knude-system med EPYC 7601 med to sokler. Resultaterne ses i Figur 11 og viser den forventede HPL-skalerbarhed over 16 systemer.


Figur 11 – HPL over 16 servere

 

---

WRF-ydeevne på klyngeniveau

Til sidst kørte vi WRF, et vejrprognoseprogram. Testbænken var den samme som før, 16-knude-system med EPYC 7601 med to sokler. Og vi foretog også nogle test af et mindre 4-knudesystem med EPYC 7551 med to sokler. Alle servere havde 16 GB * 16 RDIMM'er, der kørte med 2400 MT/s og var forbundet med Mellanox EDR InfiniBand.


Figur 12 – WRF conus 12km, enkeltknude

Vi brugte WRF v 3.8.1 og v 3.9.1 og testede datasættene conus 12 km og conus 2,5 km. Vi kompilerede WRF og netcdf ved brug af Intel-compilere og kørte med Intel MPI. Vi afprøvede forskellige proces- og fliseskemaer ved brug af både dmpar- og dm+sm-konfigurationsindstilling med OpenMP.

Vi arbejder med AMD for at finde andre compiler-justeringsindstillinger til WRF.

Der måltes ikke nogen forskel i ydeevnen mellem WRF v 3.8.1 og v 3.9.1. Når man sammenlignede dmpar med dm+sm, resulterede en velovervejet kombination af processer og fliser i den samme ydeevne. Dette vises i Figur 12.


Figur 13 – WRF conus 12km, klyngetest


Figur 14 – WRF conus 2,5km, klyngetest

Test på klyngeniveau blev udført med WRV v 3.8.1 og dmpar-konfigurationen med brug af alle kerner og 8 fliser pr. kørsel.

Conus 12 km er et mindre datasæt ydeevnen fladede ud efter 8 knuder, 512 kerner på EPYC. Dette vises i Figur 13. EPYC 7551 og EPYC 7601 er begge 32-kerne processorer med 7601 basisclockfrekvens og all-core turbofrekvens og er henholdsvis 10 % og 6 % hurtigere end 7551. På WRF conus 12 km-tests var ydeevnen for EPYC 7601-systemet 3 % hurtigere end 7551 på 1-, 2- og 4- knudetests.

Conus 2,5 km er et større benchmark-datasæt og i forhold til 1 EPYC-system skalerer ydeevnen godt op til 8 knuder (512 kerner) og begynder derefter at aftage. Med conus 2,5 km kører EPYC 7601-systemet også 2-3 % hurtigere end EPYC 7551 på 1-, 2- og 4-knudetests som vist i Figur 14.

 

---

Konklusion og næste skridt

EPYC giver en god hukommelsesbåndbredde og kernetæthed pr. sokkel. Fra et HPC-synspunkt forventer vi programmer, der kan gøre brug af den tilgængelige hukommelsesbåndbredde og CPU-kerner for at kunne udnytte EPYC-arkitekturen mest muligt. I dag understøtter EPYC ikke AVX512 eller AVX2 i en enkelt cyklus, så koder, der er meget vektoriserede og kan bruge AVX2 eller AVX512 effektivt, er muligvis ikke ideelle til EPYC.

Hvis man bruger sager, der kan udnytte flere NVMe-drev, kan man også drage fordel af den direkte tilsluttede NVMe, hvilket er muligt på grund af antallet af PCI-E-baner på EPYC.

Vores næste skridt omfatter yderligere ydeevnetests med flere HPC-programmer.