AMD EPYC – ytelsesstudie av STREAM, HPL, InfiniBand og WRF

---

Sammendrag

HPC and AI Innovation Lab har en ny klynge med 32 AMD EPYC-baserte systemer som er sammenkoblet med Mellanox EDR InfiniBand. Som alltid utfører vi ytelsesevalueringer på vår nyeste klynge, og ønsker å dele resultatene. Denne bloggen dekker minnebåndbredderesultater fra STREAM, HPL, InfiniBand-mikroytelsesprøve for ventetid og båndbredde, og WRF-resultater fra datasettene for ytelsesprøve.

Vi er interessert i faktisk HPC-applikasjonsytelse på EPYC. Hvis du har datasett som du ønsker å prøve på EPYC, tar du kontakt med Dell-kundeteamet for å få tilgang til Innovation Lab.
 

---

AMD EPYC-arkitektur

AMD EPYC-prosessorer støtter åtte minnekanaler, opptil 16 doble monterte minnemoduler (DIMM-er) per kontakt med to DIMM-er per kanal, og opptil 32 kjerner per kontakt. I tillegg gir en plattform med AMD-CPU-er opptil 128 PCI-E-baner for eksterne enheter som GPU-er og NVMe-stasjoner.
Selve CPU-ene er moduler med flere brikker som er montert fra fire halvlederkomponenter. Hver halvlederkomponent inkluderer opptil åtte Zen-kjerner, to DDR4-minnekanaler og 32 IO-baner. Zen-kjernene på en halvlederkomponent er ordnet i to grupper på fire, og hver gruppe på fire kjerner, kalt et kjernekompleks, deler L3-hurtigbuffer. I en sokkel er alle fire halvlederkomponentene krysskoblet via en sammenhengende sammenkobling som heter Infinity Fabric. Dette vises i figur 1.


Figur 1 – EPYC-sokkeloppsett. CCX er et kjernekompleks av opptil fire kjerner som deler en L3-hurtigbuffer. M* er minnekanalene, to kanaler håndteres av hver halvlederkomponent. P* og G* er IO-baner. ∞ er Infinity Fabric.



På et system med én sokkel gir hver halvlederkomponent opptil 32 PCI-E-baner ved hjelp av P*- og G*-IO-banene som vises i figur 1. Dette gir sokkelen totalt 128 PCI-E-baner, som vist i figur 2. Når en CPU brukes i en konfigurasjon med to sokler (2S), blir halvparten av IO-banene på hver halvlederkomponent brukt til å koble til én av halvlederkomponentene på den andre sokkelen ved hjelp av G* IO-banene som er konfigurert som Infinity Fabric. Dette etterlater sokkelen med P* IO-banene for totalt 64 PCI-E-baner, og dermed fortsatt 128 PCI-E-baner til plattformen. Dette vises i figur 3


Figur 2 – EPYC 1S PCI-E-baner




Figur 3 – EPYC 2S-oppsett




Figur 3 – EPYC 2S-oppsett

 

---

STREAM-ytelsesprøve

Første skritt for å evaluere EPYC var å måle plattformens minnebåndbreddeegenskaper ved hjelp av STREAM-ytelsesprøven. Disse testene ble utført på en Dell EMC PowerEdge R7425-server med to AMD EPYC 7601-prosessorer (32c, 2,2 GHz), 16*16 GB DIMM-er på 2400 MT/s, som kjører Red Hat® Enterprise Linux® 7.5.

NUMA-presentasjonen (ikke-ensartet minnetilgang) av EPYC kan kontrolleres av et BIOS-alternativ som kalles «Memory Interleaving» (Minneinnfelling), og tilordnes ved hjelp av Linux-verktøy som for eksempel numactl og lstopo.

Standard Memory Interleaving-alternativ er «Memory Channel Interleaving» (Minnekanalinnfelling). I denne modusen er de to kanalene på hver halvlederkomponent innfelt. Dette viser fire NUMA-noder per sokkel og åtte NUMA-noder til operativsystemet på et 2S-system.

«Memory Die Interleaving» (Innfelling av minnehalvlederkomponent) er et alternativ der minnet på tvers av alle fire halvlederkomponentene på en sokkel, dvs. åtte minnekanaler, er innfelt. Dette viser én NUMA-node per sokkel og to NUMA-noder på et 2S-system.

«Memory Socket Interleaving» (Minnesokkelinnfelling) bruker minne på tvers av begge soklene, og gir én NUMA-node på en 2S-plattform. Dette tilsvarer at NUMA er deaktivert.    

Når du bruker minnekonfigurasjonen «Memory Channel Interleaving» (Minnekanalinnfelling), må du huske på at hver sokkel har fire halvlederkomponenter, at hver halvlederkomponent gir to minnekanaler, og at BIOS presenterer åtte NUMA-noder på en 2S-plattform. Eksempelet på numactl-utdata i figur 4 viser disse åtte NUMA-nodene på en 2S-plattform, én NUMA-node per halvlederkomponent.


Figur 4 – numactl-utdata på 2S EPYC


Fysisk sett er det fire NUMA-avstander på plattformen, som uthevet i figur 4: til selve NUMA-noden (avstand «10» i rødt), til de tre nodene som deler samme halvlederkomponent (avstand «16» i blått), til noden på den andre sokkelen som er koblet til direkte via en Infinity Fabric-kobling (avstand «22» i grønt), og til de tre andre nodene på den eksterne sokkelen som du får tilgang til via to hopp når du bruker Infinity Fabric mellom de to soklene, samt den interne Infinity Fabric-koblingen (avstand «28» i svart).

Noen BIOS-implementeringer og -versjoner kan forenkle denne fysiske utformingen og bare presentere tre NUMA-avstander til operativsystemet. Denne forenklingen omfatter maskering av avstandsforskjellen mellom NUMA-node 0 (som et eksempel) og NUMA-nodene 4, 5, 6, 7, ved å presentere NUMA-nodene 4, 5, 6, 7 med lik avstand fra NUMA-node 0. En slik implementering vises i figur 5. NUMA-oppsettet vil være et justerbart alternativ i den neste utgaven av PowerEdge R7425 BIOS. Forenkling av NUMA-nodeavstandene endrer ikke den fysiske utformingen av kjernene, og er hovedsakelig til fordel for OS-planleggeren. For HPC- og MPI-jobber som er NUMA-følsomme, skal disse presentasjonene være uvesentlige.


Figur 5 – numactl-utdata på 2S EPYC med forenklede NUMA-avstander


I tillegg til de åtte NUMA-nodene på en plattform med to sokler, viser figur 4 og 5 også minne og kjerner som er tilknyttet hver NUMA-node. Hver NUMA-node har 32 GB minne fra to 16 GB DIMM-er (16 DIMM-er i serveren, 8 per sokkel, 1 DIMM per kanal). Hver NUMA-node inneholder de åtte kjernene til den lokale halvlederkomponenten. Kjernenummereringen på Dell EMC-plattformen er en ringdistribusjon som går på tvers av alle NUMA-noder først. og deretter fyller hver NUMA-node.

I tillegg kan lstopo-utdata brukes til å tydelig vise hvilket sett med fire kjerner som utgjør et kjernekompleks. Dette er de fire kjernene på en halvlederkomponent som deler L3-hurtigbuffer. For eksempel, figur 6 viser at NUMA-node 0 har åtte kjerner, og på denne NUMA-noden deler kjernene 0, 16, 32, 48 L3-hurtigbuffer, mens kjernene 8, 24, 40, 56 deler L3-hurtigbuffer.


Figur 6 – lstopo-utdata på 2S EPYC


Figur 7 – AMD EPYC-plattformens minnebåndbredde

Med informasjonen om NUMA-oppsettet i tankene, presenteres resultatene av STREAM Triad-ytelsesprøven for minnebåndbredde i figur 7, med BIOS stilt inn på «Memory Channel Interleaving» (Minnekanalinnfelling). Vær oppmerksom på at minnemodulene på 16 GB 2667 MT/s med dobbeltnivå som brukes i dette testmiljøet, kjører ved 2400 MT/s på EPYC. Det første stolpesettet i figur 7 viser at minnebåndbredden til 2S-plattformen er 244 GB/s når alle kjernene brukes, og 255,5 GB/s når halvparten av kjernene brukes. Det andre datapunktet er minnebåndbredden til én enkelt sokkel, og som forventet er dette ca. halvparten av hele 2S-plattformen. Det tredje datapunktet måler minnebåndbredden til en NUMA-node, en individuell halvlederkomponent. Husk på at hver sokkel har fire halvlederkomponenter, og båndbredden til halvlederkomponenten er ca. ¼ av sokkelens båndbredde. Det er to kjernekomplekser i en halvlederkomponent, og hvis du bare bruker kjernene i ett kjernekompleks, gir dette ~30 GB/s. Når kjerner brukes på tvers av begge kjernekompleksene på en halvlederkomponent, kan hele båndbredden til halvlederkomponenten, ~32 GB/s, oppnås.

Minnebåndbredden til 2S-plattformen er hele 240–260 GB/s, og er et resultat av de åtte minnekanalene per sokkel på plattformen. Én enkelt kjerne kan gi ~24,5 GB/s av minnebåndbredden til lokalt minne, noe som er ypperlig for den enkelttrådede delen av applikasjoner.

Med utgangspunkt i effekten NUMA-oppsettet har på ekstern minnetilgang, tegner figur 8 den relative minnebåndbredden når kjernene får tilgang til minne som ikke er i samme NUMA-domene. Tilgang til minne på samme sokkel er ~30 % tregere, og tilgang til minne på den andre sokkelen er ~65 % tregere. Når du bruker STREAM Triad, ser det ut til at det ikke er noen målbar effekt på båndbredden når du får tilgang til den eksterne sokkelen i ett hopp (node 6, 1 Infinity Fabric mellom soklene) eller to hopp (node 4, 5, 7 – 1 Infinity Fabric-hopp mellom soklene + 1 lokalt Infinity Fabric-hopp). Når det gjelder applikasjoner som er følsomme for båndbredde, er god minneplassering viktig for ytelsen, selv innenfor samme sokkel.


Figur 8 – påvirkning på ekstern minnetilgang
 

---

HPL-ytelsesprøve

Deretter målte vi databehandlingskapasiteten til EPYC som målt av HPL-ytelsesprøven. EPYC kan støtte AVX-instruksjoner og ytelse på 8 flyttallsoperasjoner (FLOP) per syklus. På plattformen vår brukte vi Open MPI og de lineære BLIS-algebrabibliotekene for å kjøre HPL.

Den teoretiske ytelsen til testsystemet vårt (to EPYC 7601-prosessorer) er 64 kjerner * 8 flyttallsoperasjoner per syklus * 2,2 GHz klokkefrekvens, noe som gir 1126 GFLOP-er. Vi målte 1133 GLOP-er, noe som utgjør en effektivitet på 100,6 %.

Vi kjø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 testene var den målte HPL-ytelsen 102–106 % av teoretisk ytelse.

Effektiviteten er over 100 % fordi EPYC kan opprettholde turbofrekvenser over grunnfrekvensen mens HPL-testen pågår.
 

---

InfiniBand-ventetid og -båndbredde

Deretter verifiserte vi resultatene av InfiniBand-mikroytelsesprøven for ventetid og båndbredde mellom to servere. Konfigurasjonen som brukes for disse testene, er beskrevet i tabell 1. Du finner resultat- og båndbredderesultater i figur 9 og figur 10.


  Tabell 1 – InfiniBand-testmiljø


Figur 9 – InfiniBand-ventetid, med svitsj

Kjør følgende kommando: 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

Vi var nøye med å feste MPI-prosessen til NUMA-noden som er nærmest HCA-en. Denne informasjonen er tilgjengelig i lstopo-utdataene, og i vårt tilfelle var det NUMA-node 6. Ventetidstester ble kjørt med både OpenMPI og HPC-X. Med OpenMPI og MXM-akselerasjon målte vi en ventetid på 1,17 µs. Med OpenMPI og UXS målte vi en ventetid på 1,10 µs. Ventetidresultatene som ble hentet med HPC-X, vises her.

Fra figur 9 er ventetiden på EPYC-prosessorer med C-tilstander aktivert 1,07 µs, og ventetiden for alle meldingsstørrelser er ~2 til 9 % bedre med C-tilstander aktivert, sammenlignet med når C-tilstander er deaktivert. Når C-tilstander er aktivert, kan inaktive kjerner være i dypere C-tilstander. Dette gir høyere turbofrekvenser på de aktive kjernene, noe som resulterer i redusert ventetid.

Båndbredderesultatene vises i figur 10. Vi målte enveis båndbredde på 12,4 GB/s og toveis båndbredde på 24,7 GB/s. Disse resultatene er som forventet for EDR


Figur 10 – InfiniBand-båndbredde

Kjør følgende kommando: 

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

 

Tabell 2 – resultater av osu_mbw_mr – enkel NUMA-node
Kjør følgende kommando: 

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-oppsettet som er beskrevet i figur 3 og figuren 6, fikk oss til å kontrollere effekten av prosesslojalitet på båndbredden. For denne testen brukte vi ytelsesprøven osu_mbw_mr som måler aggregert toveis båndbredde mellom flere par med prosessorer. Målet med denne testen er å fastslå den oppnådde båndbredden og meldingshastigheten mellom individuelle NUMA-noder ved hjelp av alle de åtte kjernene på NUMA-noden. Resultatene av denne testen vises i tabell 2. Testkonfigurasjonen brukte ytelsesprofil (C-tilstander deaktivert og turbo aktivert).

Resultatene viser at når prosessorene kjører på NUMA-noden som er koblet til InfiniBand HCA (NUMA-node 6), er den aggregerte båndbredden 12,3 GB/s. Når det kjøres prosesser på noen av de tre andre NUMA-nodene som er på samme sokkel som HCA (kontakt 1), er den aggregerte båndbredden omtrent den samme, ~12,1 GB/s. Når det kjøres prosesser på NUMA-noder i sokkelen som er ekstern for HCA, faller den aggregerte båndbredden til ~6,8 GB/s.

Det neste settet med resultater som vises i tabell 3, viser enveis båndbredde mellom individuelle sokler. I denne testen ble alle de 32 tilgjengelige kjernene i sokkelen brukt. Vi målte 5,1 GB/s ved kjøring på sokkelen som er lokal for HCA, og 2,4 GB/s ved kjøring på sokkelen som er ekstern for HCA. Når vi brukte alle de 64 kjernene i testserverne våre, målte vi 3,0 GB/s når vi kjørte 64 prosesser per server.

For å dobbeltsjekke dette siste resultatet kjørte vi en test som bruker alle åtte NUMA-nodene på tvers av begge soklene, og hver NUMA-node kjører to prosesser, noe som gir totalt 16 prosesser per server. Med dette oppsettet målte vi også 2,9 GB/s.

Disse resultatene indikerer at topologien til systemet har innvirkning på kommunikasjonsytelsen. Dette er interessant for saker der et kommunikasjonsmønster med flere prosesser som kommuniserer på tvers av servere, er en viktig faktor. For andre applikasjoner er det mulig at den reduserte båndbredden som ble målt ved kjøring av prosesser på flere NUMA-domener, ikke er en faktor som påvirker ytelsen på applikasjonsnivå.


  Tabell 3 – resultater av osu_mbw_br – sokler og systemnivå
Kjør følgende kommando: 

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

 
Kjør følgende kommando:

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

 
Kjør følgende kommando: 

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-ytelse på klyngenivå

Når ytelsen til InfiniBand-strukturen vår var validert, var den neste testen å raskt kjøre HPL på tvers av klyngen. Disse testene ble utført på et system med 16 noder og EPYC 7601 med dobbel sokkel. Resultatene er oppført i figur 11 og viser forventet HPL-skalerbarhet på tvers av de 16 systemene.


Figur 11 – HPL på tvers av 16 servere

 

---

WRF-ytelse på klyngenivå

Til slutt kjørte vi WRF, en værmeldingsapplikasjon. Testmiljøet var det samme som før, et system med 16 noder og EPYC 7601 med to sokler. I tillegg utført vi også noen tester på et mindre system med fire noder og EPYC 7551 med to sokler. Alle serverne hadde 16 GB*16 RDIMM-er som kjørte ved 2400 MT/s, og var sammenkoblet med Mellanox EDR InfiniBand.


Figur 12 – WRF conus 12 km, enkel node

Vi brukte WRF v3.8.1 og v3.9.1, og testet datasettene conus 12 km og conus 2,5 km. Vi kompilerte WRF og netcdf ved hjelp av Intel-kompilatorer, og kjørte dem med Intel MPI. Vi prøvde ulike prosess- og mosaikkoppsett ved hjelp av både dmpar og konfigureringsalternativet dm+sm med OpenMP.

Vi arbeider med AMD for å fastsette andre kompilatorjusteringsalternativ for WRF.

Vi målte ingen ytelsesforskjell mellom WRF v3.8.1 og v3.9.1. Når vi sammenlignet dmpar og dm+sm, resulterte en skjønnsom kombinasjon av prosesser og fliser i omtrent den samme ytelsen. Dette vises i figur 12.


Figur 13: WRF conus 12 km, klyngetester


Figur 14: WRF conus 2,5 km, klyngetester

Testene på klyngenivå ble utført med WRV v3.8.1 og dmpar-konfigurasjonen ved hjelp av alle kjernene og åtte fliser per kjøring.

Conus 12 km er et mindre datasett, og ytelsen flatet ut etter 8 noder, 512 kjerner på EPYC. Dette vises i figur 13. EPYC 7551 og EPYC 7601 er begge 32-kjernede prosessorer med 7601-grunnklokkefrekvensen og turbofrekvens for alle kjerner som er henholdsvis 10 og 6 % raskere enn 7551. På WRF conus 12 km-testene var ytelsen til EPYC 7601-systemet 3 % raskere enn 7551 på testene med én, to og fire noder.

Conus 2,5 km er et større datasett for ytelsesprøve. I forhold til 1 EPYC-systemet skaleres ytelsen opptil 8 noder (512 kjerner), og deretter begynner den å synke. Med conus 2,5 km har EPYC 7601-systemet 2–3 % raskere ytelse enn EPYC 7551 på tester med én, to og fire noder, som vist i figur 14.

 

---

Konklusjon og neste trinn

EPYC gir god minnebåndbredde og kjernetetthet per sokkel. Fra et HPC-synspunkt forventer vi at applikasjoner som kan bruke tilgjengelig minnebåndbredde og tilgjengelige CPU-kjerner, vil dra mest nytte av EPYC-arkitekturen. EPYC i dag støtter ikke AVX512 eller AVX2 i én enkelt syklus, så koder som er svært vektoriserte og kan bruke AVX2 eller AVX512 effektivt, er kanskje ikke ideelle for EPYC.

Brukstilfeller som kan bruke flere NVMe-stasjoner, kan også dra nytte av direkte tilkoblet NVMe som er mulig takket være antallet PCI-E-baner på EPYC.

Våre neste trinn omfatter ytterligere ytelsestester med flere HPC-applikasjoner.