Microsoft PowerPoint - CCS学際共同boku-08b.ppt

Size: px

Start display at page:

Download "Microsoft PowerPoint - CCS学際共同boku-08b.ppt"

もりよりこうじょう
7 years ago
Views:

1 マルチコア / マルチソケットノードにおけるメモリ性能のインパクト研究代表者朴泰祐筑波大学システム情報工学研究科 [email protected]

2 アウトライン近年の高性能 PC クラスタの傾向と問題 multi-core/multi-socket ノードとメモリ性能メモリバンド幅に着目した性能測定 multi-link network 性能評価まとめ

3 近年の高性能 PC クラスタの傾向と問題点ノード構成の傾向 CPU が 4~6 core 程度の multi-core 構成 ( 以下 MC 構成 ) となっているノード当たり複数ソケット (multi-socket: 以下 MS 構成 ) となっているネットワーク構成の傾向 Infiniband のような高性能ネットワークを大規模多段 Fat-Tree で構成複数リンクの平行結線によりネットワークバンド幅を増強 (multi-rail 以下 MR 構成 ) ノード及びネットワーク性能の増強 :MC-MS-MR 構成実際の sustained performance を向上させるには様々な工夫が必要

4 T2K-Tsukuba 計算ノードのブロックダイアグラム 2GB 667MHz DDR2 DIMM x4 Dual Channel Reg DDR2 2GB 667MHz DDR2 DIMM x4 Hyper Transport 8GB/s (Fullduplex) 2GB 667MHz DDR2 DIMM x4 2GB 667MHz DDR2 DIMM x4 4GB/s (Full-duplex) (A)1 (B)1 4GB/s (Full-duplex) PCI-Express X16 PCI-Express X8 PCI-X PCI-X Bridge Bridge 8GB/s X16 X8 X4 Bridge Bridge NVIDIA NVIDIA nforce nforce GB/s Bridge Bridge NVIDIA NVIDIA nforce nforce X16 X8 X4 SAS SAS PCI-Express X16 PCI-Express X8 4GB/s (Full-duplex) (A)2 (B)2 4GB/s (Full-duplex) Mellanox MHGH28-XTC ConnectX HCA x2 (1.2µs MPI Latency, 4X DDR 2Gb/s) I/O Hub USB PCI-X Mellanox MHGH28-XTC ConnectX HCA x2 (1.2µs MPI Latency, 4X DDR 2Gb/s)

5 メモリマップとプロセスマッププロセス ( コア ) と参照データを近接メモリにマッピング可能 (numactl 機能 ) 2GB 667MHz DDR2 DIMM x4 N Dual Channel Reg DDR2 2GB 667MHz DDR2 DIMM x4 Hyper Transport 8GB/s (Fullduplex) 2GB 667MHz DDR2 DIMM x4 N 2GB 667MHz DDR2 DIMM x4 4GB/s (Full-duplex) (A)1 (B)1 4GB/s (Full-duplex) PCI-Express X16 PCI-Express X8 PCI-X PCI-X Bridge Bridge 8GB/s X16 X8 X4 Bridge Bridge NVIDIA NVIDIA nforce nforce GB/s Bridge Bridge NVIDIA NVIDIA nforce nforce X16 X8 X4 SAS SAS PCI-Express X16 PCI-Express X8 4GB/s (Full-duplex) (A)2 (B)2 4GB/s (Full-duplex) Mellanox MHGH28-XTC ConnectX HCA x2 (1.2µs MPI Latency, 4X DDR 2Gb/s) I/O Hub USB PCI-X Mellanox MHGH28-XTC ConnectX HCA x2 (1.2µs MPI Latency, 4X DDR 2Gb/s)

11 12 1 2 3 4 5 6 7 8 9 1 11 12 スイッチ数 616 台 ( 全て 24port) IB cable 8554 本 1 2 3 4 5 6 7 8 9 1

6 T2K-Tsukuba のノード間ネットワーク構成 Full bi-sectional FAT-tree L3 SWs Network n n : #Node with 4 Links : #24ports IB Switch L2 SWs L1 SWs Nodes Detail View for one network unit スイッチ数 616 台 ( 全て 24port) IB cable 8554 本 x 2 network units

7 T2K-Tsukuba の計算ノード性能の問題点メモリバンド幅の不足 PACS-CS: 5.6GFLOPS, 6.4GB/s 1.14 Byte/FLOP T2K-Tsukuba: 147.2GFLOPS, 42.7GB/s.29Byte/FLOP PACS-CS に比べ約 1/4 の Byte/FLOP 性能しかない MC/MS 構成によりメモリ階層が非常に複雑 B8 シリーズ AMD quad-core Opteron (Barcelona) 4 つの core が各 512KB の private L2 cache を持ちさらに 2MB の shared L3 cache を持つ 4 つの CPU socket は共有メモリ結合だが構成は NUMA (Non-Uniform Memory Architecture) MC 化はさらに進むがメモリ性能が追いつかない! DDR2->DDR3, FSB のさらなる向上でメモリも良くなっているが core 数はそれを上回る勢いで増える HPC 的にどうか? 以上の背景の下 MC/MS 構成ノードにおける演算性能とメモリ性能の特性を調べ MC/MS 環境の core の有効利用方法を探る

8 マルチソケット環境における並列化 NUMA(Non-Uniform Memory Access) アーキテクチャ高いメモリアクセス性能 NUMA アーキテクチャに合わせたチューニングが必要 NUMAコントロール (numactl) 並列化による性能向上メモリバインドプロセスのマッピング 8 衝突が発生! レイテンシ大ソケットソケット 1 memory memory 2 core core 1 core core 2 3 core core core core core 1 core 11 core 4 core 6 core 14 core 5 1 core 7 core 15 memory 1 ソケット 2 ソケット 3 memory 3

9 T2K-Tsukuba における MC/MS ノード性能 Byte/FLOP という尺度に着目し synthetic benchmark により MC/MS におけるプロセスマッピングとメモリ性能の関係を詳細評価 double a[n/p], b[n/p], x1, x2, y; /* N is large enough */ for(i=; i<n/p; i++){ x1 = _mm_load_pd(&a[i]); x2 = _mm_load_pd(&b[i]); y1 = x1; y2 = x2; y1 = _mm_mul_pd(y1,y2); y1 = _mm_mul_pd(y1,y2); _mm_store_pd(&c[i], y1); } メモリアクセス 1 浮動小数点演算回数を調節 (1, 2, 4, 8, 12, 16, 24 回 )

10 プロセスのマッピング : Linux numactl numactl physcpubind (core mapping: blocked) MPIプロセス 2 MPIプロセス 4 MPIプロセス 8 MPIプロセス 16 socket socket 1 socket socket 1 socket socket 1 socket socket socket 2 socket 3 socket 2 socket 3 socket 2 socket 3 socket numactl cpunodebind (socket mapping: interleaved) socket socket 2 socket 3 1 socket 2 2 socket 3 3 socket MPIプロセス 2 MPIプロセス 4 MPIプロセス 8 MPIプロセス 16 socket 1 socket socket 1 socket socket socket socket socket socket socket socket

11 プロセスとソケットのマッピングとメモリ性能 14 B/F 要求が低ければ問題なし性能 [MFlops] socket (interleaved) mapping core (blocked) mapping 1.5 Byte/flop 3 Byte/flop 6 Byte/flop 12 Byte/flop 24 Byte/flop 1.5 Byte/flop 3 Byte/flop 6 Byte/flop 12 Byte/flop 24 Byte/flop B/F 要求が高いと core/socket が多いと性能低下大 proc. 増強が性能に結びついていない並列度 [ MPI プロセス数 ]

12 考察と今後の進展 numactlによるプロセスマッピングの重要性 socket mapping か core mapping かを慎重に検討する必要ありメモリバンド幅要求による影響が強いメモリ性能限界 Byte/FLOPに基づく性能予測は重要プロセス数の増加が必ずしも性能に結びつかない場合があるプロセス数またはスレッド数の制御アプリケーションのメモリバンド幅要求に応じ性能向上に結びつく利用コア数限界を求める余剰コアが発生した場合これを有効利用する ( 例 : 通信スレッドへの割り当てによる全体性能の向上 )

13 MR 特性の予備評価 T2K-Tsukuba におけるノード間通信の MR の数 ( 何本の Infiniband を通信に用いるか ) T2K-Tsukuba における Fat-Tree ネットワークの評価 Intel MPI benchmark による性能評価使用ノード数 :2~128 nodes

14 pingpong, pingping 性能 [ バンド幅 ] PingPong Mbytes/sec Data size [byte] PingPing MR=2 MR=4 の効果は小さい ( データサイズがかなり大きくないと効果がない ) pingpong と pingping の性能は近い PCI-Express に十分なバンド幅があり双方向通信でも高速 ( どちらかというと )multi-rail は複数の通信ストリームに分散させて使った方がよいのではないか? 25 Mbytes/sec Data size [bytes]

15 Exchange( 隣接転送 ) 性能 [ 時間 ] Exchange(Data size : 1MB) Exchange(Data size : 4MB) 時間 (usec) 時間 (usec) ノード数ノード数 Exchange(Data size : 2MB) 時間 (usec) MB の時のデータがおかしい? データサイズが大きいと MR=4 の効果が高く出る Fat-tree であることでノード数が増加しても通信性能に影響しないノード数

16 Allreduce 性能 [ 時間 ] Allreduce (Data size : 1MB) Allreduce (Max Data size : 4MB) 時間 (usec) 時間 [usec] ノード数ノード数時間 usec) Allreduce (Data size : 2MB) データサイズが小さい場合は MR 数増加で通信性能改善 4MB 時に MR=4 で性能劣化通信バッファ不足? ノード数増加に対し log オーダー程度の通信時間 Fat-Tree が有効に働いているノード数

17 Alltoall 性能 [ 時間 ] Alltoall(Data size : 1MB) Alltoall(Data size : 4MB) 時間 (usec) 時間 (usec) ノード数ノード数時間 (usec) Alltoall(Data size : 2MB) どの場合でも MR 数増加が性能改善に貢献最も多数のメッセージ通信が行われるが他の collective 通信より性能が安定している Fat-Tree が有効に働いているノード数

18 ノードを跨ぐ多数通信ペアの性能 [ バンド幅 ] 64KB (USE_FIRST) 4MB (USE_FIRST) (RR) (USE_FIRST) (RR) (USE_FIRST) (RR) (RR) MB/s 2 15 MB/s 通信ペア数通信ペア数 2 ノード間の通信ペア数を変化させた sendrecv 通信 ( 双方向同時 ) 通信ペア数が増えれば MR 数を増やすよりも MR=1 で複数通信ストリームを同時並行実行した方が効率が良いはず MR=4 が常に良い T2K-Tsukuba で用いている MVAPICH2 の設定パラメータ選択に問題があるのでは?

19 まとめ現状の T2K-Tsukuba において point-to-point, collective のどちらの通信でも Infiniband の MR (binding) は概ね効果がある一部の負性特性領域ケースがあるが MR=2 or MR=4 としておいた方が全体の通信性能が向上する point-to-point と collective では MR の効き方に違いがあるためアプリケーションで重要な通信の種類とデータサイズに応じ最適な MR 数を見つける必要があるのでは? 現状の問題点と今後の課題ノード上に複数 MPI プロセスがあり同時に多数の通信を行う場合 MR=1 で複数ストリームを同時に処理できていない? いつでも MR=2 or MR=4 とした方がとりあえず性能が高い今後 MVAPICH2 の実装とパラメータ設定を詳細に調査 MC/MS/MR という複雑な構造における性能最適化のため core と rail の使い方パラメータ設定を ( 半 ) 自動化するようなシステムを作りたい

Microsoft PowerPoint - stream.ppt [互換モード]

Microsoft PowerPoint - stream.ppt [互換モード] STREAM 1 Quad Opteron: ccnuma Arch. AMD Quad Opteron 2.3GHz Quad のソケット 4 1 ノード (16コア ) 各ソケットがローカルにメモリを持っている NUMA:Non-Uniform Access ローカルのメモリをアクセスして計算するようなプログラミング, データ配置, 実行時制御 (numactl) が必要 cc: cache-coherent