AMD EPYC – Leistungsstudie zu STREAM, HPL, InfiniBand und WRF

---

Übersicht

Das HPC and AI Innovation Lab verfügt über ein neues Cluster mit 32 AMD EPYC-basierten Systemen, die mit Mellanox EDR InfiniBand verbunden sind. Wie immer führen wir Leistungsbewertungen für unseren neuesten Cluster durch und wollten die Ergebnisse veröffentlichen. In diesem Blog werden die Ergebnisse der Speicherbandbreite von STREAM, HPL, InfiniBand-Mikro-Benchmark-Performance für Latenz und Bandbreite und WRF-Ergebnisse aus den Benchmark-Datensätzen beschrieben.

Wir sind an der realen Leistung von HPC-Anwendungen auf EPYC interessiert. Wenn Sie Datensätze haben, die Sie mit EPYC testen möchten, wenden Sie sich an Ihr Dell Account-Team, um Zugriff auf das Innovation Lab zu erhalten.
 

---

AMD EPYC-Architektur

AMD EPYC-Prozessoren unterstützen acht Speicherkanäle, bis zu 16 DIMMs (Dual In-line Memory Modules) pro Sockel mit zwei DIMMs pro Kanal und bis zu 32 Kerne pro Sockel. Außerdem bietet eine Plattform mit AMD-CPUs bis zu 128 PCI-E-Lanes für Peripheriegeräte wie GPUs und NVMe-Laufwerke.
Die CPUs selbst sind Multi-Chip-Module, die aus vier Chips zusammengesetzt sind. Jeder Chip enthält bis zu acht Zen-Kerne, zwei DDR4-Speicherkanäle und 32 E/A-Lanes. Die Zen-Kerne auf einem Chip sind in zwei Vierergruppen angeordnet, wobei jede Vierergruppe als Kernkomplex bezeichnet wird und sich den L3-Cache teilt. Innerhalb eines Sockels sind alle vier Chips über eine zusammenhängende Verbindung namens Infinity Fabric über Crossconnect verbunden. Dies ist in Abbildung 1 dargestellt.


Abbildung 1 – EPYC-Sockellayout. CCX ist ein Kernkomplex von bis zu 4 Kernen, die sich den L3-Cache teilen. M* sind die Speicherkanäle, zwei Kanäle, die von jedem Chip gehandhabt werden. P* und G* sind E/A-Lanes. ∞ ist die Infinity-Fabric.



In einem Single-Socket-System stellt jeder Chip bis zu 32 PCI-E-Lanes bereit, wobei die in Abbildung 1 gezeigten P* und G* E/A-Lanes verwendet werden. Auf diese Weise erhält der Sockel insgesamt 128 PCI-E-Lanes, wie in Abbildung 2 gezeigt. Wenn eine CPU in einer 2S-Konfiguration (Two-Socket) verwendet wird, wird die Hälfte der E/A-Lanes jedes Chips verwendet, um mithilfe der als Infinity Fabric konfigurierten G* E/A-Lanes eine Verbindung mit einem der Chips auf dem anderen Sockel herzustellen. Damit verbleibt der Socket mit den P* E/A-Lanes für insgesamt 64 PCI-E-Lanes und damit noch 128 PCI-E-Lanes für die Plattform. Dies ist in Abbildung 3 dargestellt.


Abbildung 2 – EPYC 1S PCI-E-Lanes




Abbildung 3: EPYC 2S-Layout




Abbildung 3: EPYC 2S-Layout

 

---

STREAM-Benchmark-Performance

Als ersten Schritt zur Evaluierung von EPYC haben wir die Speicherbandbreitenfähigkeiten der Plattform mit dem STREAM-Benchmark gemessen. Diese Tests wurden auf einem Dell EMC PowerEdge R7425-Server durchgeführt, mit zwei AMD EPYC 7601-Prozessoren (32c, 2,2 GHz), 16*16-GB-DIMMs mit 2400 Mt/s und dem Betriebssystem Red Hat® Enterprise Linux® 7.5.

Die NUMA-Darstellung (Non-Uniform Memory Access) von EPYC kann über eine BIOS-Option namens „Memory Interleaving“ gesteuert und mit Linux-Dienstprogrammen wie numactl und lstopo abgebildet werden.

Die Standardoption für das Memory-Interleaving ist „Memory Channel Interleaving“. In diesem Modus sind die beiden Kanäle jedes Chips verschachtelt. Dies stellt dem Betriebssystem auf einem 2S-System vier NUMA-Knoten pro Sockel, also acht NUMA-Knoten, zur Verfügung.

„Memory Die Interleaving“ ist eine Option, bei der der Speicher auf allen vier Chips eines Sockels, d. h., auf acht Speicherkanälen, verschachtelt ist. Dies bietet einen NUMA-Knoten pro Sockel, also zwei NUMA-Knoten pro 2S-System.

Durch „Memory Socket Interleaving“ wird der Speicher beider Sockel verschachtelt, sodass ein NUMA-Knoten auf einer 2S-Plattform vorhanden ist. Dies ist das Äquivalent zu „NUMA disabled“.    

Denken Sie bei Verwendung der Standardkonfiguration von „Memory Channel Interleaving“ daran, dass jeder Sockel vier Chips hat, jeder Chip zwei Speicherkanäle bietet und das BIOS acht NUMA-Knoten auf einer 2S-Plattform darstellt. Als Beispiel für eine numactl-Ausgabe finden Sie in Abbildung 4 diese acht NUMA-Knoten auf einer 2S-Plattform, was einem NUMA-Knoten pro Chip entspricht.


Abbildung 4 – numactl-Ausgabe auf 2S-EPYC


Physisch gibt es vier NUMA-Abstände auf der Plattform, wie in Abbildung 4 hervorgehoben: zum NUMA-Knoten selbst (Abstand „10“ in Rot), zu den drei Knoten, die denselben Chip teilen (Abstand „16“ in Blau), zum Knoten auf dem anderen Sockel, der direkt über eine Infinity Fabric-Verbindung (Abstand „22“ in Grün) mit den drei anderen Knoten auf dem Remote-Sockel verbunden ist, auf die über zwei Hops mithilfe des Infinity Fabric zwischen den beiden Sockeln und der internen Infinity Fabric-Verbindung zugegriffen wird (Abstand „28“ in Schwarz).

Einige BIOS-Implementierungen und -Versionen vereinfachen möglicherweise dieses physische Layout und bieten nur drei NUMA-Entfernungen zum Betriebssystem. Diese Vereinfachung beinhaltet das Maskieren des Abstandsunterschieds zwischen dem NUMA-Knoten 0 (als Beispiel) und den NUMA-Knoten 4, 5, 6, 7, indem die NUMA-Knoten 4, 5, 6, 7 als gleich weit entfernt zum NUMA-Knoten 0 dargestellt werden. Eine solche Implementierung ist in Abbildung 5 dargestellt. Das NUMA-Layout ist in der nächsten Version des PowerEdge R7425-BIOS eine einstellbare Option. Durch die Vereinfachung der NUMA-Knotenabstände wird das tatsächliche physische Layout der Kerne nicht geändert. Dies ist in erster Linie für den OS-Scheduler von Vorteil. Für HPC- und MPI-Jobs, die NUMA-fähig sind, sollten diese unterschiedlichen Darstellungen unerheblich sein.


Abbildung 5: numactl-Ausgabe auf 2S-EPYC mit vereinfachten NUMA-Entfernungen


Neben den 8 NUMA-Knoten auf einer Zwei-Sockel-Plattform werden in Abbildung 4 und Abbildung 5 auch der mit jedem NUMA-Knoten verknüpfte Speicher und die zugehörigen Kerne angezeigt. Jeder NUMA-Knoten verfügt über 32 GB Speicher von zwei 16-GB-DIMMs (16 DIMMs im Server, acht pro Sockel, 1 DIMM pro Kanal). Jeder NUMA-Knoten enthält die acht Kerne des lokalen Chips. Die Kernaufzählung auf der Dell EMC-Plattform erfolgt im Rundlaufverfahren, bei dem zuerst alle NUMA-Knoten durchsucht werden und dann jeder NUMA-Knoten gefüllt wird.

Darüber hinaus kann mit der Ausgabe von lstopo deutlich gezeigt werden, aus welchem Satz von vier Kernen ein Kernkomplex besteht. Dies sind die vier Kerne auf einem Chip, die sich den L3-Cache teilen. Beispielsweise zeigt Abbildung 6, dass der NUMA-Knoten 0 acht Kerne hat und auf diesen NUMA-Knoten teilen sich die Kerne 0, 16, 32, 48 den L3-Cache und die Kerne 8, 24, 40, 56 den L3-Cache.


Abbildung 6 – lstopo-Ausgabe auf 2S EPYC


Abbildung 7 – Speicherbandbreite der AMD EPYC-Plattform

Unter Berücksichtigung dieser NUMA-Layoutinformationen sind die STREAM Triad-Benchmarkergebnisse für die Speicherbandbreite in Abbildung 7 dargestellt, wobei das BIOS auf „Memory Channel Interleaving“ eingestellt ist. Beachten Sie, dass die 16 GB 2667 MT/s Dual-Rank-Speichermodule, die in dieser Testumgebung verwendet werden, auf 2400 MT/s auf EPYC ausgeführt werden. Der erste Balkensatz in Abbildung 7 zeigt die Speicherbandbreite der 2S-Plattform mit 244 Gbit/s, wenn alle Kerne verwendet werden, und 255,5 Gbit/s, wenn die Hälfte der Kerne genutzt wird. Der zweite Datenpunkt ist die Speicherbandbreite eines einzelnen Sockels und das ist erwartungsgemäß etwa die Hälfte der gesamten 2S-Plattform. Der dritte Datenpunkt misst die Speicherbandbreite eines NUMA-Knotens, eines einzelnen Chips. Denken Sie daran, dass jeder Sockel vier Chips hat und die Bandbreite eines Chips ungefähr ein ¼ des Sockels ist. Innerhalb eines Würfels gibt es zwei Kernkomplexe, und wenn nur die Kerne eines Kernkomplexes verwendet werden, ergeben sich ~30 Gbit/s. Wenn Kerne für beide Kernkomplexe auf einem Chip verwendet werden, kann die volle Bandbreite des Chips von ~32 Gbit/s erreicht werden.

Die Speicherbandbreite der 2S-Plattform ist beeindruckend, 240 bis 260 Gbit/s, und ergibt sich aus den acht Speicherkanälen pro Sockel auf der Plattform. Darüber hinaus kann ein einzelner Kern eine Speicherbandbreite von ~24,5 Gbit/s für den lokalen Speicher bereitstellen, was für den Single-Thread-Teil von Anwendungen hervorragend geeignet ist.

In Abbildung 8 wird der Einfluss des NUMA-Layouts auf den Remote-Speicherzugriff dargestellt. Dabei wird die relative Speicherbandbreite dargestellt, wenn Cores auf Speicher zugreifen, die sich nicht in derselben NUMA-Domäne befinden. Der Zugriff auf den Speicher auf demselben Sockel ist ~30 % langsamer, der Zugriff auf den Speicher auf dem anderen Sockel ist ~65 % langsamer. Mit STREAM Triad scheint es keine messbaren Auswirkungen auf die Speicherbandbreite zu geben, wenn auf den Speicher des Remote-Sockels über einen Hop (Knoten 6, 1 Infinity Fabric zwischen Sockeln) oder zwei Hops (Knoten 4, 5, 7 – 1 Infinity Fabric-Hop zwischen Sockeln und 1 lokaler Infinity Fabric-Hop) zugegriffen wird. Für Anwendungen mit hohem Speicherbandbreitenbedarf ist eine gute Speicherlokalität wichtig, um die Leistung auch innerhalb desselben Sockels zu verbessern.


Abbildung 8: Auswirkungen des Remotespeicherzugriffs
 

---

HPL-Benchmark-Performance

Als nächstes maßen wir die Rechenfähigkeit von EPYC wie durch das HPL-Benchmark gemessen. EPYC unterstützt AVX-Anweisungen und eine Performance von 8 FLOP/Zyklus. Auf unserer Plattform verwendeten wir Open MPI und die linearen Algebra-Bibliotheken BLIS zum Ausführen von HPL.

Die theoretische Leistung unseres Testsystems (zwei EPYC 7601-Prozessoren) beträgt 64 Kerne * 8 FLOP/Zyklus * 2,2 GHz Taktfrequenz, was 1126 GFLOPS ergibt. Wir haben 1133 GLOPS gemessen, was einem Wirkungsgrad von 100,6% entspricht.

Wir haben auch HPL auf den EPYC 7551 (32c, 2,0 GHz), EPYC 7351 (16c, 2,4 GHz) und EPYC 7351P (1S, 16c und 2,4 GHz) ausgeführt. Bei diesen Tests lag die gemessene HPL-Performance bei 102-106 % der theoretischen Leistung.

Der Wirkungsgrad liegt über 100%, da EPYC in der Lage ist, Turbofrequenzen über der Grundfrequenz während der Dauer des HPL-Tests aufrechtzuerhalten.
 

---

InfiniBand – Latenz und Bandbreite

Wir haben dann die Ergebnisse der InfiniBand-Latenz und des Bandbreiten-Mikro-Benchmark zwischen zwei Servern überprüft. Die für diese Tests verwendete Konfiguration ist in Tabelle 1 beschrieben. Die Ergebnisse zu Latenz und Bandbreite sind in Abbildung 9 und Abbildung 10 dargestellt.


  Tabelle 1 – InfiniBand-Testumgebung


Abbildung 9 – InfiniBand-Latenz mit Switch

Führen Sie folgenden Befehl aus: 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

Es wurde darauf geachtet, den MPI-Prozess mit dem NUMA-Knoten zu verbinden, der dem HCA am nächsten liegt. Diese Informationen sind in der Ausgabe von lstopo verfügbar, in unserem Fall war es NUMA-Knoten 6. Latenztests wurden sowohl mit OpenMPI als auch mit HPC-X durchgeführt. Mit OpenMPI und MXM-Beschleunigung haben wir eine Latenz von 1,17 µs gemessen, mit OpenMPI und UCX haben wir eine Latenz von 1,10 µs gemessen. Die mit HPC-X erzielten Latenzergebnisse sind hier dargestellt.

In Abbildung 9 beträgt die Latenz auf EPYC-Prozessoren mit aktivierten C-Zuständen 1,07 µs und die Latenz für alle Nachrichtengrößen ist ~2 bis 9 % besser mit aktivierten C-Zuständen im Vergleich zu deaktivierten C-Zuständen. Durch die Aktivierung der C-Zustände können sich Leerlaufkerne in tieferen C-Zuständen befinden, wodurch höhere Turbofrequenzen auf den aktiven Kernen möglich sind. Dies führt zu einer verringerten Latenz.

Die Ergebnisse der Bandbreite sind in Abbildung 10 dargestellt. Wir haben eine unidirektionale Bandbreite von 12,4 Gbit/s und eine bidirektionale Bandbreite von 24,7 Gbit/s gemessen. Diese Ergebnisse entsprechen den Erwartungen an EDR.


Abbildung 10: InfiniBand-Bandbreite

Führen Sie folgenden Befehl aus: 

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

 

Tabelle 2: Ergebnisse für osu_mbw_mr – einzelner NUMA-Knoten
Führen Sie folgenden Befehl aus: 

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

Das in Abbildung 3 und Abbildung 6 beschriebene NUMA-Layout veranlasste uns, die Auswirkungen der Prozesslokalität auf die Bandbreite zu überprüfen. Für diesen Test haben wir den osu_mbw_mr-Benchmark verwendet, der die aggregierte unidirektionale Bandbreite zwischen mehreren Prozesspaaren misst. Ziel dieses Tests ist es, die erreichte Bandbreite und Nachrichtenrate zwischen einzelnen NUMA-Knoten unter Verwendung aller acht Kerne auf dem NUMA-Knoten zu bestimmen. Die Ergebnisse dieses Tests sind in Tabelle 2 dargestellt. Die Testkonfiguration verwendete das Leistungsprofil (C-Zustände deaktiviert und Turbo aktiviert).

Die Ergebnisse zeigen, dass bei Ausführung von Prozessen auf dem NUMA-Knoten, der mit dem InfiniBand-HCA (NUMA-Knoten 6) verbunden ist, die Gesamtbandbreite 12,3 Gbit/s beträgt. Wenn Prozesse auf einem der drei anderen NUMA-Knoten ausgeführt werden, die sich im selben Sockel wie der HCA (Sockel 1) befinden, beträgt die Gesamtbandbreite ungefähr 12,1 Gbit/s. Wenn Prozesse auf den NUMA-Knoten in dem Sockel ausgeführt werden, der vom HCA entfernt ist, sinkt die Gesamtbandbreite auf ~6,8 Gbit/s.

Der nächste in Tabelle 3 gezeigte Satz von Ergebnissen demonstriert die unidirektionale Bandbreite zwischen einzelnen Sockeln. Für diesen Test wurden alle 32 im Sockel vorhandenen Kerne verwendet. Wir haben beim Betrieb auf dem lokalen Sockel zum HCA 5,1 Gbit/s gemessen und 2,4 GB / s beim Betrieb auf dem entfernten Socket zum HCA. Unter Verwendung aller 64 Kerne in unseren Testservern haben wir 3,0 Gbit/s gemessen, wenn 64 Prozesse pro Server ausgeführt wurden.

Um dieses letzte Ergebnis noch einmal zu überprüfen, haben wir einen Test mit allen 8 NUMA-Knoten auf beiden Sockeln durchgeführt, wobei jeder NUMA-Knoten 2 Prozesse ausführte, was insgesamt 16 Prozesse pro Server ergab. Bei diesem Layout wurden auch 2,9 Gbit/s gemessen.

Diese Ergebnisse weisen darauf hin, dass sich die Topologie des Systems auf die Kommunikationsleistung auswirkt. Dies ist in Fällen von Interesse, in denen ein Gesamtkommunikationsmuster mit mehreren Prozessen, die über Server hinweg kommunizieren, ein wichtiger Faktor ist. Bei anderen Anwendungen ist es möglich, dass die reduzierte Bandbreite, die beim Ausführen von Prozessen in mehreren NUMA-Domänen gemessen wird, keinen Einfluss auf die Leistung auf Anwendungsebene hat.


  Tabelle 3: Ergebnisse für osu_mbw_br – Sockel und Systemebene
Führen Sie folgenden Befehl aus: 

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

 
Führen Sie folgenden Befehl aus:

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

 
Führen Sie folgenden Befehl aus: 

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-Leistung auf Cluster-Ebene

Nach der Überprüfung der InfiniBand-Fabric-Leistung bestand der nächste Test darin, HPL schnell im Cluster auszuführen. Diese Tests wurden an einem 16-Knoten-System mit Dual Socket EPYC 7601 durchgeführt. Die Ergebnisse sind in Abbildung 11 dargestellt und zeigen die erwartete HPL-Skalierbarkeit für die 16 Systeme.


Abbildung 11: HPL auf 16 Servern

 

---

WRF-Leistung auf Cluster-Ebene

Schließlich haben wir WRF ausgeführt, eine Anwendung für die Wettervorhersage. Die Testumgebung war dieselbe wie zuvor, 16-Knoten-System mit Dual Socket EPYC 7601. Außerdem haben wir einige Tests auf einem kleineren System mit 4 Knoten mit Dual Sockel EPYC 7551 durchgeführt. Alle Server hatten 16 GB* 16 RDIMMs, die auf 2400 MT/s ausgeführt wurden und mit Mellanox EDR InfiniBand verbunden waren.


Abbildung 12 - WRF-Konus 12 km, einzelner Knoten

Wir haben WRF v3.8.1 und v3.9.1 verwendet und die Datensätze „conus 12km“ und „conus 2.5km“ getestet. Wir haben WRF und netcdf mit Intel-Compilern kompiliert und mit Intel MPI ausgeführt. Wir haben verschiedene Prozess- und Kachelschemata ausprobiert, wobei sowohl dmpar als auch die Konfigurationsoption dm+sm mit OpenMP verwendet wurden.

Wir arbeiten mit AMD zusammen, um weitere Optimierungsoptionen für den Compiler für WRF zu ermitteln.

Es gab keinen gemessenen Leistungsunterschied zwischen WRF v3.8.1 und v3.9.1. Beim Vergleich von dmpar und dm+sm ergab eine vernünftige Kombination von Prozessen und Kacheln ungefähr die gleiche Leistung. Dies ist in Abbildung 12 dargestellt.


Abbildung 13 - WRF-Konus 12 km, Cluster-Tests


Abbildung 14 - WRF-Konus 2,5km, Cluster-Tests

Auf Cluster-Ebene wurden Tests mit WRV v3.8.1 und der dmpar-Konfiguration mit allen Kernen und 8 Kacheln pro Durchlauf durchgeführt.

„Conus 12km“ ist ein kleinerer Datensatz mit einer Leistung, die nach 8 Knoten mit 512 Kernen auf EPYC auf ein Plateau gelangt. Dies ist in Abbildung 13 dargestellt. Der EPYC 7551 und der EPYC 7601 sind beide 32-Kern-Prozessoren mit einer Basistaktfrequenz von 7601 und einer All-Kern-Turbofrequenz von 10 % bzw. 6 % höher als der 7551. Bei Tests mit „WRF Conus 12km“ lag die Performance des EPYC 7601-Systems um 3 % über der des 7551 bei Tests mit 1, 2 und 4 Knoten.

„Conus 2.5km“ ist ein größerer Benchmark-Datensatz und im Vergleich zu 1 EPYC-System skaliert die Leistung gut auf 8 Knoten (512 Kerne) und beginnt dann abzunehmen. Mit „Conus 2.5 km“ arbeitet das EPYC 7601-System 2–3 % schneller als der EPYC 7551 bei Tests mit 1, 2 und 4 Knoten, wie in Abbildung 14 gezeigt.

 

---

Fazit und nächste Schritte

EPYC bietet eine gute Speicherbandbreite und Kerndichte pro Sockel. Aus HPC-Sicht erwarten wir, dass Anwendungen, die die verfügbare Speicherbandbreite und die CPU-Kerne nutzen können, die EPYC-Architektur optimal nutzen können. EPYC unterstützt heute nicht AVX512 oder AVX2 in einem einzigen Zyklus. Daher sind Codes, die stark vektorisiert sind und AVX2 oder AVX512 effizient verwenden können, möglicherweise nicht ideal für EPYC.

Anwendungsfälle mit mehreren NVMe-Laufwerken können auch vom direkt angeschlossenen NVMe profitieren, das aufgrund der Anzahl der PCI-E-Lanes auf EPYC möglich ist.

Unsere nächsten Schritte umfassen weitere Leistungstests mit zusätzlichen HPC-Anwendungen.