AMD EPYC — badanie wydajności STREAM, HPL, InfiniBand i WRF

---

Streszczenie

Laboratorium innowacji HPC i AI ma nowy klaster z 32 systemami opartymi na procesorach AMD EPYC połączonymi przez Mellanox EDR InfiniBand. Jak zawsze, wykonujemy oceny wydajności naszego najnowszego klastra i chcielibyśmy podzielić się wynikami. W tym blogu opisano wyniki przepustowości z mikrotestu porównawczego wydajności STREAM, HPL i InfiniBand dotyczące latencji i przepustowości oraz wyniki WRF ze zbiorów danych testów porównawczych.

Interesuje nas wydajność rzeczywistych aplikacji HPC na procesorach EPYC. Jeśli masz zbiory danych, które chcesz przetestować na procesorach EPYC, skontaktuj się z zespołem obsługi klienta Dell w celu uzyskania dostępu do laboratorium innowacji.
 

---

Architektura AMD EPYC

Procesory AMD EPYC obsługują osiem kanałów pamięci, do 16 modułów pamięci DIMM na gniazdo, do dwóch modułów DIMM na kanał i do 32 rdzeni na gniazdo. Ponadto platforma z procesorami AMD zapewnia do 128 torów PCI-E do obsługi urządzeń peryferyjnych, takich jak procesor graficzny i dyski NVMe.
Same procesory są modułami z wieloma układami złożonymi z czterech matryc. Każda matryca składa się z maksymalnie ośmiu rdzeni Zen, dwóch kanałów pamięci DDR4 i 32 torów we/wy. Rdzenie Zen na matrycy są ułożone w dwóch grupach, po cztery w każdej grupie czterech rdzeni nazywanej kompleksem rdzeni, ze wspólną pamięcią podręczną L3. W gnieździe wszystkie cztery matryce są połączone za pośrednictwem koherentnego łącza o nazwie Infinity Fabric. Zostało to pokazane na rysunku 1.


Rysunek 1 – Układ gniazda EPYC. CCX to kompleks rdzeni złożony z maksymalnie 4 rdzeni, który współdzieli pamięć podręczną L3. M* to kanały pamięci, dwa kanały obsługiwane przez każdą matrycę. P* i G* to tory we/wy. ∞ to Infinity Fabric.



W przypadku układu z jednym gniazdem każda matryca zapewnia do 32 torów PCI-E przy użyciu torów we/wy P* i G* pokazanych na rysunku 1. Dzięki temu gniazdo uzyskuje łącznie 128 torów PCI-E, jak pokazano na rysunku 2. W przypadku używania procesora w konfiguracji z dwoma gniazdami (2S) połowa torów we/wy każdej matrycy jest używana do połączenia z jedną matrycą w drugim gnieździe przy użyciu torów we/wy G* skonfigurowanych jako Infinity Fabric. Pozostawia to gniazdo z torami we/wy P* dla łącznie 64 torów PCI-E, a więc nadal 128 torów PCI-E torów dla platformy. Zostało to pokazane na rysunku 3


Rysunek 2 – Tory PCI-E w konfiguracji EPYC z 1 gniazdem




Rysunek 3 – Układ EPYC z 2 gniazdami




Rysunek 3 – Układ EPYC z 2 gniazdami

 

---

Wydajność w teście porównawczym STREAM

Pierwszym krokiem do oceny procesora EPYC był pomiar przepustowości pamięci platformy przy użyciu testu porównawczego STREAM. Testy te były wykonywane na serwerze Dell EMC PowerEdge R7425 z dwoma procesorami AMD EPYC 7601 (32 rdzenie, 2,2 GHz), 16*16 GB DIMM przy 2400 MT/s, z systemem Red Hat® Enterprise Linux® 7.5.

Prezentacja niejednolitego dostępu do pamięci (NUMA) procesorów EPYC może być kontrolowana przez opcję BIOS o nazwie „Memory Interleaving” (Przeplatanie pamięci) i mapowana przy użyciu narzędzi Linux, takich jak numactl i Istopo.

Domyślna opcja przeplatania pamięci to „Memory Channel Interleaving” (Przeplatanie kanałów pamięci). W tym trybie przeplatane są dwa kanały każdej matrycy. Prezentuje on cztery węzły NUMA na gniazdo i osiem węzłów NUMA w systemie operacyjnym w systemie z dwoma gniazdami.

„Memory Die Interleaving” (Przeplatanie matryc pamięci) to opcja, w której pamięć jest przeplatana między wszystkimi czterema matrycami w gnieździe, tj. osiem kanałów pamięci. Prezentuje on jeden węzeł NUMA na gniazdo i dwa węzły NUMA w systemie z 2 gniazdami.

„Memory Socket Interleaving” (Przeplatanie gniazd pamięci) przeplata pamięć między dwoma gniazdami, tworząc jeden węzeł NUMA na platformie z 2 gniazdami. Byłby to odpowiednik wyłączenia NUMA.    

W przypadku korzystania z konfiguracji domyślnej „Memory Channel Interleaving” (Przeplatanie kanałów pamięci) należy pamiętać, że każde gniazdo ma cztery matryce, a każda matryca zapewnia dwa kanały pamięci i system BIOS prezentuje osiem węzłów NUMA na platformie z 2 gniazdami. Przykładowy wynik numactl na rysunku 4 przedstawia te osiem węzłów NUMA na platformie z 2 gniazdami, po jednym węźle NUMA na matrycę.


Rysunek 4 – Wynik numactl w konfiguracji EPYC z 2 gniazdami


Fizycznie na platformie są cztery odległości NUMA, jak zaznaczono na rysunku 4: do samego węzła NUMA (odległość „10” na czerwono), do trzech węzłów współdzielących tę samą matrycę (odległość „16” na niebiesko), do węzła w drugim gnieździe, które jest bezpośrednio połączone za pośrednictwem łącza Infinity Fabric (odległość „22” na zielono), do trzech innych węzłów w gnieździe zdalnym, dostępnego za pośrednictwem dwóch bram oraz łącza wewnętrznego Infinity Fabric (odległość „28” na czarno).

Niektóre implementacje i wersje BIOS mogą uprościć ten układ fizyczny i prezentować tylko trzy odległości NUMA w systemie operacyjnym. Uproszczenie to obejmuje maskowanie różnicy odległości między węzłem NUMA 0 (przykładowo) a węzłami NUMA 4, 5, 6, 7 poprzez prezentowanie węzłów NUMA 4, 5, 6, 7 jako położonych w równej odległości od węzła NUMA 0. Taka implementacja została pokazana na rysunku 5. Układ NUMA będzie opcją z możliwością dostrajania w następnym wydaniu systemu BIOS PowerEdge R7425. Uproszczenie odległości między węzłami NUMA nie zmienia rzeczywistego fizycznego układu rdzeni. Jego celem są głównie korzyści dla harmonogramu systemu operacyjnego. W przypadku zadań HPC i MPI z rozróżnieniem NUMA różne sposoby prezentacji powinny być nieistotne.


Rysunek 5 – Wynik numactl w konfiguracji EPYC z 2 gniazdami z uproszczonymi odległościami NUMA


Oprócz 8 węzłów NUMA na platformie z 2 gniazdami na rysunkach 4 i 5 pokazano pamięć i rdzenie powiązane z poszczególnymi węzłami NUMA. Każdy węzeł NUMA ma 32 GB pamięci w postaci dwóch modułów DIMM 16 GB (16 modułów DIMM na serwerze, osiem na gniazdo, 1 DIMM na kanał). Każdy węzeł NUMA zawiera osiem rdzeni matrycy lokalnej. Wyliczenie rdzeni na platformie Dell EMC jest działaniem okrężnym, które najpierw przechodzi przez wszystkie węzły NUMA, a następnie wypełnia każdy węzeł NUMA.

Ponadto wynik Istopo umożliwia wyraźne pokazanie, który zestaw czterech rdzeni tworzy kompleks rdzeni. Są to cztery rdzenie na matrycy, które współdzielą pamięć podręczną L3. Na przykład rysunek 6 pokazuje, że węzeł NUMA 0 ma osiem rdzeni i w tym węźle NUMA rdzenie 0, 16, 32, 48 współdzielą pamięć podręczną L3 oraz rdzenie 8, 24, 40, 56 współdzielą pamięć podręczną L3.


Rysunek 6 – Wynik Istopo na platformie EPYC z 2 gniazdami


Rysunek 7 – Przepustowość pamięci platformy AMD EPYC

Uwzględniając informacje na temat układu NUMA, wyniki testu porównawczego STREAM Triad dotyczące przepustowości pamięci zostały pokazane na rysunku 7 z ustawieniem BIOS „Memory Channel Interleaving” (Przeplatanie kanałów pamięci). Należy pamiętać, że dwuwarstwowe moduły pamięci 16 GB 2667 Mt/s używane w tym teście pracują na poziomie 2400 MT/s w procesorach EPYC. Pierwszy zestaw słupków na rysunku 7 przedstawia przepustowość pamięci na platformie z 2 gniazdami na poziomie 244 GB/s podczas używania wszystkich rdzeni oraz 255,5 GB/s podczas używania połowy rdzeni. Drugi punkt danych to przepustowość pamięci jednego gniazda, stanowi około połowy platformy z 2 gniazdami, zgodnie z oczekiwaniami. Trzeci punkt danych mierzy przepustowość pamięci w węźle NUMA, pojedyncza matryca. Należy pamiętać, że każde gniazdo ma cztery matryce, a przepustowość matrycy wynosi około 1/¼ przepustowości gniazda. Matryca zawiera dwa kompleksy rdzeni. Korzystanie z rdzeni w jednym kompleksie rdzeni zapewnia ok. 30 GB/s. Korzystanie z rdzeni w obu kompleksach rdzeni w matrycy pozwala uzyskać pełną przepustowość matrycy, ok. 32 GB/s.

Imponująca przepustowość pamięci platformy z 2 gniazdami na poziomie 240–260 GB/s jest wynikiem ośmiu kanałów pamięci na gniazdo platformy. Co więcej, jeden rdzeń może zapewnić przepustowość pamięci ok. 24,5 GB/s w przypadku pamięci lokalnej, co jest doskonałym wynikiem dla jednowątkowej części aplikacji.

Patrząc na wpływ układu NUMA na dostęp zdalny do pamięci, rysunek 8 przedstawia względną przepustowość pamięci podczas dostępu rdzeni do pamięci w innej domenie NUMA. Dostęp do pamięci w tym samym gnieździe jest o ok. 30% wolniejszy, dostęp do pamięci w innym gnieździe jest o ok. 65% wolniejszy. W przypadku STREAM Triad wydaje się, że wybór dostępu do pamięci w jednym skoku (węzeł 6, 1 Infinity Fabric między gniazdami) lub w dwóch skokach (węzeł 4, 5, 7, 1 skok Inifinity Fabric między gniazdami + 1 skok lokalny Infinity Fabric) nie ma wymiernego wpływu na przepustowość pamięci. W przypadku aplikacji wrażliwych na przepustowość pamięci dobra lokalizacja pamięci będzie ważna dla wydajności nawet w tym samym gnieździe.


Rysunek 8 – Wpływ dostępu zdalnego do pamięci
 

---

Wydajność w teście porównawczym HPL

Następnie zmierzyliśmy moc obliczeniową procesora EPYC według testu porównawczego HPL. Procesor EPYC obsługuje instrukcje AVX i wydajność 8 FLOP/cykl. Do wykonania HPL na platformie użyliśmy liniowych bibliotek algebraicznych Open MPI i BLIS.

Teoretyczna wydajność naszego systemu testowego (dwa procesory EPYC 7601) to 64 rdzenie * 8 FLOP/cykl * częstotliwość zegara 2,2 GHz, czyli 1126 GFLOPS. Zmierzyliśmy 1133 GLOPS, tzn. wydajność na poziomie 100,6%.

Ponadto uruchomiliśmy HPL na procesorach EPYC 7551 (32 rdzenie, 2,0 GHz), EPYC 7351 (16 rdzeni, 2,4 GHz) i EPYC 7351P (1 gniazdo, 16 rdzeni, 2,4 GHz). W tych testach zmierzona wydajność HPL wyniosła 102–106% teoretycznej wydajności.

Wydajność wynosi ponad 100%, ponieważ procesor EPYC może utrzymać częstotliwości turbo powyżej częstotliwości bazowej podczas testu HPL.
 

---

Latencja i przepustowość InfiniBand

Następnie porównaliśmy wyniki mikrotestu porównawczego dotyczące latencji i przepustowości InfiniBand dwóch serwerów. Konfiguracja używana do tych testów została opisana w tabeli 1. Wyniki dotyczące latencji i przepustowości znajdują się na rysunku 9 i 10.


  Tabela 1 – Stanowisko testowe InfiniBand


Rysunek 9 – Latencja InfiniBand, z przełącznikiem

Uruchamiane polecenie: 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

Starannie przypięto proces MPI do węzła NUMA najbliżej HCA. Informacje te są dostępne w wyniku Istopo i w tym przypadku był to węzeł NUMA 6. Testy latencji zostały przeprowadzone przy użyciu OpenMPI i HPC-X. W przypadku akceleracji OpenMPI i MXM zmierzyliśmy latencję 1,17 µs, a w przypadku OpenMPI i UCX 1,10 µs. Wyniki dotyczące latencji uzyskane w przypadku HPC-X zostały przedstawione tutaj.

Na rysunku 9 latencja procesorów EPYC z włączonymi stanami C wynosi 1,07 µs, a latencja dla wszystkich rozmiarów komunikatów jest o ok. 2 do 9% lepsza z włączonymi stanami C niż z wyłączonymi stanami C. Włączone stany C umożliwiają bezczynnym rdzeniom pozostanie w głębszych stanach C, co pozwala na wyższe częstotliwości turbo w aktywnych rdzeniach, co ogranicza latencję.

Wyniki dotyczące przepustowości zostały pokazane na rysunku 10. Zmierzyliśmy przepustowość jednokierunkową 12,4 GB/s i przepustowość dwukierunkową 24,7 GB/s. Wyniki te są zgodne z oczekiwaniami dla EDR


Rysunek 10 – Przepustowość InfiniBand

Uruchamiane polecenie: 

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

 

Tabela 2 – Wyniki osu_mbw_mr – jeden węzeł NUMA
Uruchamiane polecenie: 

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

Układ NUMA opisany na rysunku 3 i 6 wymagał sprawdzenia wpływu lokalności procesu na przepustowość. Do tego testu użyliśmy testu porównawczego osu_mbw_mr, który mierzy łączną przepustowość jednokierunkową między wieloma parami procesów. Celem tego testu jest ustalenie uzyskanej przepustowości i szybkości komunikatów między pojedynczymi węzłami NUMA przy użyciu wszystkich ośmiu rdzeni w węźle NUMA. Wyniki tego testu zostały przedstawione w tabeli 2. Konfiguracja testowa korzystała z profilu wydajnościowego (stany C wyłączone i funkcja Turbo włączona).

Wyniki pokazują, że kiedy procesy są uruchomione w węźle NUMA, który jest podłączony do HCA InfiniBand (węzeł NUMA 6), łączna przepustowość wynosi 12,3 GB/s. Podczas wykonywania procesów w dowolnym z pozostałych trzech węzłów NUMA w tym samym gnieździe co HCA (gniazdo 1) łączna przepustowość jest zbliżona, wynosi ok. 12,1 GB/s. Podczas wykonywania procesów w węzłach NUMA w gnieździe zdalnym względem HCA łączna przepustowość spada do ok. 6,8 GB/s.

Następny zbiór wyników pokazanych w tabeli 3 przedstawia przepustowość jednokierunkową między pojedynczymi gniazdami. Podczas tego testu używano wszystkich 32 rdzeni dostępnych w gnieździe. Zmierzyliśmy przepustowość 5,1 GB/s po uruchomieniu w gnieździe lokalnym względem HCA i 2,4 GB/s po uruchomieniu w gnieździe zdalnym względem HCA. Używając wszystkich 64 rdzeni w serwerach testowych, zmierzyliśmy przepustowość 3,0 GB/s po uruchomieniu 64 procesów na serwer.

Aby dokładnie sprawdzić ten ostatni wynik, przeprowadziliśmy test przy użyciu wszystkich 8 węzłów NUMA w obu gniazdach z 2 procesami uruchomionymi w każdym węźle NUMA, co daje łącznie 16 procesów na serwer. W tym układzie także zmierzono przepustowość 2,9 GB/s.

Wyniki te wskazują, że topologia systemu wpływa na wydajność komunikacji. Jest to interesujące w przypadkach, w których schemat komunikacji wszystkie-wszystkie z wieloma procesami komunikującymi się między serwerami jest ważnym czynnikiem. W przypadku innych aplikacji istnieje możliwość, że zmniejszona przepustowość zmierzona podczas uruchomienia procesów w wielu domenach NUMA może nie być czynnikiem wpływającym na wydajność na poziomie aplikacji.


  Tabela 3 – Wyniki osu_mbw_br – poziom gniazda i systemu
Uruchamiane polecenie: 

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

 
Uruchamiane polecenie:

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

 
Uruchamiane polecenie: 

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

---

Wydajność na poziomie klastra HPL

Po sprawdzeniu wydajności sieci szkieletowej InfiniBand następnym testem było szybkie wykonywanie HPL w całym klastrze. Testy te były wykonywane w systemie 16-węzłowym z dwoma gniazdami EPYC 7601. Wyniki na rysunku 11 pokazują oczekiwaną skalowalność HPL w 16 systemach.


Rysunek 11 – HPL między 16 serwerami

 

---

Wydajność na poziomie klastra WRF

Na koniec uruchomiliśmy WRF, aplikację do prognozowania pogody. Stanowisko testowe było takie jak przedtem, system 16-węzłowy z dwoma gniazdami EPYC 7601. Ponadto wykonaliśmy także kilka testów w mniejszym systemie 4-węzłowym z dwoma gniazdami EPYC 7551. Wszystkie serwery mają 16 GB * 16 RDIMM z szybkością 2400 MT/s i były połączone przez Mellanox EDR InfiniBand.


Rysunek 12 – Stożek WRF 12 km, jeden węzeł

Użyliśmy WRF w wersji 3.8.1 i 3.9.1 oraz przetestowaliśmy zbiory danych stożka 12 km i stożka 2,5 km. Skompilowaliśmy WRF i netcfd przy użyciu kompilatorów Intel i uruchomiliśmy Intel MPI. Wypróbowaliśmy inny proces i schematy przechylenia przy użyciu opcji konfiguracji dmpar, a także dm+sm przy użyciu OpenMP.

Współpracujemy z firmą AMD w celu określenia innych opcji strojenia kompilatora dla WRF.

Nie zmierzyliśmy różnicy wydajności między wersjami WRF 3.8.1 i 3.9.1. W przypadku porównania dmpar i dm+sm wynikiem rozsądnej kombinacji procesów i kafelków była w przybliżeniu taka sama wydajność. Zostało to pokazane na rysunku 12.


Rysunek 13 – Stożek WRF 12 km, testy klastrów


Rysunek 14 – Stożek WRF 2,5 km, testy klastrów

Testy na poziomie klastra zostały przeprowadzone przy użyciu WRV 3.8.1 i konfiguracji dmpar ze wszystkimi rdzeniami i 8 kafelkami na uruchomienie.

Stożek 12 km jest mniejszym zbiorem danych, a wydajność ulega spłaszczeniu po 8 węzłach, 512 rdzeni na EPYC. Zostało to pokazane na rysunku 13. EPYC 7551 i EPYC 7601 to procesory 32-rdzeniowe z częstotliwością zegara bazowego 7601 i częstotliwością turbo wszystkich rdzeni o 10% i 6% wyższą niż 7551. Podczas testów stożka WRF 12 km działanie systemu EPYC 7601 było o 3% szybsze niż 7551 niż w testach węzła 1, 2 i 4.

Stożek 2,5 km jest większym zbiorem danych porównawczych, a względem systemu z 1 procesorem EPYC skaluje się dobrze do 8 węzłów (512 rdzeni), a następnie wydajność zaczyna spadać. W przypadku stożka 2,5 km system EPYC 7601 działa o 2–3% szybciej niż EPYC 7551 podczas testów z 1, 2 i 4 węzłami, co pokazano na rysunku 14.

 

---

Wniosek i kolejne kroki

Procesor EPYC zapewnia dobrą przepustowość pamięci i gęstość rdzeni na gniazdo. Z punktu widzenia HPC oczekujemy, że aplikacje, które mogą używać dostępnej przepustowości pamięci i rdzeni procesorów, będą mogły korzystać z architektury EPYC. Obecnie EPYC nie obsługuje AVX512 ani AVX2 w jednym cyklu, dlatego kody o wysokiej wektorowości, które mogą efektywnie korzystać z AVX2 lub AVX512, mogą nie być idealne dla architektury EPYC.

Przypadki użycia, które mogą wykorzystywać wiele napędów NVMe i mogą także skorzystać z podłączonego bezpośrednio interfejsu NVMe, również są możliwe ze względu na liczbę torów PCI-E w procesorze EPYC.

Nasze kolejne kroki obejmują dalsze testy wydajności z dodatkowymi aplikacjami HPC.