AMD EPYC – STREAM、HPL、InfiniBand、WRFパフォーマンス スタディ

---

概要

HPCおよびAIイノベーション ラボには、Mellanox EDR InfiniBandと相互接続された32 AMD EPYCベースのシステムを備えた新しいクラスターが含まれます。EMCでは通常どおり、最新のクラスターでパフォーマンス評価を実施しています。その結果をここで共有させていただきます。このブログでは、レイテンシーおよび帯域幅のSTREAM、HPL、InfiniBandマイクロベンチマーク パフォーマンスの結果から得られるメモリー帯域幅と、ベンチマーク データセットの結果から得られるメモリー帯域幅について説明します。

弊社は、EPYCにおける現実のHPCアプリケーション パフォーマンスに関心を持っています。EPYCで試行するデータセットがある場合は、デル アカウント チームに問い合わせて、イノベーション ラボにアクセスしてください。
 

---

AMD EPYCアーキテクチャー

AMD EPYCプロセッサーは、8個のメモリー チャネル、ソケットあたり最大16個のデュアル インライン メモリー モジュール（DIMM）、チャネルあたり2枚のDIMM、ソケットあたり最大32コアをサポートしています。さらに、AMD CPUを搭載したプラットフォームは、GPUやNVMeドライブなどの周辺機器に対して最大128 PCI-Eレーンを提供します。
CPU自体は、4つのダイから構成されたマルチチップ モジュールです。各ダイは、最大8個のZenコア、2個のDDR4メモリー チャネル、32個のIOレーンを搭載しています。ダイのZenコアは、4コアずつ2つのグループに分けられています。このグループはコア コンプレックスと呼ばれ、L3キャッシュを共有しています。ソケット内では、4つすべてのダイが、Infinityファブリックと呼ばれる一貫性のある相互接続によってクロス接続されています。これを図1に示します。


図1 – EPYCソケット レイアウト。CCXは、L3キャッシュを共有する最大4コアのコア コンプレックスです。M*はメモリー チャネルであり、2つのチャネルは各ダイで処理されます。P*およびG*はIOレーン。∞はInfinityファブリック。



シングルソケット システムでは、各ダイはP*およびG*のIOレーンを使用して、最大32 PCI-Eレーンを提供します（図1を参照）。これにより、図2に示すように、ソケットの合計は128 PCI-Eレーンになります。CPUが2ソケット（2S）構成で使用されている場合は、各ダイのIOレーンの半分が、Infinityファブリックとして構成されたG* IOレーンを使用して他のソケットのいずれかのダイに接続するために使用されます。これにより、ソケットにはP* IOレーンが残り、合計64 PCI-Eレーンとなります。そのため、プラットフォームには128 PCI-Eレーンが残ります。これを図3に示します。


図2 - EPYC 1S PCI-Eレーン




図3 - EPYC 2Sのレイアウト




図3 - EPYC 2Sのレイアウト

 

---

STREAMベンチマークのパフォーマンス

EPYCを評価するための最初のステップとして、STREAMベンチマークを使用して、プラットフォームのメモリー帯域幅機能を測定しました。これらのテストは、デュアルAMD EPYC 7601プロセッサー（32C、2.2 Ghz）、16*16 GB DIMM（2400 MT/秒）を搭載し、Red Hat® Enterprise Linux® 7.5を実行しているDell EMC PowerEdge R7425サーバーで実施されています。

EPYCのnon-uniform memory access（NUMA）プレゼンテーションは、「メモリー インターリーブ」と呼ばれるBIOSオプションによって制御でき、numactlやlstopoなどのLinuxユーティリティーを使用してマップされます。

デフォルトのメモリー インターリーブ オプションは、「メモリー チャネル インターリーブ」です。このモードでは、各ダイの2つのチャネルがインターリーブされます。これにより、ソケットごとに4つのNUMAノードと、2Sシステム上のオペレーティング システムに8個のNUMAノードが提供されます。

「メモリー ダイ インターリーブ」は、ソケット上の4つすべてのダイのメモリー、つまり8つのメモリー チャネルがインターリーブされるオプションです。これにより、ソケットごとに1つのNUMAノードと、2Sシステムに2つのNUMAノードが提供されます。

「メモリー ソケット インターリーブ」は、2つのソケットにまたがってメモリーをインターリーブし、2Sプラットフォーム上に1つのNUMAノードを提供します。これはNUMAを無効にした場合に相当します。    

デフォルトの「メモリー チャネル インターリーブ」の構成を使用して（各ソケットに4つのダイがあることを思い出してください）、各ダイは2つのメモリー チャネルを提供し、BIOSは2Sプラットフォームに8つのNUMAノードを表示します。図4のnumactl出力の例は、2Sプラットフォームにこれらの8つのNUMAノード、各ダイに1つのNUMAノードを示しています。


図4 - 2S EPYCのnumactl出力


物理的には、図4でハイライト表示されているように、プラットフォーム上には次の4種類のNUMA距離があります。NUMAノード自体までの距離（赤色の「10」）、同じダイを共有している3つのノードまでの距離（青色の「16」）、Infinityファブリック リンクを介して直接接続されているもう一方のソケットのノードまでの距離（緑色の「22」）、2つのソケット間のInfinityファブリックと内部Infinityファブリック リンクを使用して2つのホップを介してアクセスされる、リモート ソケット上の他の3つのノードまでの距離（黒色の「28」）。

一部のBIOS実装およびバージョンでは、この物理レイアウトが簡素化され、オペレーティング システムには3つのNUMA距離のみが提供される場合があります。この簡素化により、NUMAノード0（例を参照）とNUMAノード4、5、6、7間の距離の差分をマスキングする必要が出てきます。これは、NUMAノード4、5、6、7をNUMAノード0から等距離として示すことによって実行できます。このような実装を図5に示します。NUMAレイアウトは、PowerEdge R7425 BIOSの次回のリリースで調節可能なオプションになる予定です。NUMAノードの距離を簡素化しても、コアの実際の物理レイアウトは変更されません。簡素化は主にOSスケジューラーにとって利点となります。NUMA対応のHPCおよびMPIジョブでは、これらの異なるプレゼンテーションは重要ではありません。


図5 - NUMA距離を簡素化した2S EPYCのnumactl出力


2ソケット プラットフォーム上の8つのNUMAノードに加えて、図4と図5は、各NUMAノードに関連付けられているメモリーとコアも示しています。各NUMAノードには、16GB DIMMを2枚で32GBのメモリーがあります（サーバーに16枚、ソケットあたり8枚、チャネルあたり1枚のDIMM）。各NUMAノードには、ローカル ダイの8コアが含まれています。Dell EMCプラットフォーム上のコア列挙はラウンド ロビンで、最初にすべてのNUMAノードを通過してから各NUMAノードに割り当てます。

さらに、lstopo出力を使用して、複雑なコアを構成している4コアのセットを明確に示すことができます。これらはL3キャッシュを共有するダイの4つのコアです。たとえば、図6は、NUMAノード0に8個のコアがあり、このNUMAノードではコア0、16、32、48がL3キャッシュを共有しており、コア8、24、40、56がL3キャッシュを共有していることを示しています。


図6 - 2S EPYCのlstopo出力


図7 - AMD EPYCプラットフォームのメモリー帯域幅

このNUMAレイアウトの情報を念頭に置いておくと、メモリー帯域幅のSTREAM Triadベンチマークの結果は、BIOSを「メモリー チャネル インターリーブ」に設定した状態で図7のように示されます。このテスト ベッドで使用される16 GB 2667 MT/秒デュアル ランク メモリー モジュールは、EPYCで2400 MT/秒で実行されることに注意してください。図7の最初の2本の棒は、すべてのコアが使用されている場合は2Sプラットフォームのメモリー帯域幅は244 GB/秒、コアの半分が使用されている場合は255.5 GB/秒であることを示しています。2番目のデータ ポイントは1つのソケットのメモリー帯域幅であり、想定どおり、2Sプラットフォーム全体の約半分になります。3番目のデータ ポイントは、NUMAノードの個々のダイのメモリー帯域幅を測定します。各ソケットに4つのダイがあり、1つのダイの帯域幅はソケットの約4分の1であることを思い出してください。ダイの中には2つのコア コンプレックスがあり、1つのコア コンプレックスでコアを使用すると、最大30GB/秒の帯域幅が提供されます。ダイの両方のコア コンプレックスでコアを使用する場合は、ダイのフル帯域幅を最大32GB/秒で提供できます。

2Sプラットフォームのメモリー帯域幅は240～260GB/秒と非常に優れています。これはプラットフォームにソケットあたり8個のメモリー チャネルが置かれているからです。さらに、単一のコアによって最大24.5 GB/秒のメモリー帯域幅をローカル メモリーに提供することができます。これは、アプリケーションのシングルスレッド部分としては並外れています。

NUMAレイアウトのリモート メモリー アクセスへの影響を確認します。図8は、コア アクセス メモリーが同じNUMAドメインにない場合に相対的なメモリー帯域幅を描画したグラフです。同一のソケットのメモリーへのアクセス速度は最大30%低下し、もう一方のソケットのメモリーへのアクセス速度は最大65%低下します。STREAM Triadを使用すると、1ホップ（ノード6、ソケット間に1つのInfinityファブリック）、または2ホップ（ノード4、5、7：ソケット間に1つのInfinityファブリック + 1つのローカルInfinityファブリック）でリモート ソケット上のメモリーにアクセスする場合に、メモリー帯域幅に測定不能な影響が及んでいるように見えます。メモリー帯域幅の機密性の高いアプリケーションでは、同一ソケット内においてもメモリー ローカリティ―が優れていることがパフォーマンスにとって重要となります。


図8 - リモート メモリー アクセスの影響
 

---

HPLベンチマークのパフォーマンス

次に、HPLベンチマークで測定されたEPYCの計算機能を測定しました。EPYCは、AVX命令と8 FLOP/サイクルのパフォーマンスをサポートします。Dellプラットフォームでは、オープンMPIとBLIS線形代数ライブラリーを使用してHPLを実行していました。

テスト システム（デュアルEPYC 7601プロセッサー）の理論上のパフォーマンスは64コア*8 FLOP/サイクル*2.2 GHzクロック周波数で、1126 GFLOPSを提供します。測定値は1133 GLOPSで、これは100.6%の効率性を実現します。

また、EPYC 7551（32c、2.0 GHz）、EPYC 7351（16c、2.4 GHz）、EPYC 7351P（1S、16c、2.4 GHz）上でHPLを実行しました。これらのテストでは、測定されたHPLパフォーマンスは理論上のパフォーマンスの102～106%に達していました。

効率性が100%を超えるのは、HPLテストの実行中にEPYCがベース周波数を上回るターボ周波数を維持することができるためです。
 

---

InfiniBandのレイテンシーと帯域幅

次に、2台のサーバー間でのInfiniBandレイテンシーおよび帯域幅のマイクロベンチマーク結果を確認しました。これらのテストに使用される構成については、表1を参照してください。レイテンシーと帯域幅の結果は、図9と図10のとおりです。


  表1 - InfiniBandテスト ベッド


図9 - InfiniBandレイテンシー（スイッチを使用）

実行コマンド：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

HCAに最も近いNUMAノードにMPIプロセスをピン留めするために注意を払うようにしました。この情報はlstopo出力で使用でき、ここではNUMAノード6になりました。レイテンシー テストは、OpenMPIとHPC-Xの両方で実行されました。レイテンシー測定値は、OpenMPIおよびMXMアクセラレーションを使用すると1.17µs、OpenMPIおよびUCXを使用すると1.10µsとなりました。ここでは、HPC-Xで取得したレイテンシーの結果が示されています。

図9では、C-Stateが有効になっているEPYCプロセッサーのレイテンシーは1.07µsで、すべてのメッセージ サイズのレイテンシーはC-Stateが有効になっている場合、無効になっている場合と比較して2～9%向上します。C-Stateが有効になっていると、アイドル コアはより深いC-stateとなり、アクティブ コア上でより高いターボ周波数を可能にします。この結果、レイテンシーが低下します。

帯域幅の結果は、図10に示されています。単方向帯域幅は12.4 GB/秒、双方向帯域幅は24.7 GB/秒という測定値が出ました。これらの結果は、EDRで予測されたとおりです


図10 - InfiniBand帯域幅

実行コマンド： 

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

 

表2 - osu_mbw_mrの結果 - 単一のNUMAノード
実行コマンド： 

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

図3および図6に示されているNUMAレイアウトでは、帯域幅におけるプロセス ローカリティ―の影響を確認するよう求められます。このテストでは、複数のプロセスのペア間での単一方向の帯域幅の集計を測定するosu_mbw_mrベンチマークを使用しました。このテストの目的は、NUMAノード上の8個すべてのコアを使用して、個々のNUMAノード間で実現される帯域幅とメッセージ レートを決定することです。このテストの結果は表2に示されています。テスト構成ではパフォーマンス プロファイル（C-Stateは無効でターボは有効）を使用しました。

結果として、InfiniBand HCA（NUMAノード6）に接続されているNUMAノード上でプロセスが実行されている場合、合計帯域幅は12.3 GB/秒になることが示されました。HCA（ソケット1）と同一ソケットにある他の3つのNUMAノードのいずれかでプロセスが実行されている場合、合計帯域幅はほぼ同等で、最大12.1 GB/秒となります。HCAに対してリモートであるソケットのNUMAノード上でプロセスが実行されると、合計帯域幅は最大6.8 GB/秒に低下します。

表3に示されている次の結果のセットは、個々のソケット間の単一方向の帯域幅を示しています。このテストでは、ソケットで使用可能な32コアがすべて使用されていました。HCAに対してローカルのソケット上でプロセスが実行されている場合は5.1 GB/秒、HCAに対してリモートのソケットで実行されている場合は2.4 GB/秒という測定値が出ました。テスト サーバーの64コアをすべて使用すると、サーバーあたり64プロセスを実行している場合の測定値は3.0 GB/秒となりました。

この最後の結果を再び確認するために、両方のソケットにまたがる8つのNUMAノードをすべて使用し、各NUMAノードでは2つのプロセスを実行してテストを実行し、サーバーあたり合計16のプロセスを提供します。このレイアウトでは、2.9 GB/秒という測定値も出ました。

これらの結果は、システムのトポロジーが通信パフォーマンスに影響を与えることを示しています。これは、複数のプロセスがサーバー間で通信するオールツーオールの通信パターンが重要な要素である場合に価値ある情報となります。他のアプリケーションでは、複数のNUMAドメインでのプロセスの実行時に測定された帯域幅の減少が、アプリケーションレベルのパフォーマンスに影響を与える要因にはならないことがあります。


  表3 - osu_mbw_brの結果 – ソケットおよびシステム レベル
実行コマンド： 

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

 
実行コマンド：

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

 
実行コマンド： 

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クラスターレベルのパフォーマンス

InfiniBandファブリックのパフォーマンスが検証されて、次のテストでは、クラスター全体でHPLを迅速に実行することになりました。これらのテストは、デュアル ソケットEPYC 7601を搭載した16ノード システムで実行されています。結果は図11に示すとおり、16のシステム全体で予想されるHPLの拡張性を示しています。


図11 - 16台のサーバーにまたがるHPL

 

---

WRFクラスターレベルのパフォーマンス

最後に、気象予報アプリケーションのWRFを実行しました。テスト ベッドは以前と変わらず、デュアル ソケットEPYC 7601を搭載した16ノード システムです。さらに、デュアル ソケットEPYC 7551を搭載した小さい4ノード システムでも一部のテストを行っています。すべてのサーバーは、2400 MT/秒で実行される16 GB*16 RDIMMを使用しており、Mellanox EDR InfiniBandと相互接続されています。


図12 - WRF conus 12 km、シングル ノード

WRF v3.8.1およびv3.9.1を使用して、conus 12 kmとconus 2.5 kmのデータ セットをテストしました。インテル コンパイラーを使用してWRFおよびnetcdfをコンパイルし、インテルMPIで実行しました。dmparと、OpenMPを使用したdm+sm構成オプションの両方を使用して、別のプロセスやタイリング スキームを試しました。

デルではAMDを使用して、WRFの他のコンパイラー チューニング オプションを決定しています。

WRF v3.8.1とv3.9.1の間で測定されたパフォーマンスの違いはありませんでした。dmparとdm+smを比較することで、プロセスとタイルの賢明な組み合わせによって、ほぼ同じパフォーマンスを得ていました。これを図12に示します。


図13 - WRF conus 12km、クラスター テスト


図14 - WRF conus 2.5km、クラスター テスト

クラスター レベルのテストは、実行ごとにすべてのコアと8タイルを使用して、WRV v 3.8.1およびdmpar構成を使用して実施されました。

Conus 12kmは小さなデータセットであり、EPYCにおいて8ノード、512コアを超えるとパフォーマンスは横ばいになります。これを図13に示します。EPYC 7551とEPYC 7601はどちらも32コア プロセッサーであり、7601のベース クロック周波数を提供し、全コア ターボ周波数は7551と比べるとそれぞれ10%、および6%高速化されています。WRF conus 12kmのテストでのEPYC 7601システムのパフォーマンスは、1、2、および4ノードのテストでは7551よりも3%速くなりました。

Conus 2.5kmは大規模なベンチマーク データセットであり、EPYC 1個のシステムと比較すると、8ノード（512コア）まではパフォーマンスが順調に向上し、その後下降し始めます。Conus 2.5kmを使用した場合も、EPYC 7601システムのパフォーマンスは、図14に示すように、1、2、および4ノードのテストではEPYC 7551よりも2～3%速くなります。

 

---

結論と次の手順

EPYCは、ソケットごとに適切なメモリー帯域幅とコア密度を提供します。HPCの観点からは、利用可能なメモリー帯域幅とCPUコアを使用して、EPYCアーキテクチャーの利点を最大限に活用できるようにするアプリケーションが期待されています。EPYCは現時点では、AVX512またはAVX2を単一サイクルでサポートしていないため、高度にベクトル化されてAVX2やAVX512を効率的に使用できるコードは、EPYCにとって理想的ではありません。

複数のNVMeドライブを使用できる使用事例では、EPYC上のPCI-Eレーンの数によっては、直接接続されたNVMeからメリットを得る場合もあります。

次の手順では、追加のHPCアプリケーションを使用して、さらなるパフォーマンス テストを実施します。