Transcript メッセージ衝突を防止する 適応的な収集操作アルゴリズム

メッセージ衝突を防止する
適応的な収集操作アルゴリズ
ム
吉富 翔太 弘中 健 田浦 健次朗
（東京大学）
背景
広域分散環境の充実と計算資源としての普及
InTrigger (Japan), Grid5000 (France)
WANのバンド幅が数10Gbpsを超える広帯域に
収集操作（gather)を効率よく行う必要性
ファイル転送
データ通信 など
多くの並列処理に関わるアプリケーション
のさまざまな場面でよく利用されている
高速化・効率化への要請の高まり
WA
N
集合通信の効率化における課題
ネットワーク・計算機のヘテロ性
大規模な環境へのスケーラビリティ
接続性（NAT, Firewallなどの存在）
広域・ヘテロな環境に適応可能な集合通信
バンド幅を最大限利用したbroadcastの最適化
gather で加えて非常に問題となるもの
コンテンションによる性能悪化
 ルータ・スイッチでの通信の衝突に
よるパケットロス
 データの再送に伴う通信性能低下
SW
N0 N1 N2 N3
Nk
gatherとコンテンションの関係
gather はコンテンションが生じやすい
原 ネットワークに過剰なデータが流入しようとする
因 受信ノードの受信容量を超えたデータが到達する
通信の性能に与える影響が無視できない
最大で数百倍の性能悪化（詳しくは後ほど）
SW
解決策は簡単ではない
N0 N1
大規模なネットワーク
一般のヘテロなネットワークへの適応性
N2 N3
Nk
簡単なgatherの手法ではどうか？
ツリー状に通信
順序を決めて通信
① ② ③ ④ ⑤
 長所： ノード数の増加に対し
て適応的
 短所： 通信の合流地点でコ
ンテンションがやはり起きる
可能性がある
 長所： コンテンションを抑制
できる
 短所：環境が大規模・高遅延
になると、順序制御（同期）
のコストが無視できなくなる
本研究の目的・貢献
目的
コンテンションを抑制
ヘテロ・大規模なネットワークに対して適応的
の２点を満たした高性能なgatherの手法を提案
貢献
今回は既存のMPIの実装との性能比較
最大で約３倍のスループットの向上
複数クラスタを利用した場合でも、ノード数の増加に
対して極端に性能悪化しないgatherを実現
発表の流れ
関連研究
既存の実装やアルゴリズム
問題提起
コンテンションの影響：実際のgatherと理論値の比較
提案手法
概略と問題設定
アルゴリズムとその一般化
実装と実験
まとめ
関連研究
（既存のMPIライブラリ）
OpenMPI
MPICH
MagPIe [Kielmann et al. 1999]
ルートノードを頂点とするツリー
構造を作る
各送信ノードは特に同期を取っ
たりはしない
コンテンションにより通信性能が
悪化しやすい
Flat tree
Contention!
Binomial tree
関連研究（組合せ最適問題としての
gather）
 ヘテロな環境での効率的な集合通信[Prashanth. et al. 1999]
バンド幅・遅延・メッセージサイズのパラメタを利用し
て、通信コストを算出
通信パターンの決定はネットワーク全体で総コスト
が最小となるような組合せ最適化問題に帰着
 大規模、かつヘテロなネットワークに対して適している。
 実ネットワーク上でどの経路で通信が行われるかは考
慮しない
複数のノードからの通信が衝突するこ
とによりコンテンションが生じやすい
コンテンションが通信性能に与える影響
一回当たりのgather の完了時間と、理論値との
比較
理論値 ＝
送信メッセージサイズ
受信ノードのバンド幅
× 送信ノード数
小規模な環境： 1スイッチ14ノードでのgather
①
②
ノード数
送信データサイズ
バンド幅
スイッチ性能
（バッファ容量等）
14
1KB ～ １MB
500Mbps
1Gbps
低
高
SW
受 送
…
14ノード
送
コンテンションの影響（スイッチ性能・バン
1回の実行時間（ミリ秒）
gather
time (msec)
Completion
ド幅小）
実行時間の 理論値 と 実測値 との間に200ms
以上の差（比率にして最大約100倍くらい）
2000
Theoretical
Concurrent
1500
実測値
1000
200msec
500
理論値
0
1
3KB 10
100
1000
10000
Message size (Kbyte)
Message
size (KB)
1ノードあたりの送信メッセージサイズ（KB）
コンテンションの影響（スイッチ性能・バン
ド幅大）
実行時間の 理論値 と 実測値 との間に200ms
の差が同様に生じている
o m ple tio n tim e (m se c )
gather C1回の実行時間（ミリ秒）
1200
1000
800
600
実測値
400
200
理論値
0
1
10
100
1000
M e ssage size (K byte )
1ノードあたりの送信メッセージサイズ（KB）
10000
コンテンションの影響（MPI実装との
比較）
MPI_gather 1回の実行時間（ミリ秒）
1クラスタ ： 2スイッチに56ノードが接続
1000
9ノード
…
800
OpenMPI
600
SW
MPICH
400
SW
200
理論値
0
10
100
1000
1ノードあたりの送信メッセージサイズ（KB）
…
47ノード
コンテンションの影響に関するまとめ
考察
スイッチでのパケットロスが生じる
一部パケットが再送タイムアウト（RTO）経たないと再送
されないことがある（タイムロス）
RTO = 200 ms ～ （Linux 2.6.18)
タイムロスはgather一回の実行時間と比べ非常に大
異なる環境でも生じている
どこでも発生しうる（特定の環境依存でない）
一般にgatherを考える上で対処すべき事項
全てのスイッチ・ルータにおいて、コンテンションによる
通信性能の悪化を起こさないようにすること
発表の流れ
関連研究
既存の実装やアルゴリズム
問題提起
コンテンションの影響：Naïveなgatherと理論値の比較
提案手法
概略と問題設定
アルゴリズムとその一般化
実験と性能評価
まとめ
アルゴリズムが満たすべき性質
目的
コンテンションを抑制したい
必要条件は何か？
任意の1ノードのリンク
に対して、メッセージが
同時に
複数のノードから
流入しようとはしない
OK
OK
NG
※スイッチのバックプレーン容量は十分大きいと仮定する
提案手法の概要
 当面の目標
 全スイッチ・ルータで「1ノードへ・同時に・複数の
ノードから」 メッセージが流入しない条件を満たす
 実現するための手法を２つ
1. 逐次に1ノードずつ通信
2. パイプライン状に通信
 様々なネットワークに適用するために
 ネットワークの構成に応じて両者を組み合わせるこ
とで、より高いスループットを実現
問題設定（１）
通信経路は事前に決定しておく
通信経路計算のコストは通信時間に比べて小さい
gatherの開始前にどのように通信するかは決定済
静的なツリーを元に通信
故障しない
通信路の故障
ノードの参加脱退
ネットワーク状態の時間変化
今回は考慮しない
脱退しない
問題設定（２）
１ノードは受信ノードが相異なる複数のgatherを
同時に行うことはない
他の通信の影響を受けない
必要なネットワークの情報は予め既知である
バンド幅
[長沼 et al. 2008]
遅延・トポロジー [白井 et al. 2007]
これらの情報の取得に要するコストは今回は考慮しない
全てのノードは他の任意のノードと通信ができ、
また送信と受信が同時に行えるものとする
アルゴリズム（１） －
逐次通信
1. B → A
2. A → C （確認メッセージ：数バイトのデータ）
3. C は確認メッセージを受け取り次第、 A に向
けて自身のメッセージを送出
A
SW
C 送信ノード
受信ノード
確認メッセージ
B 送信ノード
アルゴリズム（２） －
信
パイプライン通
1. B → A
同時並行で行われる
C→B
2. B は C からのデータを受け取り次第、 A へ
送信する
A
SW
C 送信ノード
受信ノード
B 送信ノード
逐次通信とパイプライン通信の定性的得
失
逐次通信
欠点 遅延が大きい場合
理由 同期に要するコストが
無視できなくなるため
パイプライン通信
バンド幅が小さい場合
途中のリンクが通信のボ
トルネックとなるため
遅延大
バンド幅小
高遅延なリンクでは
同期コストが非常に大きい
低バンド幅のリンクが
ボトルネックに
逐次通信とパイプライン通信の定量的得
失
 通信開始から完全に通信が終了するまでの時間
A
C
遅延 L
受信ノード 送信ノード
バンド幅 B
メッセージ長 M
B
パイプライン通信
T p  L AB 
M
B AB
送信ノード
 M
M
 max 
, L BC 
B BC
 B AB
逐次通信
T S  L AB 
M
B AB
 2 L AC 
M
B AC




遅延
バンド幅
メッセージ長
の関数となる
一般のネットワークへの適用方法
 Step1 ： 「初期パイプライン」の構築
 ルートノードを終端とする一本のパイプライン
 コンテンションが起きない条件を満たす
 そのようなパイプラインは必ず一つ以上存在する
 Step2 ： ツリーの組み換え（パイプラインの分割）
 そのままパイプライン通信を行うか
 ツリーを組み替え一部と逐次通信を行うか
をネットワーク情報を用いて判断し、
適宜ツリーを組み替える
初期パイプラインの構築
手順
トポロジーをルートノードから深さ優先探索し、辿っ
た順番の逆順をパイプライン転送の順序とする
ルートノードはパイプラインの終端になる
探索時の制約
コンテンションを起こさない条件を満たす
かつ
次に辿れるノードとして複数の選択肢が存在する
ルートと各ノード間のバンド幅が一番大きいものを選択
（理由） なるべくバンド幅が小さいリンクをパイプラインの
先端側に集め、ボトルネックにならないようにするため
初期パイプラインの構築
 ルートノードを終端とする一本のパイプラインを構築
SW
SW
重要なこと
全スイッチで
SW
SW
SW
SW
SW
root
同時に
複数ノードからの
データが1ノードへ
集中していない
ツリーのつなぎ替え後の様子
パイプラインが3本に
SW
SW
SW
同期
SW
同期
SW
2箇所で逐次通信に
切り替え
SW
SW
root
つなぎ替えた後でも、全スイッチについてコンテンションを
起こさない条件を常に満たしている
ツリーのつなぎ替え （簡単なモデル）
初期パイプライン
root
root
同期
パイプラインのroot側の
ノードからツリーのつな
ぎ替え（逐次通信）を行
うかどうかを決定する
同期
同期
ツリーのつなぎ替えを行う閾値
ノード間通信時間…見積もり可能
B
A
Tb’c
Tbb’
Tab
…
B’
C
Tac
C
B
A
パイプライン通信
…
B’
逐次通信
ノードCはAと逐次通信すべきか？
パイプライン通信のコスト Tab ＋
ー
確認メッセージ分の
コスト（AC間の遅延）
Tbb’ ＋ Tb’c
逐次通信のコスト Tab ＋ Tbb’ ＋ Tac ＋ Lac
この値の正負がツリーのつな
ぎ替えをするかどうかの閾値
Tb’c －（Tac ＋ Lac）
提案手法の要約
排他的に逐次通信
パイプラインで通信
両手法に一長一短がある
一本の初期パイプラインを構築
性能が向上する余地がある
（逐次通信への切り替えによる）通信ツリーの再構築
コンテンションを抑制し、なおかつ大規模・ヘテロな
ネットワークにも適応的な gather を実現
性能評価
 データ通信量と実行時間の関係の評価
 ノード数は固定 （単一クラスタ：56ノード）
 送信メッセージサイズ 10KB ～ 1MB
 通信参加ノード数と実行時間の関係の評価
 送信メッセージサイズは固定 （20KB）
 通信参加ノード数 （50ノード ～ 192ノード）
比較に利用した手法
コンテンションによる通
信性能劣化の可能性
OpenMPI / 全ノードが一斉に通信
全ノードがメッセージを一斉に送信
MPICH / 階層的なツリーに基づく通信
あり
階層的なツリー構造を作る手法
逐次通信（提案手法内での比較として）
提案手法のうち、「逐次通信」のみ利用
提案手法
パイプライン通信・逐次通信の組み合わせ
なし
実験環境（最大9クラスタ192ノード）
単一クラスタ
実験時に使用
単一クラスタでの性能評価
 コンテンションによる影響（OpenMPI, MPICH と 提案手法）
 同期コストの影響
（逐次通信 と 提案手法）
実行完了時間（ミリ秒）
300
OpenMPI
200
MPICH
提案手法
逐次通信
100
理論値
0
10
100
送信メッセージサイズ（KB）
1000
複数クラスタでの評価
 コンテンションによる影響 （一斉送信, 階層的なツリーに基
づく通信と提案手法）
 同期コストの影響
（逐次通信と提案手法）
C実行完了時間（ミリ秒）
o m p le tio n tim e (m se c )
400
C o n c u rre n t
S e qu e n tial
M agP ie
OURS
逐次通信
一斉に送信
階層的な通信
300
200
200
100
提案手法
0
50
100
150
N um ber of nodes
通信ノード数
200
どのようなツリーが構築されていたか
（参考）
（同期は全てルートノードと各パイプラインの先頭のノードとの間で行われた）
まとめ
多対一型集合通信のうちgather操作について
コンテンションを抑制
ヘテロ・大規模なネットワークに対して適応的
の２点を満たす手法を提案した。
性能評価の結果、
データ通信量によらずコンテンションの影響を受け
ない
通信参加ノード数の増加に対しても通信性能が極
端に悪くならない
ような、アルゴリズムを実現できた。
今後の課題
WANのバンド幅の活用
WANのバンド幅は広帯域になりつつある
提案手法では、WANを一部のノードしか一度に利用
しないため、バンド幅を有効活用できていない
さらにアルゴリズムを改善しなければならない
接続性が限られる場合
NATやFirewall
広域環境上のオーバレイ
限られた接続性の下でもメッセージ衝突を抑制
したアルゴリズムの構築が必要
ご静聴ありがとうございました