Comments
Description
Transcript
マルチコア/マルチソケットノードに おけるメモリ性能の
マルチコア/マルチソケットノードに おけるメモリ性能のインパクト 研究代表者 朴 泰祐 筑波大学 システム情報工学研究科 [email protected] アウトライン 近年の高性能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計算ノードのブロックダイアグラム Dual Channel Reg DDR2 2GB 667MHz DDR2 DIMM x4 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 X16 PCI-Express X8 X8 PCI-X PCI-X Bridge Bridge X4 4GB/s (Full-duplex) 8GB/s 8GB/s PCI-Express X16 X16 Bridge Bridge Bridge Bridge NVIDIA NVIDIA nForce nForce 3600 3600 NVIDIA NVIDIA nForce nForce 3050 3050 PCI-Express X8 X8 X4 SAS SAS (A)2 (B)2 4GB/s (Full-duplex) USB USB I/O I/O Hub Hub Mellanox MHGH28-XTC ConnectX HCA x2 (1.2µs MPI Latency, 4X DDR 20Gb/s) PCI-X PCI-X Mellanox MHGH28-XTC ConnectX HCA x2 (1.2µs MPI Latency, 4X DDR 20Gb/s) メモリマップとプロセスマップ プロセス(コア)と参照データを近接メモリにマッピング可能(numactl 機能) Dual Channel Reg DDR2 N 2GB 667MHz DDR2 DIMM x4 2GB 667MHz DDR2 DIMM x4 Hyper Transport 8GB/s (Fullduplex) N 2GB 667MHz DDR2 DIMM x4 4GB/s (Full-duplex) (A)1 (B)1 4GB/s (Full-duplex) X16 PCI-Express X8 X8 PCI-X PCI-X Bridge Bridge X4 4GB/s (Full-duplex) 8GB/s 8GB/s PCI-Express X16 2GB 667MHz DDR2 DIMM x4 PCI-Express X16 X16 Bridge Bridge Bridge Bridge NVIDIA NVIDIA nForce nForce 3600 3600 NVIDIA NVIDIA nForce nForce 3050 3050 PCI-Express X8 X8 X4 SAS SAS (A)2 (B)2 4GB/s (Full-duplex) USB USB I/O I/O Hub Hub Mellanox MHGH28-XTC ConnectX HCA x2 (1.2µs MPI Latency, 4X DDR 20Gb/s) PCI-X PCI-X Mellanox MHGH28-XTC ConnectX HCA x2 (1.2µs MPI Latency, 4X DDR 20Gb/s) T2K-Tsukubaのノード間ネットワーク構成 Full bi-sectional FAT-tree Network n L3 SWs n : #Node with 4 Links : #24ports IB Switch L2 SWs L1 SWs Nodes Detail View for one network unit 1 2 1 1 2 3 2 3 4 5 3 6 7 8 4 4 9 10 11 12 5 5 6 6 7 7 8 8 13 14 15 16 17 18 19 20 21 22 23 24 9 9 10 10 11 11 12 12 スイッチ数 616台 (全て24port) IB cable 8554本 25 26 27 28 29 30 31 32 33 34 35 36 x 20 network units T2K-Tsukubaの計算ノード性能の問題点 メモリバンド幅の不足 PACS-CS: 5.6GFLOPS, 6.4GB/s ⇒ 1.14 Byte/FLOP T2K-Tsukuba: 147.2GFLOPS, 42.7GB/s⇒ 0.29Byte/FLOP ⇒PACS-CSに比べ約1/4のByte/FLOP性能しかない MC/MS構成により、メモリ階層が非常に複雑 B8000シリーズAMD quad-core Opteron (Barcelona) MC化はさらに進むが、メモリ性能が追いつかない! 4つのcoreが各512KBの private L2 cache を持ち、さらに2MBの shared L3 cacheを持つ 4つのCPU socketは共有メモリ結合だが構成はNUMA (Non-Uniform Memory Architecture) DDR2->DDR3, FSBのさらなる向上でメモリも良くなっているがcore数はそれを上回る 勢いで増える ⇒HPC的にどうか? 以上の背景の下、MC/MS構成ノードにおける演算性能とメモリ性能の特性を調べ、 MC/MS環境のcoreの有効利用方法を探る マルチソケット環境における並列化 NUMA(Non-Uniform Memory Access)アーキテクチャ 高いメモリアクセス性能 NUMAアーキテクチャに合わせたチューニングが必要 並列化による性能向上 メモリバインド プロセスのマッピング memory 0 (numactl) ソケット0 ソケット1 衝突が発生!レイテンシ大 core core 4 51 core core 22 33 core core 6 7 ソケット2 memory 2 8 core core 00 110 memory 1 ⇒NUMAコントロール ソケット3 core core 82 9 core core 3 12 13 core core 10 11 core core 14 15 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=0; i<N/p; i++){ x1 = _mm_load_pd(&a[i]); ← メモリアクセス1 x2 = _mm_load_pd(&b[i]); y1 = x1; y2 = x2; y1 = _mm_mul_pd(y1,y2); y1 = _mm_mul_pd(y1,y2); 浮動小数点演算回数を調節 …… (1, 2, 4, 8, 12, 16, 24回) _mm_store_pd(&c[i], y1); } プロセスのマッピング: Linux numactl numactl –physcpubind (core mapping: blocked) MPIプロセス 2 0 socket socket 1 socket 2 socket 3 0 1 MPIプロセス 4 socket 0 socket 1 socket 2 socket 3 0 2 1 3 MPIプロセス 8 socket 0 0 2 1 3 socket 2 socket 1 4 6 5 7 socket 3 MPIプロセス 16 socket 0 0 2 1 3 socket 2 8 9 10 11 socket 1 4 6 5 7 socket 3 12 13 14 15 numactl –cpunodebind (socket mapping: interleaved) MPIプロセス 2 socket 0 0 socket 2 10 socket 1 1 socket 3 MPIプロセス 4 socket 0 socket 1 MPIプロセス 8 socket 0 4 socket 1 0 1 0 socket 2 socket 3 socket 2 socket 3 2 3 2 3 6 1 5 7 MPIプロセス 16 socket 0 0 8 4 12 socket 2 2 6 10 14 socket 1 1 9 5 13 socket 3 3 7 11 15 プロセスとソケットのマッピングとメモリ性能 B/F要求が低ければ 問題なし 14000 socket (interleaved) mapping 12000 core (blocked) mapping 性能 [MFlops] 10000 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が多いと 性能低下大 8000 6000 4000 2000 2→4 proc. 増強が性能に 結びついていない 0 1 2 4 8 並列度 [ MPIプロセス数] 11 16 考察と今後の進展 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 4500 4000 3500 Mbytes/sec 3000 2500 bind=4 bind=2 2000 bind=1 1500 1000 500 0 1 10 100 1000 10000 100000 1000000 10000000 Data size [byte] PingPing 3500 3000 Mbytes/sec 2500 2000 bind=4 bind=2 1500 bind=1 1000 500 0 1 10 100 1000 10000 Data size [bytes] 100000 1000000 10000000 • MR=2 ⇒ MR=4の効果は小さい (データサイズがかなり大きくないと 効果がない) • pingpongとpingpingの性能は近 い ⇒PCI-Expressに十分なバンド幅が あり、双方向通信でも高速 • (どちらかというと)multi-railは複 数の通信ストリームに分散させて 使った方がよいのではないか? Exchange(隣接転送)性能 [時間] Exchange(Data size : 4MB) 3500 7000 3000 6000 5000 2500 2000 bind=1 1500 bind=2 1000 bind=4 500 時間 (usec) 時間 (usec) Exchange(Data size : 1MB) 4000 bind=1 3000 bind=2 2000 bind=4 1000 0 2 4 8 16 32 64 0 128 2 ノード数 4 8 16 32 64 128 ノード数 Exchange(Data size : 2MB) 3500 時間 (usec) 3000 2500 2000 bind=1 1500 bind=2 1000 bind=4 500 0 2 4 8 16 ノード数 32 64 128 • 1MBの時のデータがおかしい? • データサイズが大きいとMR=4の効果 が高く出る • Fat-treeであることで、ノード数が増加 しても通信性能に影響しない Allreduce性能 [時間] Allreduce (Max Data size : 4MB) Allreduce (Data size : 1MB) 35000 5000 4500 30000 4000 bind=1 bind=2 bind=4 3000 2500 2000 25000 時間 [usec] 時間 (usec) 3500 20000 bind=1 15000 bind=2 bind=4 10000 1500 1000 5000 500 0 0 21 42 38 4 16 532 6 64 2 2 7 128 44 8 8 16 16 32 32 64 64 128 128 ノード数 ノード数 Allreduce (Data size : 2MB) 12000 時間 usec) 10000 8000 bind=1 bind=2 bind=4 6000 4000 2000 0 22 44 88 16 16 ノード数 3232 6464 128128 • データサイズが小さい場合はMR数増 加で通信性能改善 4MB時にMR=4で性能劣化 ⇒通信バッファ不足? • ノード数増加に対し、logオーダー程 度の通信時間 ⇒Fat-Treeが有効に働いている Alltoall性能 [時間] Alltoall(Data size : 1MB) Alltoall(Data size : 4MB) 350000 1400000 300000 時間(usec) 250000 bind=1 bind=2 bind=4 200000 150000 100000 1000000 bind=1 bind=2 bind=4 800000 600000 400000 200000 50000 0 0 1 2 2 4 3 8 4 16 5 32 6 64 22 7 128 Alltoall(Data size : 2MB) 700000 600000 500000 bind=1 bind=2 bind=4 400000 300000 200000 100000 0 1 2 2 4 3 8 4 16 ノード数 44 8 8 16 16 32 32 64 64 128 128 ノード数 ノード数 時間 (usec) 時間 (usec) 1200000 5 32 6 64 7 128 • どの場合でもMR数増加が性能改善 に貢献 • 最も多数のメッセージ通信が行われ るが他のcollective通信より性能が安定 している ⇒Fat-Treeが有効に働いている ノードを跨ぐ多数通信ペアの性能 [バンド幅] 64KB 4MB bind=1 bind=2 (USE_FIRST) bind=1 bind=2 (USE_FIRST) bind=2 (RR) bind=4 (USE_FIRST) bind=2 (RR) bind=4 (USE_FIRST) bind=4 (RR) 3500 4500 3000 4000 3500 MB/s 2500 MB/s bind=4 (RR) 5000 2000 3000 2500 1500 2000 1000 1500 1000 500 500 0 0 0 5 10 通 信 ペア 数 15 20 0 5 10 数 通信ペア 15 • 2ノード間の通信ペア数を変化させたsendrecv通信(双方向同時) • 通信ペア数が増えれば、MR数を増やすよりもMR=1で複数通信ストリームを同 時並行実行した方が効率が良いはず ⇒ MR=4が常に良い • T2K-Tsukubaで用いているMVAPICH2の設定、パラメータ選択に問題があるの では? 20 まとめ 現状の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の使い 方、パラメータ設定を(半)自動化するようなシステムを作りたい