AMD EPYC – Studio sulle prestazioni di STREAM, HPL, InfiniBand e WRF

---

Riepilogo

HPC and AI Innovation Lab offre un nuovo cluster con 32 sistemi basati su AMD EPYC interconnessi con Mellanox EDR InfiniBand. Come sempre, stiamo eseguendo valutazioni delle prestazioni sul nostro cluster più recente e volevamo condividere i risultati. Questo blog illustra i risultati della larghezza di banda di memoria ottenuti dalle prestazioni dei micro-benchmark di STREAM, HPL e InfiniBand per latenza e larghezza di banda, nonché i risultati WRF ottenuti dai dataset dei benchmark.

Ci interessano le prestazioni delle applicazioni HPC reali su EPYC. Per chi desidera testare alcuni dataset su EPYC, è possibile contattare l'Account Team Dell per accedere a Innovation Lab.
 

---

Architettura AMD EPYC

I processori AMD EPYC supportano otto canali di memoria, fino a 16 moduli (DIMM) per socket con due moduli DIMM per canale e fino a 32 core per socket. Inoltre, una piattaforma con CPU AMD fornisce fino a 128 corsie PCI-E per periferiche come GPU e unità NVMe.
Le stesse CPU sono moduli multichip assemblati da quattro matrici. Ogni matrice include fino a otto core Zen, due canali di memoria DDR4 e 32 corsie IO. I core Zen su una matrice sono organizzati in due gruppi di quattro. Ogni gruppo di quattro core, chiamato complesso core, condivide la cache L3. All'interno di un socket, tutte e quattro le matrici sono collegate tramite un'interconnessione coerente nota con il nome di Infinity Fabric, come mostrato nella Figura 1.


Figura 1: layout di un socket EPYC. CCX è un complesso costituito da un massimo di 4 core che condividono la cache L3. M* rappresentano i canali di memoria, due canali gestiti da ogni matrice. P* e G* sono corsie IO. ∞ è Infinity Fabric.



In un sistema a socket singolo, ogni matrice fornisce fino a 32 corsie PCI-E con le corsie IO G* e P* mostrate nella Figura 1. Il socket ha quindi un totale di 128 corsie PCI-E, come mostrato nella Figura 2. Se si utilizza una CPU in una configurazione a due socket (2S), metà delle corsie IO di ogni matrice viene utilizzata per connettersi a una delle matrici nell'altro socket mediante le corsie IO G* configurate come Infinity Fabric. Per il socket rimangono disponibili le corsie IO P* per un totale di 64 corsie PCI-E e, quindi, sempre 128 corsie PCI-E per la piattaforma, come mostrato nella Figura 3


Figura 2: corsie PCI-E 1S EPYC




Figura 3: layout 2S EPYC




Figura 3: layout 2S EPYC

 

---

Prestazioni di benchmark STREAM

Per iniziare la valutazione di EPYC, abbiamo analizzato le funzionalità di larghezza di banda della memoria della piattaforma utilizzando il benchmark STREAM. Questi test sono stati eseguiti su un server Dell EMC PowerEdge R7425 con due processori AMD EPYC 7601 (32 core, 2,2 GHz), 16 DIMM da 16 GB a 2.400 m/s che eseguono Red Hat® Enterprise Linux® 7.5.

La presentazione di accesso non uniforme alla memoria (NUMA, Non-Uniform Memory Access) di EPYC può essere controllata tramite un'opzione del BIOS denominata "Memory Interleaving" e mappata mediante utilità Linux come numactl e lstopo.

L'opzione predefinita di Memory Interleaving è "Memory Channel Interleaving". In questa modalità, i due canali di ciascuna matrice sono interfogliati, con quattro nodi NUMA per socket e otto nodi NUMA per il sistema operativo su un sistema 2S.

"Memory Die Interleaving" è un'opzione in cui le memorie in tutte e quattro le matrici in un socket, ovvero otto canali di memoria, sono interfogliate, con un nodo NUMA per socket e due nodi NUMA su un sistema 2S.

"Memory Socket Interleaving" esegue l'interfoliazione della memoria in entrambi i socket, con un nodo NUMA su una piattaforma 2S (equivalente alla disabilitazione di NUMA).    

Utilizzando la configurazione predefinita di "Memory Channel Interleaving", tenere presente ogni socket ha quattro matrici, ciascuna matrice fornisce due canali di memoria e il BIOS presenta otto nodi NUMA su una piattaforma 2S. L'output numactl di esempio nella Figura 4 mostra questi otto nodi NUMA su una piattaforma 2S, un nodo NUMA per matrice.


Figura 4: output numactl su 2S EPYC


Fisicamente, sono presenti quattro distanze NUMA sulla piattaforma, come evidenziato nella Figura 4: dal nodo NUMA stesso (distanza "10" in rosso), dai tre nodi che condividono la stessa matrice (distanza "16" in blu), dal nodo sull'altro connettore con connessione diretta tramite un link Infinity Band (distanza "22" in verde) e dagli altri tre nodi sul socket remoto a cui si accede tramite due hop mediante il link Fabric Infinity tra i due socket più il link Fabric Infinity interno (distanza "28" in nero).

Alcune implementazioni e versioni del BIOS possono semplificare questo layout fisico e presentare solo tre distanze NUMA dal sistema operativo. La semplificazione prevede il masking della differenza di distanza tra il nodo NUMA 0 (ad esempio) e i nodi NUMA 4, 5, 6, 7, presentando i nodi NUMA 4, 5, 6, 7 come equidistanti dal nodo NUMA 0. Questa implementazione è mostrata nella Figura 5. Il layout NUMA verrà ottimizzato nella prossima versione del BIOS di PowerEdge R7425. La semplificazione delle distanze dei nodi NUMA non modifica il layout fisico effettivo dei core, ma è essenzialmente a vantaggio dell'utilità di pianificazione del sistema operativo. Per i processi HPC e MPI compatibili con NUMA, queste varie presentazioni dovrebbero essere irrilevanti.


Figura 5: output numactl su 2S EPYC con distanze NUMA semplificate


Oltre agli 8 nodi NUMA su una piattaforma a due socket, la Figura 4 e Figura 5 mostrano anche la memoria e i core associati a ciascun nodo NUMA. Ogni nodo NUMA è caratterizzato da 32 GB di memoria di due moduli DIMM da 16 GB (16 moduli DIMM nel server, otto per socket, 1 modulo DIMM per canale). Ogni nodo NUMA contiene gli otto core della matrice locale. L'enumerazione dei core nella piattaforma Dell EMC è d tipo Round Robin: attraversando prima tutti i nodi NUMA e riempiendo quindi ogni singolo nodo.

È anche possibile utilizzare l'output lstopo per mostrare chiaramente il set di quattro core che costituiscono un complesso. Questi sono i quattro core su una matrice che condividono la cache L3. Ad esempio, la Figura 6 mostra che il nodo NUMA 0 ha otto core e su questo nodo NUMA i core 0, 16, 32 e 48 condividono la cache L3 e i core 8, 24, 40 e 56 condividono la cache L3.


Figura 6: output lstopo su 2S EPYC


Figura 7: larghezza di banda della memoria della piattaforma AMD EPYC

Tenendo conto di queste informazioni sul layout NUMA, i risultati dei benchmark STREAM Triad per la larghezza di banda della memoria vengono visualizzati nella Figura 7 con il BIOS impostato su "Memory Channel Interleaving". Si noti che i moduli di memoria dual rank da 16 GB a 2.667 m/s utilizzati in questo banco di prova vengono eseguiti a 2.400 m/s in EPYC. Il primo set di barre nella Figura 7 mostra la larghezza di banda della memoria della piattaforma 2S a 244 GB/s quando vengono utilizzati tutti i core e 255,5 GB/s quando viene utilizzata metà dei core. Il secondo data point è la larghezza di banda della memoria di un singolo socket, corrispondente a circa metà dell'intera piattaforma 2S, come previsto. Il terzo data point misura la larghezza di banda della memoria di un nodo NUMA, una singola matrice. Tenere presente che ogni socket include quattro matrici e che la larghezza di banda di una matrice corrisponde a circa ¼ del socket. All'interno di una matrice sono presenti due complessi core e l'utilizzo dei core su un solo complesso fornisce circa 30 GB/s. Quando vengono utilizzati i core in entrambi i complessi su una matrice, è possibile ottenere la larghezza di banda completa della matrice, ovvero circa 32 GB/s.

La larghezza di banda della memoria della piattaforma 2S è impressionante, 240-260 GB/s, ed è il risultato degli otto canali di memoria per socket sulla piattaforma. Inoltre, un singolo core può fornire una larghezza di banda della memoria di circa 24,5 GB/s alla memoria locale, ideale per la porzione a singolo thread delle applicazioni.

Esaminando l'impatto del layout NUMA sull'accesso remoto alla memoria, la Figura 8 traccia la larghezza di banda della memoria relativa quando i core accedono a una memoria che non si trova nello stesso dominio NUMA. L'accesso alla memoria sullo stesso socket è più lento di circa il 30%, l'accesso sull'altro socket di circa il 65%. L'utilizzo di STREAM Triad non sembra avere alcun impatto misurabile sulla larghezza di banda della memoria quando si accede alla memoria nel socket remoto su un hop (node6, 1 Infinity Fabric tra i socket) o due hop (node4, 5, 7 - 1 hop Infinity Fabric tra i socket + 1 hop Infinity Fabric locale). Per le applicazioni sensibili alla larghezza di banda della memoria, un'allocazione adeguata della memoria sarà importante per le prestazioni anche all'interno dello stesso socket.


Figura 8: impatto dell'accesso remoto alla memoria
 

---

Prestazioni di benchmark HPL

È stata quindi misurata la funzionalità di calcolo di EPYC come in base al benchmark HPL. EPYC è in grado di supportare istruzioni AVX e prestazioni pari a 8 FLOP per ciclo. Sulla nostra piattaforma abbiamo utilizzato Open MPI e le librerie di algebra lineare BLIS per eseguire HPL.

Le prestazioni teoriche del nostro sistema di test (due processori EPYC 7601) sono pari a 64 core * 8 FLOP per ciclo * frequenza di clock a 2,2 GHz, per un totale di 1.126 GFLOPS. Abbiamo misurato 1.133 GLOPS, con un'efficienza del 100,6%.

Abbiamo anche eseguito HPL su EPYC 7551 (32 core, 2 GHz), EPYC 7351 (16 core, 2,4 GHz) ed EPYC 7351P (1S, 16 core, 2,4 GHz). In questi test, le prestazioni di HPL misurate erano pari al 102-106% delle prestazioni teoriche.

L'efficienza è superiore al 100%, poiché EPYC è in grado di supportare frequenze Turbo al di sopra della frequenza di base per la durata del test HPL.
 

---

Latenza e larghezza di banda di InfiniBand

Abbiamo quindi verificato i risultati dei micro-benchmark in termini di latenza e larghezza di banda di InfiniBand tra due server. La configurazione utilizzata per questi test è descritta nella Tabella 1. La latenza e i risultati della larghezza di banda sono indicati nella Figura 9 e nella Figura 10.


  Tabella 1 - Banco di prova di InfiniBand


Figura 9: latenza InfiniBand, con switch

Eseguire il comando: 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

È stata prestata attenzione ad aggiungere il processo MPI al nodo NUMA più vicino alla scheda HCA. Queste informazioni sono disponibili nell'output di lstopo e, nel nostro caso, si tratta di un nodo NUMA 6. I test di latenza sono stati eseguiti con OpenMPI e HPC-X. Con l'accelerazione OpenMPi e MXM abbiamo misurato una latenza di 1,17 µs, con OpenMPI e UCX una latenza di 1,10 µs. Qui vengono visualizzati i risultati della latenza ottenuta con HPC-X.

Dalla Figura 9, la latenza sui processori EPYC con stati C abilitati è pari a 1,07 µs e la latenza per tutte le dimensioni dei messaggi è superiore dal 2 al 9% con gli stati C abilitati rispetto agli stati C disabilitati. Con gli stati C abilitati, i core inattivi sono caratterizzati da stati C più profondi, che consentono frequenze Turbo più elevate sui core attivi, con una latenza conseguentemente ridotta.

Nella Figura 10 vengono visualizzati i risultati della larghezza di banda. Abbiamo misurato una larghezza di banda unidirezionale di 12,4 GB/s e una larghezza di banda bidirezionale di 24,7 GB/s. Questi sono i risultati previsti per EDR


Figura 10: larghezza di banda di InfiniBand

Eseguire il comando: 

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

 

Tabella 2: risultati di osu_mbw_mr, singolo nodo NUMA
Eseguire il comando: 

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

Con il layout NUMA descritto nella Figura 3 e nella Figura 6 abbiamo verificato l'impatto dell'allocazione del processo sulla larghezza di banda. Per questo test abbiamo utilizzato il benchmark osu_mbw_mr che misura la larghezza di banda unidirezionale aggregata tra più coppie di processi. L'obiettivo di questo test è quello di determinare la larghezza di banda e la frequenza dei messaggi tra singoli nodi NUMA utilizzando tutti gli otto core sul nodo NUMA. I risultati di questo test sono riportati nella Tabella 2. Per la configurazione di test è stato utilizzato il profilo Performance (stati C disattivati e modalità Turbo abilitata).

I risultati ci mostrano che, quando vengono eseguiti processi sul nodo NUMA connesso alla scheda HCA InfiniBand (nodo NUMA 6), la larghezza di banda aggregata è pari a 12,3 GB/s. Quando vengono eseguiti su uno qualsiasi degli altri tre nodi NUMA sullo stesso socket della scheda HCA (socket 1), la larghezza di banda aggregata è più o meno la stessa, ovvero circa 12,1 GB/s. Quando vengono eseguiti sui nodi NUMA nel socket remoto rispetto alla scheda HCA, la larghezza di banda aggregata scende a circa 6,8 GB/s.

Il set di risultati successivo mostrato nella Tabella 3 illustra la larghezza di banda unidirezionale tra singoli socket. Per questo test sono stati utilizzati tutti i 32 core disponibili nel socket. Abbiamo misurato 5,1 GB/s con processi in esecuzione sul socket locale rispetto alla scheda HCA e 2,4 GB/s con processi in esecuzione sul socket remoto rispetto alla scheda HCA. Utilizzando tutti i 64 core nei server di test, abbiamo misurato 3,0 GB/s in caso di esecuzione di 64 processi per server.

Per verificare quest'ultimo risultato, è stato eseguito un test utilizzando tutti gli 8 nodi NUMA su entrambi i socket, con 2 processi in esecuzione su ciascun nodo NUMA, per un totale di 16 processi per server. Anche con questo layout abbiamo misurato 2,9 GB/s.

Questi risultati indicano che la topologia del sistema ha effetto sulle prestazioni di comunicazione. Questa situazione risulta interessante nei casi in cui un modello di comunicazione all-to-all con più processi che comunicano tra server rappresenti un fattore importante. Per altre applicazioni, è possibile che la larghezza di banda ridotta misurata durante l'esecuzione dei processi su più domini NUMA possa non rappresentare un fattore che influenza le prestazioni a livello di applicazione.


  Tabella 3: risultati di osu_mbw_br, a livello di socket e di sistema
Eseguire il comando: 

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

 
Eseguire il comando:

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

 
Eseguire il comando: 

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

---

Prestazioni a livello di cluster HPL

Con le prestazioni del fabric InfiniBand convalidate, il test successivo è stato quello di eseguire rapidamente HPL in tutto il cluster. Questi test sono stati eseguiti su un sistema a 16 nodi con doppio socket EPYC 7601. I risultati sono mostrati nella Figura 11 e indicano la scalabilità HPL nei 16 sistemi.


Figura 11: HPL in 16 server

 

---

Prestazioni a livello di cluster WRF

Abbiamo infine eseguito WRF, un'applicazione di previsioni meteo. Il banco di prova era identico a quello precedente: un sistema a 16 nodi con doppio socket EPYC 7601. Inoltre, abbiamo eseguito alcuni test su un sistema ridotto a 4 nodi con doppio socket EPYC 7551. Tutti i server avevano 16 moduli RDIMM da 16 GB in esecuzione a 2.400 m/s ed erano interconnessi con Mellanox EDR InfiniBand.


Figure 12: WRF CONUS 12 km, nodo singolo

Abbiamo utilizzato WRF v3.8.1 e v3.9.1 e testato i data set CONUS 12 km e 2,5 km. Abbiamo compilato WRF e netcdf utilizzando i compilatori Intel e li abbiamo eseguiti con Intel MPI. Abbiamo provato schemi di processi e tiling diversi, utilizzando dmpar e l'opzione di configurazione dm+sm con OpenMP.

Stiamo collaborando con AMD per determinare altre opzioni di ottimizzazione del compilatore per WRF.

Non è stata misurata alcuna differenza in termini di prestazioni tra WRF v3.8.1 e v3.9.1. Confrontando dmpar e dm+sm, una combinazione oculata di processi e tile ha determinato più o meno le stesse prestazioni, come mostrato nella Figura 12.


Figure 13: WRF CONUS 12 km, cluster test


Figure 14: WRF CONUS 2,5 km, cluster test

I test a livello di cluster sono stati condotti con WRV v 3.8.1 e la configurazione di dmpar utilizzando tutti i core e 8 tile per esecuzione.

CONUS 12 km è un dataset ridotto e le prestazioni si sono stabilizzate dopo 8 nodi, 512 core su EPYC, come mostrato nella Figura 13. EPYC 7551 e EPYC 7601 sono entrambi processori a 32 core con frequenza di clock di base e frequenza Turbo per tutti i core di EPYC 7601 più veloce rispettivamente del 10% e del 6% rispetto a EPYC 7551. Nei test WRF CONUS 12 km, le prestazioni del sistema EPYC 7601 erano del 3% più veloci rispetto a quelle del sistema 7551 sui test a 1, 2 e 4 nodi.

CONUS 2,5 km è un data set di benchmark di dimensioni maggiori e, in relazione a un sistema EPYC, le prestazioni aumentano fino a 8 nodi (512 core), per poi iniziare a ridursi. Anche con CONUS 2,5 km, il sistema EPYC 7601 offre prestazioni più rapide del 2-3% rispetto a un sistema EPYC 7551 sui test a 1, 2 e 4 nodi, come mostrato nella Figura 14.

 

---

Conclusioni e fasi successive

EPYC offre livelli adeguati di larghezza di banda e densità di memoria per socket. Da un punto di vista di HPC, prevediamo che le applicazioni in grado di utilizzare la larghezza di banda della memoria e i core CPU disponibili possano sfruttare al meglio l'architettura EPYC. Attualmente EPYC non supporta AVX512 o AVX2 in un singolo ciclo, pertanto i codici altamente vettorizzati che possano utilizzare AVX2 o AVX512 in modo efficiente potrebbero non essere idonei per EPYC.

I casi d'uso in grado di utilizzare più unità NVMe possono trarre vantaggio dall'unità NVMe direttamente collegata, possibile per via del numero di corsie PCI-E su EPYC.

Le fasi successive includono ulteriori test delle prestazioni con applicazioni HPC aggiuntive.