マルチコア／マルチソケットノードにおけるメモリ性能の

マルチコア／マルチソケットノードに
おけるメモリ性能のインパクト
研究代表者朴泰祐
筑波大学システム情報工学研究科
[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
Ｎ
2GB 667MHz DDR2 DIMM x4
2GB 667MHz DDR2 DIMM x4
Hyper
Transport
8GB/s
(Fullduplex)
Ｎ
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]); ← メモリアクセス１
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=１
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/ｓ
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の使い
方、パラメータ設定を（半）自動化するようなシステムを作りたい

Download Report