Studie výkonu AMD EPYC – STREAM, HPL, InfiniBand a WRF

---

Shrnutí

Oddělení HPC and AI Innovation LAB má nový cluster s 32 systémy založenými na procesoru AMD EPYC, které jsou propojené s řešením Mellanox EDR InfiniBand. Stejně jako vždy provádíme hodnocení výkonu našeho nejnovějšího clusteru a chtěli bychom se s vámi podělit o výsledky. Tento blog obsahuje výsledky šířky pásma paměti z mikro srovnávacích testů výkonu STREAM, HPL, InfiniBand, které se týkají latence a šířky pásma, a výsledky WRF z datových sad svých srovnávacích testů.

Zajímá nás skutečný výkon aplikací superpočítače s použitím mikroprocesoru EPYC. Chcete-li na mikroprocesoru EPYC vyzkoušet datové sady, obraťte se na obchodní tým Dell, který vám poskytne přístup k oddělení Innovation Lab.
 

---

Architektura AMD EPYC

Procesory AMD EPYC podporují osm paměťových kanálů, až 16 paměťových modulů DIMM (Dual In-line Memory Module) na jeden soket s dvěma moduly DIMM na jeden kanál a až 32 jader na jeden soket. Platforma s procesory AMD navíc poskytuje až 128 linek PCI-E pro periferní zařízení, jako jsou grafické karty a disky NVMe.
Samotné procesory jsou multifunkční moduly sestavené ze čtyř kostek. Každá kostka obsahuje až osm jader Zen, dva paměťové kanály DDR4 a 32 linek IO. Jádra Zen na kostce jsou uspořádány do dvou skupin po 4 jádrech, označují se jako složená jádra a sdílí vyrovnávací paměť L3. V rámci jednoho soketu všechny čtyři kostky propojuje souvislé propojení nazývané Infinity Fabric. To je znázorněno na Obrázku 1.


Obrázek 1 – Rozložení soketů EPYC. CCX je složené jádro až o 4 jádrech, které sdílejí vyrovnávací paměť L3. M* jsou paměťové kanály, přičemž každá kostka má na starost dva kanály. P* a G* jsou linky IO. ∞ je propojení Infinity Fabric.



V systému s jedním soketem jedna kostka zajišťuje až 32 linek PCI-E pomocí linek IO P* a G*, které jsou zobrazené v Obrázku 1. To zajišťuje soketu celkem 128 linek PCI-E, jak je znázorněno na Obrázku 2. Pokud se procesor používá v konfiguraci se dvěma sokety (2S), polovina linek IO každé kostky se použije k připojení k jedné z kostek na jiném soketu pomocí linek IO G* nakonfigurovaných jako Infinity Fabric. To znamená, že soketu zbudou linky IO P* pro celkem 64 linek PCI-E, a tedy stále 128 linek PCI-E pro platformu. To je znázorněno na Obrázku 3.


Obrázek 2 – Linky EPYC 1S PCI-E




Obrázek 3 – Rozložení konfigurace EPYC 2S




Obrázek 3 – Rozložení konfigurace EPYC 2S

 

---

Srovnávací test výkonu STREAM

Jako první krok při hodnocení mikroprocesoru EPYC jsme pomocí srovnávacího testu STREAM změřili na platformě možnosti šířky pásma její paměti. Tyto testy byly provedeny na serveru Dell EMC PowerEdge R7425 se dvěma procesory AMD EPYC 7601 (32c, 2,2 GHz), 16 × 16GB moduly DIMM 2 400 MT/s a s operačním systémem Red Hat® Enterprise Linux® 7.5.

Prezentaci NUMA (Non-Uniform Memory Access) mikroprocesorů EPYC lze ovládat pomocí možnosti systému BIOS nazvané „Memory Interleaving“ a namapovat pomocí nástrojů Linux, jako jsou numactl a lstopo.

Výchozí možnost Memory Interleaving je nastavena na hodnotu „Memory Channel Interleaving“. V tomto režimu se prokládají dva kanály z každé kostky. To představuje 4 uzly NUMA na 1 soket a 8 uzlů NUMA pro operační systém systému s konfigurací 2S.

„Memory Die Interleaving“ je možnost, při které se paměť přenáší napříč všemi 4 kostkami na soketu, tj. prokládá se osm paměťových kanálů. To představuje 1 uzel NUMA na 1 soket a 2 uzly NUMA v systému s konfigurací 2S.

Možnost „Memory Socket Interleaving“ prokládá paměť napříč oběma sokety, přičemž platformě 2S přiřadí 1 uzel NUMA. Jedná se o stejné hodnoty, jako když je NUMA zakázaný.    

Používáte-li výchozí možnost „Memory Channel Interleaving“, pamatujte, že každý soket obsahuje 4 kostky, každá kostka je vybavena 2 paměťovými kanály a systém BIOS nabízí na platformě 2S 8 uzlů NUMA. Vzorový výstup nástroje numactl na Obrázku 4 znázorňuje těchto 8 uzlů NUMA na platformě 2S – vždy pouze 1 uzel NUMA na 1 kostku.


Obrázek 4 – Výstup nástroje numactl na platformě 2S EPYC


Jak je znázorněno na Obrázku 4, fyzicky jsou na platformě 4 vzdálenosti NUMA: na samotný uzel NUMA (vzdálenost „10“ červeně "), na 3 uzly, které sdílejí stejnou kostku (vzdálenost „16“ modře), na uzel v druhém soketu, který je přímo propojen prostřednictvím linku Infinity Fabric (vzdálenost „22“ zeleně), na 3 ostatní uzly ve vzdáleném soketu, ke kterým lze přistupovat prostřednictvím 2 směrování pomocí linku Infinity Fabric mezi dvěma sokety a interním linkem Infinity Fabric (vzdálenost „28“ černě).

Některé implementace a verze systému BIOS mohou zjednodušit toto fyzické rozložení a představují pouze 3 vzdálenosti NUMA k operačnímu systému. Toto zjednodušení zahrnuje maskování rozdílu vzdáleností mezi uzlem NUMA 0 (jako příklad) a uzly NUMA 4, 5, 6 a 7, přičemž se uvede, že uzly NUMA 4, 5, 6 a 7 mají od uzlu NUMA 0 stejnou vzdálenost. Taková implementace je znázorněna na Obrázku 5. V rámci příštího vydání systému BIOS PowerEdge R7425 bude mít rozložení NUMA možnost ladění. Zjednodušení vzdáleností mezi uzly NUMA nezmění skutečné fyzické rozložení jader, slouží především jako výhoda pro plánovač operačního systému. V případě úloh superpočítače a MPI, které podporují uzly NUMA, by tyto prezentace měly být nepodstatné.


Obrázek 5 – Výstup nástroje numactl na platformě 2S EPYC se zjednodušenými vzdálenostmi NUMA


Kromě 8 uzlů NUMA na platformě se dvěma sokety, Obrázek 4 a Obrázek 5 také zobrazují paměť a jádra, které náleží jednotlivým uzlům NUMA. Každý uzel NUMA obsahuje 32 GB paměti díky dvěma 16GB modulům DIMM (16 modulů DIMM na serveru – 8 modulů na 1 soket –, 1 modul DIMM na 1 kanál). Každý uzel NUMA obsahuje 8 jader místní kostky. Součet jader v platformě Dell EMC představuje kruhově dotazování přes všechny uzly NUMA, které poté každý uzel NUMA vyplní.

Navíc je možné použít výstup nástroje lstopo k jasnému znázornění, která sada 4 jader tvoří složené jádro. Jedná se o 4 jádra na kostce, která sdílí vyrovnávací paměť L3. Obrázek 6 například ukazuje, že uzel NUMA 0 má 8 jader, přičemž vyrovnávací paměť L3 v něm sdílí jádra 0, 16, 32, 48 a jádra 8, 24, 40, 56.


Obrázek 6 – Výstup nástroje Istopo na platformě 2S EPYC


Obrázek 7 – Šířka pásma paměti platformy AMD EPYC

Se zohledněním informací o tomto rozložení NUMA uvádíme na Obrázku 7 výsledky srovnávacího testu STREAM Triad se systémem BIOS nastaveným na možnost „Memory Channel Interleaving“. Upozorňujeme, že dvouřadé moduly 16GB 2667 použité v tomto testu pracovaly na mikroprocesoru EPYC při rychlosti 2 400 MT/s. Modré sloupce na Obrázku 7 znázorňují šířku pásma paměti platformy 2S, která je 244 Gbit/s, když se používají všechna jádra, a 255,5 Gbit/s, když se používá polovina jader. Oranžové sloupce znázorňují šířku paměti jediného soketu, která dle očekávání je stejně velká jako polovina celé platformy 2S. Třetí datový bod měří šířku pásma paměti uzlu NUMA, samostatné kostky. Každý soket má 4 kostky, a šířka pásma jedné kostky je přibližně 1/¼ daného soketu. V kostce existují dvě složená jádra. Používání pouze jader v jednom složeném jádru zajistí šířku pásma přibližně 30 Gbit/s. Pokud se používají jádra napříč oběma složenými jádry na kostce, je možné dosáhnout plné šířky pásma kostky přibližně 32 Gbit/s.

Šířka pásma paměti platformy 2S je působivých 240–260 Gbit/s a je výsledkem 8 paměťových kanálů na 1 soket na platformě. Jediné jádro navíc místní paměti zajistí šířku pásma přibližně 24,5 Gbit/s, která je ideální pro část aplikací s jedním vláknem.

S ohledem na dopad, který má rozložení NUMA na vzdálený přístup k paměti, Obrázek 8 znázorňuje relativní šířku pásma paměti, když jádra přistupují k paměti, která se nenachází ve stejné doméně NUMA. Přístup k paměti ve stejném soketu je až o 30 % pomalejší, přístup k paměti v druhém soketu je až o 65 % pomalejší. Používáte-li STREAM Triad, zdá se, že při přístupu k paměti vzdáleného soketu přes jedno směrování (uzel 6 – 1 směrování Infinity Fabric mezi sokety) nebo přes dvě směrování (uzel 4, 5, 7 – 1 směrování Infinity Fabric mezi sokety + 1 místní směrování Infinity Fabric) nedochází k ovlivnění šířky pásma. V případě aplikací citlivých na šířku pásma bude mít na výkon vliv dobrá pozice paměti, a to i v rámci stejného soketu.


Obrázek 8 – Dopad vzdáleného přístupu k paměti
 

---

Srovnávací test výkonu HPL

Dále jsme podle srovnávacího testu HPL změřili výpočetní schopnosti mikroprocesorů EPYC. EPYC umí podporovat pokyny AVX a výkon 8 FLOP/cyklus. Na naší platformě jsme ke spuštění HPL používali lineární algebraické knihovny Open MPI a BLIS.

Teoretický výkon našeho testovacího systému (dva procesory EPYC 7601) je 64 jader × 8 FLOP/cyklus × taktovací frekvence 2,2 GHz, což se rovná 1 126 GFLOPS. Naměřili jsme 1 133 GLOPS, což představuje efektivitu 100,6 %.

HPC jsme také spustili na procesoru EPYC 7551 (32c, 2,0 GHz), EPYC 7351 (16c, 2,4 GHz) a EPYC 7351P (1S, 16c, 2,4 GHz). U těchto testů naměřený výkon HPL činil 102–106 % teoretického výkonu.

Efektivita převyšuje 100 %, jelikož mikroprocesor EPYC je schopen během trvání testu HPL udržet frekvence Turbo nad základní frekvencí.
 

---

Latence a šířka pásma InfiniBand

Poté jsme ověřili výsledky mikro srovnávacích testů latence a šířky pásma InfiniBand mezi dvěma servery. Konfigurace použitá pro tyto testy je popsaná v Tabulce 1. Výsledky latence a šířky pásma jsou uvedeny na Obrázcích 9 a 10.


  Tabulka 1 – Testbed InfiniBand


Obrázek 9 – Latence InfiniBand s přepínačem

Spusťte příkaz: 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

Bylo třeba připnout proces MPI na uzel NUMA, který je nejblíže k HCA. Tyto informace jsou k dispozici ve výstupu nástroje lstopo. V našem případě se jednalo o uzel NUMA 6. Testy latence byly spuštěny u knihoven OpenMPI a HPC-X. Díky akceleraci OpenMPI a MXM jsme změřili latenci 1,17µ a pomocí OpenMPI a UCX jsme změřili latenci 1,10µ. Výsledky latence získané pomocí HPC-X jsou uvedeny zde.

Z Obrázku 9 latence u procesorů EPYC s povolenými režimy C-State je 1,07µ a latence pro všechny velikosti zpráv je ve srovnání mezi povolenými a zakázanými režimy C-State vyšší přibližně o 2–9 %. Povolené režimy C-State umožňují, aby byla jádra v hlubších režimech C-State nečinná. Díky tomu v aktivních jádrech dochází k vyšší frekvenci Turbo, což vede ke snížení latence.

Výsledky šířky pásma jsou uvedené na Obrázku 10. Naměřili jsme jednosměrnou šířku pásma 12,4 Gbit/s a dvousměrnou šířku pásma 24,7 Gbit/s. Tyto výsledky se pro technologii EDR očekávali.


Obrázek 10 – Šířka pásma InfiniBand

Spusťte příkaz: 

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

 

Tabulka 2 – Výsledky osu_mbw_mr – jeden uzel NUMA
Spusťte příkaz: 

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

Rozložení NUMA, které je popsané na Obrázcích 3 a 6, nás přivedlo ke kontrole dopadu umístění na šířku pásma. Pro tento test jsme použili srovnávací test osu_mbw_mr, který měří agregaci jednosměrné šířky pásma mezi více páry procesů. Cílem tohoto testu je určit dosaženou šířku pásma a frekvenci zpráv mezi jednotlivými uzly NUMA pomocí všech 8 jader na uzlu NUMA. Výsledky tohoto testu jsou uvedeny v Tabulce 2. Testovací konfigurace použila Profil výkonu (zakázané režimy C-State a povolené Turbo).

Výsledky ukazují, že pokud se procesy spustí na uzlu NUMA, který je připojen k InfiniBand HCA (uzel NUMA 6), agregovaná šířka pásma činí 12,3 Gbit/s. Pokud se procesy spustí na libovolném ze 3 uzlů NUMA, které se nacházejí ve stejném soketu jako HCA (Soket 1), agregovaná šířka pásma činí přibližně 12,1 Gbit/s. Pokud se procesy spustí v uzlech NUMA v soketu, který je vzdálený od HCA, agregovaná šířka pásma klesne na 6,8 Gbit/s.

Následující sada výsledků uvedených v Tabulce 3 znázorňuje jednosměrovou šířku pásma mezi jednotlivými sokety. Pro tento test bylo použito všech 32 jader v soketu. Při provozu v soketu na HCA jsme naměřili šířku pásma 5,1 Gbit/s a 2,4 Gbit/s při provozu v soketu vzdáleném od HCA. Při použití všech 64 jader v testovacích serverech jsme změřili 3,0 Gbit/s – 64 procesů na 1 server.

Za účelem ověření tohoto posledního výsledku jsme spustili test s využitím všech 8 uzlů NUMA napříč oběma sokety, přičemž v každém uzlu NUMA probíhaly 2 procesy, tedy celkem 16 procesů na 1 serveru. Pomocí tohoto rozložení jsme také naměřili hodnotu 2,9 Gbit/s.

Tyto výsledky ukazují, že topologie systému má vliv na výkon komunikace. To je důležité v případech, kdy vzorec vzájemné komunikace mezi všemi a komunikace více procesů napříč servery představuje důležitý faktor. V případě ostatních aplikací je možné, že snížená šířka pásma měřená při spuštěných procesech na více doménách NUMA nemusí ovlivňovat výkon na úrovni aplikace.


  Tabulka 3 – Výsledky osu_mbw_br – na úrovni soketů a systému
Spusťte příkaz: 

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

 
Spusťte příkaz:

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

 
Spusťte příkaz: 

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

---

Výkon HPL na úrovni clusteru

Po ověření výkonu InfiniBand Fabric bylo součástí dalšího testu rychle spustit HPL napříč clusterem. Tyto testy byly provedeny v systému s 16 uzly a dvěma sokety EPYC 7601. Výsledky jsou uvedeny na Obrázku 11 a zobrazují očekávanou škálovatelnost HPL napříč 16 systémy.


Obrázek 11 – HPL napříč 16 servery

 

---

Výkon softwaru WRF na úrovni clusteru

Konečně jsme spustili WRF, aplikaci na předpověď počasí. Testbed byl stejný jako předtím, systém se 16 uzly a dvěma sokety EPYC 7601. Navíc jsme provedli několik testů v menším systému se 4 uzly a dvěma sokety EPYC 7551. Moduly RDIMM 16 GB × 16 všech serverů běžely při rychlosti 2 400 MT/s a servery samotné byly propojeny s řešením Mellanox EDR InfiniBand.


Obrázek 12 – WRF Conus 12 km, 1 uzel

Používali jsme software WRF v3.8.1 a v3.9.1 a otestovali sady dat Conus 12 km a Conus 2,5 km. Pomocí nástrojů Intel Compiler jsme zkompilovali software WRF a formát netcdf a spustili knihovnu Intel MPI. Pomocí možností konfigurace dmpar a dm+sem s OpenMP jsme vyzkoušeli různá schémata zpracování a skládání dlaždic.

Pomocí technologie AMD chceme pro software WRF určit další možnosti ladění kompilátoru.

Mezi verzemi softwaru WRF v3.8.1 a v3.9.1 jsme nenaměřili žádný rozdíl ve výkonu. Při srovnání možností dmpar a dm+sm jsme pomocí uvážlivé kombinace procesů a dlaždic dosáhli přibližně stejného výkonu. To je znázorněno na Obrázku 12.


Obrázek 13 – WRF Conus 12 km, testy clusteru


Obrázek 14 – WRF Conus 2,5 km, testy clusteru

Testy na úrovni clusteru byly provedeny pomocí softwaru WRF v3.8.1 a konfigurace dmpar s využitím všech jader a 8 dlaždic na 1 test.

Conus 12 km je menší datová sada, ve které se výkon v mikroprocesoru EPYC po 8 uzlech a 512 jádrech ustálí. To je znázorněno na Obrázku 13. EPYC 7551 a EPYC 7601 jsou 32jádrové procesory se základní taktovací frekvencí 7551 a 7601, přičemž frekvence Turbo všech jader je u nich odpovídajícím způsobem o 10 a 6 % rychlejší. V případě testů WRF Conus 12 km byl výkon systému EPYC 7601 o 3 % rychlejší než 7551 při testu uzlů 1, 2 a 4.

Conus 2,5 km je větší datová sada srovnávacího testu. V závislosti na 1 systému EPYC výkon vzroste až na 8 uzlů (512 jader) a zahájí odmítání. S datovou sadou Conus 2,5 km je výkon systému EPYC 7601 o 2–3 % rychlejší než výkon systému EPYC 7551 při testování uzlů 1, 2 a 4, jak je znázorněno na Obrázku 14.

 

---

Závěr a další postup

Mikroprocesory EPYC poskytují dobrou šířku pásma paměti a hustotu jader na 1 soket. Z pohledu superpočítače očekáváme, že většinu výhod architektury EPYC budou schopné využít aplikace, které dokáží využít dostupnou šířku pásma paměti a jádra procesoru. Mikroprocesory EPYC v současné době nepodporují rozšíření AVX512 či AVX2 v 1 cyklu, takže kódy, které jsou vysoce vektorové a dokážou efektivně používat rozšíření AVX2 a AVX512, nemusí být pro architekturu EPYC ideální.

Případy použití, které dokážou využít více disků NVMe, mohou těžit z výhod přímo připojených disků NVMe, což je možné díky počtu linek PCI-E v mikroprocesoru EPYC.

Náš další postup zahrnuje další testy výkonu s dalšími aplikacemi superpočítačů.