マルチコア / マルチソケットノードに おけるメモリ性能のインパクト 研究代表者朴泰祐筑波大学システム情報工学研究科 taisuke@cs.tsukuba.ac.jp
アウトライン 近年の高性能 PC クラスタの傾向と問題 multi-core/multi-socket ノードとメモリ性能 メモリバンド幅に着目した性能測定 multi-link network 性能評価 まとめ
近年の高性能 PC クラスタの傾向と問題点 ノード構成の傾向 CPU が 4~6 core 程度の multi-core 構成 ( 以下 MC 構成 ) となっている ノード当たり複数ソケット (multi-socket: 以下 MS 構成 ) となっている ネットワーク構成の傾向 Infiniband のような高性能ネットワークを大規模 多段 Fat-Tree で構成 複数リンクの平行結線によりネットワークバンド幅を増強 (multi-rail 以下 MR 構成 ) ノード及びネットワーク性能の増強 :MC-MS-MR 構成 実際の sustained performance を向上させるには様々な工夫が必要
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 36 36 8GB/s Bridge Bridge NVIDIA NVIDIA nforce nforce 35 35 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)
メモリマップとプロセスマップ プロセス ( コア ) と参照データを近接メモリにマッピング可能 (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 36 36 8GB/s Bridge Bridge NVIDIA NVIDIA nforce nforce 35 35 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)
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 1 2 3 4 5 6 7 8 9 1 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 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 31 32 33 34 35 36 x 2 network units
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 の有効利用方法を探る
マルチソケット環境における並列化 NUMA(Non-Uniform Memory Access) アーキテクチャ 高いメモリアクセス性能 NUMA アーキテクチャに合わせたチューニングが必要 NUMAコントロール (numactl) 並列化による性能向上 メモリバインド プロセスのマッピング 8 衝突が発生! レイテンシ大 ソケット ソケット 1 memory memory 2 core core 1 core core 2 3 core core core core 8 2 9 12 13 3 core 1 core 11 core 4 core 6 core 14 core 5 1 core 7 core 15 memory 1 ソケット 2 ソケット 3 memory 3
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 回 )
プロセスのマッピング : 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 1 1 1 1 4 5 1 4 5 2 3 2 3 6 7 2 3 6 7 socket 2 socket 3 socket 2 socket 3 socket 2 socket 3 socket 2 8 9 1 11 numactl cpunodebind (socket mapping: interleaved) socket socket 2 socket 3 1 socket 2 2 socket 3 3 socket 3 12 13 14 15 MPIプロセス 2 MPIプロセス 4 MPIプロセス 8 MPIプロセス 16 socket 1 socket socket 1 socket socket 1 1 1 4 1 5 socket 2 2 6 socket 3 3 7 socket 4 8 12 socket 2 2 6 1 14 socket 1 1 5 9 13 socket 3 3 7 11 15
プロセスとソケットのマッピングとメモリ性能 14 B/F 要求が低ければ問題なし 性能 [MFlops] 12 1 8 6 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 が多いと性能低下大 4 2 2 4 proc. 増強が性能に結びついていない 2 4 8 16 1 11 並列度 [ MPI プロセス数 ]
考察と今後の進展 numactlによるプロセスマッピングの重要性 socket mapping か core mapping かを慎重に検討する必要あり メモリバンド幅要求による影響が強い メモリ性能限界 Byte/FLOPに基づく性能予測は重要 プロセス数の増加が必ずしも性能に結びつかない場合がある プロセス数またはスレッド数の制御 アプリケーションのメモリバンド幅要求に応じ 性能向上に結びつく利用コア数限界を求める 余剰コア が発生した場合 これを有効利用する ( 例 : 通信スレッドへの割り当てによる全体性能の向上 )
MR 特性の予備評価 T2K-Tsukuba におけるノード間通信の MR の数 ( 何本の Infiniband を通信に用いるか ) T2K-Tsukuba における Fat-Tree ネットワークの評価 Intel MPI benchmark による性能評価 使用ノード数 :2~128 nodes
pingpong, pingping 性能 [ バンド幅 ] PingPong Mbytes/sec 45 4 35 3 25 2 15 1 5 1 1 1 1 1 1 1 1 35 3 Data size [byte] PingPing MR=2 MR=4 の効果は小さい ( データサイズがかなり大きくないと効果がない ) pingpong と pingping の性能は近い PCI-Express に十分なバンド幅があり 双方向通信でも高速 ( どちらかというと )multi-rail は複数の通信ストリームに分散させて使った方がよいのではないか? 25 Mbytes/sec 2 15 1 5 1 1 1 1 1 1 1 1 Data size [bytes]
Exchange( 隣接転送 ) 性能 [ 時間 ] Exchange(Data size : 1MB) Exchange(Data size : 4MB) 35 7 3 6 時間 (usec) 25 2 15 1 5 2 4 8 16 32 64 128 時間 (usec) 5 4 3 2 1 2 4 8 16 32 64 128 ノード数 ノード数 Exchange(Data size : 2MB) 時間 (usec) 35 3 25 2 15 1 5 1MB の時のデータがおかしい? データサイズが大きいと MR=4 の効果が高く出る Fat-tree であることで ノード数が増加しても通信性能に影響しない 2 4 8 16 32 64 128 ノード数
Allreduce 性能 [ 時間 ] Allreduce (Data size : 1MB) Allreduce (Max Data size : 4MB) 5 35 45 4 3 時間 (usec) 35 3 25 2 15 時間 [usec] 25 2 15 1 1 5 5 21 42 38 16 4 532 64 6 128 7 ノード数 2 4 8 16 32 64 128 2 4 8 16 32 64 128 ノード数 時間 usec) 12 1 8 6 4 2 Allreduce (Data size : 2MB) 2 2 4 8 16 16 32 32 64 64 128 128 データサイズが小さい場合は MR 数増加で通信性能改善 4MB 時に MR=4 で性能劣化 通信バッファ不足? ノード数増加に対し log オーダー程度の通信時間 Fat-Tree が有効に働いている ノード数
Alltoall 性能 [ 時間 ] Alltoall(Data size : 1MB) Alltoall(Data size : 4MB) 35 14 3 12 時間 (usec) 25 2 15 1 時間 (usec) 1 8 6 4 5 2 1 2 3 4 5 6 7 2 4 8 16 32 64 128 ノード数 2 4 8 16 32 64 128 ノード数 時間 (usec) 7 6 5 4 3 2 1 Alltoall(Data size : 2MB) どの場合でも MR 数増加が性能改善に貢献 最も多数のメッセージ通信が行われるが他の collective 通信より性能が安定している Fat-Tree が有効に働いている 1 2 3 4 5 6 7 2 4 8 16 32 64 128 ノード数
ノードを跨ぐ多数通信ペアの性能 [ バンド幅 ] 64KB (USE_FIRST) 4MB (USE_FIRST) (RR) (USE_FIRST) (RR) (USE_FIRST) 35 3 25 (RR) 5 45 4 35 (RR) MB/s 2 15 MB/s 3 25 2 1 5 5 1 15 2 通信ペア数 15 1 5 5 1 15 2 通信ペア数 2 ノード間の通信ペア数を変化させた sendrecv 通信 ( 双方向同時 ) 通信ペア数が増えれば MR 数を増やすよりも MR=1 で複数通信ストリームを同時並行実行した方が効率が良いはず MR=4 が常に良い T2K-Tsukuba で用いている MVAPICH2 の設定 パラメータ選択に問題があるのでは?
まとめ 現状の 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 の使い方 パラメータ設定を ( 半 ) 自動化するようなシステムを作りたい