AMD EPYC – Prestandaanalys av STREAM, HPL, InfiniBand och WRF

---

Sammanfattning

HPC and AI Innovation Lab har ett nytt kluster med 32 AMD EPYC-baserade system sammankopplade med Mellanox EDR InfiniBand. Som alltid genomför vi utvärderingar av prestandan på våra senaste kluster och vill dela med oss av resultaten. Den här bloggen tar upp resultaten för minnesbandbredd från STREAM, HPL, InfiniBand mikro-prestandatest för latens och bandbredd samt WRF-resultaten från prestandatestets datauppsättningar.

Vi är intresserade av verklighetens HPC-programprestanda på EPYC. Om du har datauppsättningar som du vill testa på EPYC kan du kontakta teamet för ditt Dell-konto för åtkomst till Innovation Lab.
 

---

AMD EPYC-arkitektur

AMD EPYC-processorer har stöd åtta för minneskanaler, upp till 16 dubbla inbyggda minnesmoduler (DIMM) per sockel, med två DIMM:er per kanal och upp till 32 kärnor per sockel. En plattform med AMD-processorer erbjuder dessutom upp till 128 PCI-E-banor för kringutrustning som GPU:er och NVMe-enheter.
Själva processorerna är multichipmoduler monterade från fyra matriser. Varje matris innefattar upp till arton Zen-kärnor, två DDR4-minneskanaler och 32 IO-banor. Zen-kärnorna i en matris är ordnade i två grupper om fyra, där varje grupp med fyra kärnor, kallade kärnkomplex, delar L3-cache. I en sockel är alla fyra matriser korsanslutna via en sammanhängande sammankoppling som kallas Infinity Fabric. Detta visas på bild 1.


Bild 1 – layout över EPYC-sockel. CCX är ett kärnkomplex med upp till fyra kärnor som delar L3-cache. M* är minneskanalerna, två kanaler hanteras av vardera matris. P* och G* är IO-banor. ∞ är Infinity Fabric.



I ett system med en enda sockel ger vardera matris upp till 32 PCI-E-banor med P*- och G* IO-banorna som visas på bild 1. Detta ger sockeln totalt 128 PCI-E-banor, som visas i bild 2. När en processor används i en konfiguration med två socklar (2S) används hälften av IO-banorna för vardera matris till att ansluta till en av matriserna på den andra sockeln med hjälp av G* IO-banorna som konfigurerats som Infinity Fabric. Detta ger sockeln med P* IO-banorna totalt 64 PCI-E-banor och därmed ändå 128 PCI-E-banor för plattformen. Detta visas i bild 3


Bild 2 – EPYC 1S PCI-E-banor




Bild 3 – EPYC 2S-layout




Bild 3 – EPYC 2S-layout

 

---

STREAM-prestandatest

Som ett första steg för att utvärdera EPYC mätte vi kapaciteten för minnesbandbredd för plattformen med hjälp av STREAM-prestandatestet. Dessa tester utfördes på en Dell EMC PowerEdge R7425-server med dubbla AMD EPYC 7601-processorer (32c, 2,2 GHz), 16*16 GB DIMM:er vid 2 400 MT/s, som körde Red Hat® Enterprise Linux® 7.5.

NUMA-presentationen (Non-Uniform Memory Access) för EPYC kan styras ett BIOS-alternativ som kallas ”Memory Interleaving” och mappas med hjälp av Linux-funktioner som numactl och lstopo.

Standardalternativet för Memory Interleaving är Memory Channel Interleaving. I det här läget överlagras de två kanalerna för vardera matris. Detta presenterar fyra NUMA-noder per sockel och åtta NUMA-noder för operativsystemet på ett 2S-system.

Memory Die Interleaving är ett alternativ där minnet i alla fyra matriser på en sockel, dvs. åtta minneskanaler, överlagras. Detta presenterar en NUMA-nod per sockel och två NUMA-noder på ett 2S-system.

Memory Socket Interleaving överlagrar minnet mellan båda socklar, vilket ger en NUMA-nod på en 2S-plattform. Detta bör vara detsamma som en inaktiverad NUMA.    

Genom att använda standardkonfigurationen för Memory Channel Interleaving – ha i åtanke att varje sockel har fyra matriser – skapar varje matris två minneskanaler och BIOS presenterar åtta NUMA-noder på en 2S-plattform. Exemplet på numactl-utgång i bild 4 visar de åtta NUMA-noderna på en 2S-plattform, en NUMA-nod per matris.


Bild 4 – numactl-utgång på 2S EPYC


Fysiskt finns fyra NUMA-avstånd på plattformen som markerats i bild 4: till själva NUMA-noden (avstånd 10 i rött), till de tre noderna som delar samma matris (avstånd 16 i blått), till noden på den andra sockeln som är direkt ansluten via en Infinity Fabric-länk (avstånd 22 i grönt), till de tre andra noderna på fjärrsockeln med åtkomst via två hopp med Infinity Fabric mellan de två socklarna samt inbyggd Infinity Fabric-länk (avstånd 28 i svart).

Vissa BIOS-implementeringar och -versioner kan ha den här fysiska layouten förenklad och endast presentera tre NUMA-avstånd för operativsystemet. Denna förenkling innefattar en maskering av skillnaden i avstånd mellan NUMA-nod 0 (exempelvis) och NUMA-nod 4,5,6,7 genom att presentera NUMA-noder 4,5,6,7 med samma avstånd från NUMA-nod 0. En sådan implementering visas i bild 5. NUMA-layout är ett valbart alternativ i nästa version av PowerEdge R7425 BIOS. Att förenkla NUMA-nodens avstånd ändrar inte den faktiska fysiska kärnlayouten, detta är främst för OS-schemaläggaren. För HPC- och MPI-jobb som är NUMA-medvetna bör de olika presentationerna inte vara av någon betydelse.


Bild 5 – numactl-utgång på 2S EPYC med förenklade NUMA-avstånd


Utöver de åtta NUMA-noderna på en plattform med två socklar visar också bild 4 och 5 det minne och de kärnor som associeras med vardera NUMA-nod. Varje NUMA-nod har 32 GB minne från två DIMM:er på 16 GB (16 DIMM:er på servern, åtta per sockel, 1 DIMM per kanal). Varje NUMA-nod innehåller åtta kärnor av de lokala matriserna. Kärnuppräkningen på Dell EMC-plattformen är en Round Robin och går först mellan alla NUMA-noder och fyller sedan varje NUMA-nod.

Dessutom kan lstopo-utgången användas för att tydligt visa vilka uppsättningar med fyra kärnor som utgör ett kärnkomplex. Dessa är de fyra kärnorna på en matris som delar L3-cache. Bild 6 visar exempelvis att NUMA-nod 0 har åtta kärnor och att NUMA-nodkärnorna 0, 16, 32, 48 delar L3-cache, medan kärnorna 8, 24, 40, 56 delar L3-cache.


Bild 6 – lstopo-utgång på 2S EPYC


Bild 7 – AMD EPYC-plattformens minnesbandbredd

Med hänsyn till NUMA-layoutinformationen visas STREAM Triad-prestandatestets resultat för minnesbandbredd i bild 7 med BIOS konfigurerad till Memory Channel Interleaving. Observera att de dubbelrankade minnesmodulerna på 16 GB 2 667 MT/s som används i den här testbädden körs vid 2 400 MT/s på EPYC. Den första uppsättningen staplar i bild 7 visar att minnets bandbredd på 2S-plattformen är 244 Gbit/s när alla kärnor används, och 255,5 Gbit/s när hälften av alla kärnor används. Den andra datapunkten är minnets bandbredd för en enda sockel, och är ungefär hälften av den fulla 2S-plattformen, som förväntat. Den tredje datapunkten mäter minnets bandbredd för en NUMA-nod, en enskild matris. Ha i åtanke att varje sockel har fyra matriser och bandbredden för en matris är ungefär ¼ av en sockel. Inom en matris finns två kärnkomplex, och om endast kärnorna i ett kärnkomplex används tillhandahålls ~30 Gbit/s. När kärnorna används mellan båda kärnkomplex på en matris kan matrisens fulla bandbredd uppnås, ~ 32 Gbit/s.

2S-plattformens minnesbandbredd är imponerande, 240–260 Gbit/s, och ett resultat av åtta minneskanaler per sockel på plattformen. Dessutom kan en enda kärna tillhandahålla ~24,5 Gbit/s av minnets bandbredd till det lokala minnet, vilket passar utmärkt för den enkeltrådade delen program.

När det kommer till påverkan av NUMA-layouten på fjärråtkomst till minnet visas i bild 8 den relativa minnesbandbredden när kärnorna har åtkomst till minnet som inte är i samma NUMA-domän. Åtkomst till minnet i samma sockel är ~30 % långsammare, åtkomst till minnet på den andra sockeln är ~65 % långsammare. Med STREAM Triad syns ingen mätbar påverkan på minnets bandbredd vid åtkomst till minnet på fjärrsockeln över ett hopp (nod 6, 1 Infinity Fabric mellan socklar) eller två hopp (nod 4, 5, 7 – 1 Infinity Fabric-hopp mellan socklar + 1 lokalt Infinity Fabric-hopp). För program som är känsliga för minnets bandbredd är bra minne lokalt viktigt för prestandan även i samma sockel.


Bild 8 – påverkan på fjärråtkomst till minnet
 

---

HPL-prestandatest

Därefter mätte vi datorkapaciteten för EPYC så som den mäts av HPL-prestandatestet. EPYC har stöd för AVX-instruktioner och en prestanda på 8 FLOP/cykel. På vår plattform använde vi Open MPI och BLIS-linjära algebrabibliotek för att köra HPL.

Den teoretiska prestandan i vårt testsystem (dubbla EPYC 7601-processorer) är 64 kärnor * 8 FLOP/cykel* 2,2 GHz klockfrekvens, vilket gav 1 126 GFLOPS. Vi mätte 1 133 GLOPS, vilket är en effektivitet på 100,6 %.

Vi körde också HPL på EPYC 7551 (32c, 2,0 GHz), EPYC 7351 (16c, 2,4 GHz) och EPYC 7351P (1S, 16c, 2,4GHz). I dessa tester mättes HPL-prestandan till 102–106 % av den teoretiska prestandan.

Effektiviteten är över 100 % eftersom EPYC kan bibehålla turbofrekvenser över basfrekvensen under HPL-testet.
 

---

InfiniBand-latens och bandbredd

Vi verifierade sedan resultaten för mikro-prestandatestet av InfiniBand-latens och -bandbredd mellan två servrar. Konfigurationen som användes för dessa två tester beskrivs i tabell 1. Latens- och bandbreddsresultat visas i bild 9 10.


  Tabell 1– InfiniBand-testbädd


Bild 9 – InfiniBand-latens, med switch

Kör kommandot: 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

Försiktighet vidtogs för att fästa MPI-processen till NUMA-noden som är närmst HCA. Den här informationen är tillgänglig i lstopo-utgången, och i vårt fall var det NUMA-nod 6. Latenstester kördes med både OpenMPI och HPC-X. Med OpenMPI- och MXM-acceleration uppmätte vi en lastens på 1,17µs, med OpenMPI och UCX uppmättes en latens på 1,10µs. Latensresultaten med HPC-X presenteras här.

På bild 9 är latensen på EPYC-processorer med aktiverade C-status 1,07µs och latensen för alla meddelandestorlekar är ~ 2 till 9 % bättre med aktiverade C-status i jämförelse med inaktiverade C-status. Aktiverade C-status möjliggör inaktiva kärnor i djupare c-status. Detta tillåter högre turbofrekvenser på de aktiva kärnorna, vilket resulterar i reducerad latens.

Resultaten för bandbredd visas i bild 10. Vi uppmätte 12,4 Gbit/s bandbredd i en riktning och 24,7 Gbit/s dubbelriktad bandbredd. Resultaten är som förväntat för EDR


Bild 10 – InfiniBand-bandbredd

Kör 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 – osu_mbw_mr-resultat – enkel NUMA-nod
Kör 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-layouten som beskrivs i bild 3 och 6 uppmärksammade oss på att kontrollera processens påverkan på bandbredden lokalt. För det här testet använde vi osu_mbw_mr-prestandatestet som mäter extra bandbredd med enkel väg mellan flera processpar. Syftet med det här testet är att avgöra uppnådd bandbredd och meddelandehastighet mellan individuella NUMA-noder med hjälp av alla åtta kärnor på NUMA-noden. Resultaten av testet visas i tabell 2. Testkonfigurationen använde prestandaprofil (inaktiverade C-status och aktiverad Turbo).

Resultaten visar att när processer som körs på NUMA-noden som är ansluten till InfiniBand HCA (NUMA-nod 6) är den extra bandbredden 12,3 Gbit/s. När processer körs på någon av de andra tre NUMA-noderna som finns i samma sockel som HCA (sockel 1) är den extra bandbredden ungefär samma, ~12,1 Gbit/s. När processer körs på NUMA-noderna i sockeln som är fjärrstyrd på HCA sänks den extra bandbredden till ~6,8 Gbit/s.

Nästa uppsättning resultat som visas i tabell 3 demonstrerar bandbredden med enkel väg mellan enskilda socklar. För detta test användes alla 32 kärnor som finns tillgängliga i sockeln. Vi mätte 5,1 Gbit/s vid körning på sockeln lokalt till HCA, och 2,4 Gbit/s vid fjärrkörning på sockeln till HCA. När vi använde alla 64 kärnor på våra testservrar uppmättes 3,0 Gbit/s när 64 processer per server kördes.

För att dubbelkontrollera det här senaste resultatet körde vi ett test med alla 8 NUMA-noder mellan båda socklarna då vardera NUMA-nod körde två processer, vilket gav totalt 16 processer per server. Med den här layouten uppmätte vi också 2,9 Gbit/s.

Dessa resultat visar att systemets topologi har påverkan på kommunikationsprestandan. Detta är intressant för fall där en viktig faktor är att det finns ett mönster med kommunikation mellan alla, med flera processer som kommunicerar mellan servrar. För andra program är det möjligt att den minskade bandbredden som uppmäts när flera processer körs på flera NUMA-domäner inte påverkar prestandan på programnivå.


  Tabell 3 – osu_mbw_br results – socklar och systemnivå
Kör 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

 
Kör 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

 
Kör 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-prestanda på klusternivå

Med vår InfiniBand-infrastruktursprestanda bekräftad gjordes nästa test för att snabbt köra HPL över klustret. Dessa tester utfördes på ett system med 16 noder med dubbla socklar EPYC 7601. Resultaten som visas i bild 11 visar förväntad HPL-skalbarhet över de 16 systemen.


Bild 11 – HPL över 16 servrar

 

---

WRF-prestanda på klusternivå

Slutligen körde vi WRF, ett väderprognosprogram. Testbädden var densamma som tidigare, ett system med 16 noder med dubbla socklar EPYC 7601. Dessutom genomförde vi några tester på ett mindre system med 4 noder med dubbla socklar EPYC 7551. Alla servrar hade 16 GB*16 RDIMM som körde på 2 400 MT/s och var sammankopplade med Mellanox EDR InfiniBand.


Bild 12 – WRF CONUS 12km, enskild nod

Vi använde WRF v3.8.1 och v3.9.1 och testade datauppsättningar på CONUS 12km och CONUS 2,5km. Vi kompilerade WRF och netcdf med Intel-kompilatorer och körde med Intel MPI. Vi har testat olika processer och layoutscheman, med alternativ för både dmpar- och dm+sm-konfiguration med OpenMP.

Vi arbetade med AMD för att utreda andra justeringsalternativ för WRF-kompilering.

Det fanns ingen uppmätt prestandaskillnad mellan WRF v3.8.1 och v3.9.1. En jämförelse mellan dmpar och dm+sm visar en rationell kombination av processer och paneler som resulterade i ungefär samma prestanda. Detta visas på bild 12.


Bild 13 – WRF CONUS 12 km, klustertester


Bild 14 – WRF CONUS 2,5km, klustertester

Tester på klusternivå genomfördes med WRV v3.8.1 och dmpar-konfigurationen med alla kärnor och 8 paneler per körning.

CONUS 12km är en mindre datauppsättning och konstant prestandanivå efter 8 noder, 512 kärnor på EPYC. Detta visas på bild 13. EPYC 7551 och EPYC 7601 är båda 32-kärniga processorer med 7601 basklockfrekvens och en turbofrekvens för alla kärnor på 10 % och 6 % snabbare än 7551 respektive. I WRF CONUS 12km-tester var prestandan för EPYC 7601-systemet 3 % snabbare än 7551 på 1-, 2- och 4-nodtesterna.

CONUS 2.5km är ett större prestandatest för datauppsättning och besläktat med 1 EPYC-systemet. Prestandan skalar upp till 8 noder (512 kärnor) och börjar sedan sänkas. Med CONUS 2.5km presterar EPYC 7601-systemet också 2–3 % snabbare än EPYC 7551 i 1-, 2- och 4 nodtesterna som visas i bild 14.

 

---

Sammanfattning och nästa steg

EPYC ger bra minnesbandbredd och kärndensitet per sockel. Från ett HPC-perspektiv förväntar vi oss att programmen kan använda minnesbandbredd och processorkärnor som finns tillgänglig för att dra mest nytta av EPYC-arkitekturen. EPYC har idag inte stöd för AVX512 eller AVX2 i en enskild cykel, så koder med hög vektor och som kan använda AVX2 eller AVX512 effektivt kanske inte är optimala för EPYC.

Alla fall som kan använda flera NVM-enheter kan också dra nytta av direktansluten NVMe, som är möjlig tack vare antalet PCI-E-banor på EPYC.

Nästa steg innefattar vidare prestandatester med andra HPC-program.