Transcript pptx

広域計算環境における並列計算用の
スケーラブルな高性能通信ライブラリの
設計と実装
博士論文本審査
48-67404 斎藤秀雄
2009年1月28日
クラスタの躍進
• 過去10年でクラスタは並列計算に最も用いられ
るアーキテクチャになった
– 1998年11月のTOP500のクラスタの割合 < 1%
– 2008年11月のTOP500のクラスタの割合 > 80%
1. はじめに
2
広域計算環境の整備
• 複数のクラスタをWANで接続することによって
さらに多くの資源を用いて計算が行える
• WANのバンド幅のの増加（〜40Gbps）
– SINET3（日本）、SURFnet（オランダ）、etc.
広域環境の恩恵を受けられるアプリが増加
– メッセージパッシング（MPI）
– データインテンシブアプリ（Hadoop）
– 分散ファイルシステム（Gfarm）
WAN
1. はじめに
3
広域環境における並列計算の難しさ
• 広域計算環境は従来の単一クラスタ環境よりは
るかに複雑
–
–
–
–
接続性が限られている
高いスケーラビリティが求められる
局所性を考慮する必要がある
未知の環境に適応する必要がある
• アプリがこれらに個別に対応するのは困難
代わりに対応してくれる広域環境用の通信ライ
ブラリが必要とされている
1. はじめに
4
接続性
• 広域環境では直接通信できないノードがある
– FWによって通信が遮断されているノード
– NATをしていてPrivate IPしか持っていないノード
FW
1. はじめに
5
スケーラビリティ
• 「つなげるならつなぐ」手法の問題点
– 様々な資源の制限
• TCPのバッファメモリ（帯域遅延積）
• NATの同時セッション数（〜65,000）
• FWの同時セッション数（10,000〜1,000,000）
– 通信性能の低下
• コンジェスチョンによるパケットロス
• セキュリティのために落とされる
パケット
• 接続（特にWANの接続）の数を
制御する必要がある
1. はじめに
6
局所性
• 接続性・スケーラビリティの要件より、一部の
プロセス対でのみ直接通信をすることになる
• 高い通信性能を保つために、それらの
プロセス対を局所性を考慮して選択する
必要がある
– 遠いプロセス対より近いプロセス対を
優先的に選択すべき
– あまり通信しないプロセス対より
たくさん通信するプロセス対を
優先的に選択すべき
1. はじめに
疎
密
7
適応性
• 環境やアプリに適応することによって、前述の
要件を自動的に満たすべきである
• 手動の設定に頼るべきではない
– 煩雑
– スケーラビリティが低い
– 様々なトラブルの原因
• 設定ミスのせいで性能が落ちたり、接続性が失われたりする
ことがある
• 「未知の環境」への適応はクラウドコンピュー
ティングではさらに重要になると予想される
1. はじめに
8
本研究の貢献
• 広域計算環境で煩雑な設定をすることなく大規
模な並列計算を効率良くできるようにすること
• 提案手法
– 環境の遅延とアプリの通信量を基にスケーラブルか
つ高性能なオーバレイを構築 (接続管理)
– 通信コストが低くなるようにオーバレイネットワー
ク上にプロセスを配置 (ランク割当て)
• 実装
– 広域計算環境用のMPIライブラリ (MC-MPI)
– Socket APIを提供してMC-MPIをより汎用的にしたライ
ブラリ (SSOCK)
1. はじめに
9
発表の流れ
1.
2.
3.
4.
5.
6.
はじめに
関連研究
MC-MPIの設計と実装
MC-MPIの評価
SSOCK
おわりに
10
FW/NAT越えの手法
• Virtual Private Network (VPN)
– IP-VPN、ユーザレベルVPN
•
•
•
•
•
SOCKS (RFC 1928)
Application Level Gateway (ALG) (RFC 2663)
TCP splicing (Denis et al. ‘04)
UDP hole punching (RFC 3489)
問題点
– 大規模な広域環境で全ノードが互いに通信できるよ
うにするためには多くの設定が必要
– 多数の接続を確立することに起因するスケーラビリ
ティの問題は解決しない
2. 関連研究
11
SmartSockets
• Maassen et al. ‘07
• JavaのSocketクラスをFW/NAT越えできるように
拡張
– アプリにはあたかもFW等がなくて直接コネクトでき
るかのように見える
– ライブラリ内では直接コネクトできない場合は逆向
きコネクトや中継を行う
• cf. SSOCKは同様のインタフェースで、大規模な
並列計算に必要なスケーラビリティと性能を提
供することを目指す
2. 関連研究
12
P2Pオーバレイネットワーク
• 各ノードは一部のノードとのみ通信
– 直接通信できない（しない）ノードのために中継
• 分散ハッシュテーブルを用いたルーティング
– nノードがそれぞれO(log n)ノードについて情報を保持
すれば、平均O(log n)ホップで通信できる
• 問題点:
– ルーティングをP2Pアドレス空間で行うため、物理
ネットワークではメッセージが遠回りしてしまう
2. 関連研究
13
IP over P2P (IPOP)
• Ganguly et al. ‘06
• P2Pオーバレイネットワークを用いてIPトンネリ
ングを行う（IPの仮想化）
• 頻繁に通信するノードの間にはショートカット
接続を確立する
• 問題点:
– 多数のノードが頻繁に通信するアプリでは多数の
ショートカット接続が確立されてしまう
– IPトンネリングを行うために用いる仮想インタフェー
スのオーバヘッドが並列アプリには大きすぎる
2. 関連研究
14
MPIライブラリの接続管理
• MPICH (Gropp et al. ‘96)、MPICH2
– 任意のプロセス対が接続できると仮定
– オンデマンドに接続を確立（遅延接続確立）
– 問題点:
• 通信するプロセス対が多いアプリ（e.g., IS, DiVinE）では多数
の接続が確立されてしまう
• GridMPI (Takano et al. ’08)
– NAT間の通信のために中継プロセスを手動で設定
– 中継プロセスのトランキングによってクラスタ間の
バンド幅利用率を向上
– 問題点:
• クラスタ間で高い性能が得られる設定を手動で行うのは困難
2. 関連研究
15
よく用いられるランク割当て手法
• プロセスをホスト名（IPアドレス）順に並べ、
その順にランクを割り当てる
• 仮定
– 多くの通信はランクの近いプロセス間で行われる
– ホスト名が近いプロセスの通信コストは低い
• しかし、実際には
– アプリの通信パターンには様々なものがある
– ホスト名と通信コストに深い関係があるとは限らな
い
2. 関連研究
16
BTの通信行列とランク割当て
• 通信行列
送信先
• ランク割当て
ホスト名に基づく割当て
ランク
より良い割当て
ランク
送
信
元
2. 関連研究
クラスタ1
クラスタ2
クラスタ3
クラスタ3
17
トポロジを考慮したランク割当て手法
• ランク割当て問題をグラフ分割問題として扱う
• Hatazaki et al. ‘98、Traff ’02
– 通信コストと通信量を手動で与える必要がある
• Bhanot et al. ‘05
– トポロジがトーラスの場合に限定されている
2. 関連研究
18
他の分野の似た研究
• 無線ネットワークのアダプティブルーティング
– Goff et al. (MobiComm ‘01)、Chin et al. (CCR ‘02)、Woo
et al. (SenSys ‘03)、etc.
• 似ている点
– 接続が限られていること
– リンク性能を測定して環境に適応すること
• 異なる点
– 無線ネットワークでは遠いノードと接続できない
「遠いノードとつなぎすぎ」という問題はそもそも
ない
2. 関連研究
19
発表の流れ
1.
2.
3.
4.
5.
6.
はじめに
関連研究
MC-MPIの設計と実装
MC-MPIの評価
SSOCK
おわりに
20
Multi-Cluster MPI (MC-MPI)
• IEEE CCGrid 2007
• 局所性を考慮した接続管理
– オーバレイネットワークを構築
FW/NAT越え
– 各プロセスがO(log n)接続を選択し、
それらをオンデマンドに確立
高いスケーラビリティ
– O(log n)接続を環境の遅延と
アプリの通信量を基に選択
高い通信性能
• 局所性を考慮したランク割当て
– 遅延と通信量を基に割当てを決定
低い通信オーバヘッド
3. MC-MPIの設計と実装
21
プロファイリング実行と本実行
短いプロファイリング実行
• 遅延行列 (D)
• 通信行列 (T)
最適化された本実行
• 局所性を考慮した接続管理
• 局所性を考慮したランク割当て
3. MC-MPIの設計と実装
22
遅延行列
• D = {dij}
– dij: プロセスiとプロセスjの間の遅延
– 各プロセスは自律的に自分と他のプロセスの間のRTT
を測定する
– 測定回数を削減するために三角不等式に基づいて遠
いプロセスとのRTTを見積もる
rttpr
r
rttrq
p
rttpq
q
if rttpr > α rttrq:
rttpq ≈ rttpr
(α: 定数)
3. MC-MPIの設計と実装
23
通信行列
• T = {tij}
– tij: ランクiとランクjの間の通信量
– 多くのアプリは実行を通して似た通信を繰り返す
– 短い”お試し実行”で送信されるバイト数を数える
• 反復法を用いるアプリ（e.g., NPB）ではメインループを1イテ
レーションだけ実行
• それ以外のアプリ（e.g., DiVinE）は5秒間だけ実行
3. MC-MPIの設計と実装
24
提案する接続管理の概要
スパニングツリー
バウンディンググラ
フ
(サイドチャネル)
(確立する接続の上限)
[MPI_Init]
3. MC-MPIの設計と実装
遅延接続確立
[アプリ本体]
25
バウンディンググラフの構築
• 各プロセスはDとTを基にO(log n)個の他のプロセ
スを選択する
– β: 接続密度を制御するパラメータ
– n: プロセス数
– 2j-1βプロセスのグループから
βプロセスずつ選択する
(j = 1, 2, …, log2(n/β))
qkを選択する確率∝tpqk
近い
p
q1
/
q2
q3
/2
q4
q5
q6
/4
3. MC-MPIの設計と実装
q7
疎
遠い
...
密
26
遅延接続確立
DST
FW
FW
FW
接続
要求
逆向き
コネクト
SRC
スパニングツリー
3. MC-MPIの設計と実装
27
提案するランク割当て
• 通信オーバヘッドを最小化するためにランク割
当て問題を二次割当て問題として扱う
• 二次割当て問題（QAP）
– 二つのnxnコスト行列が与えられたときに、
を最小化する{0, 1, …, n-1}の並べ替えpを求めよ
3. MC-MPIの設計と実装
28
QAPの解法
• QAPはNP困難であるが、ヒューリスティクスで
短時間で良い近似解を求めることができる
• GRASP (*)に基づくライブラリ（Resende et
al. ’96）を使用
• QAPLIB (Burkard et al.)で性能をテスト
– 問題サイズnに対してnコアで並列に計算
– n <= 256の問題に対して5秒以内に既知の最良解の3%
以内の近似解を得ることができた
*GRASP = Greedy Randomized Adaptive Search Procedure
3. MC-MPIの設計と実装
29
発表の流れ
1.
2.
3.
4.
5.
6.
はじめに
関連研究
MC-MPIの設計と実装
MC-MPIの評価
SSOCK
おわりに
30
Core 2 Duo/Xeon MP/Xeon 5140
 Linux 2.6.18 (TCP BIC)
 クラスタ内のRTT: 0.18-0.24ms
 クラスタ内のBW: 930-940Mbps

実験環境
Chiba (64コア)
6.2ms
700Mbps
6.1ms
740Mbps
1.7ms
880Mbps
1.5ms
900Mbps
6.4ms
750Mbps
Istbs
(64コア)
Suzuk
(64コア)
Kototoi
(64コア)
0.3ms
890Mbps
Firewall
4. MC-MPIの評価
31
評価に用いたベンチマーク
• NAS Parallel Benchmarks (NPB) (der Wijngaart ‘02)
– MPIライブラリの性能や並列計算環境の性能の評価に
広く用いられているベンチマーク
– 異なる通信パターンの複数のベンチマークからなる
• BT、EP、IS、LU、MG、SP
• Distributed Verification Environment (DiVinE) (Barnat
et al. ‘06)
– MPIで記述されたモデル検査ツール
– 多くのメモリを要するので、複数のクラスタを用い
ることができると、より大規模な問題を扱うことが
できる
4. MC-MPIの評価
32
実験1 接続数と性能の関係
• 接続数を変化させたときの性能をNPBとDiVinEで
測定
– Manual (GridMPI-like)
• クラスタ内では全対全で接続を確立
• クラスタ間の通信のために手動で中継プロセスを1, 10, 20, …,
60個設定
– MC-MPI
• βを変化させて接続数を10%, 20%, …, 100%に制限
– Random
• ランダムに接続数を10%, 20%, …, 100%に制限
4. MC-MPIの評価
33
実験1 結果--Manual (1/3)
80%
90%
Relative performance
100%
Relative performance
100%
60%
80%
40%
20%
70%
Manual
0%
60%
Manual
50%
0 10 20 30 40 50 60
Number of forwarding processes per
cluster
Block Tridiagonal (BT)
0 10 20 30 40 50 60
Number of forwarding processes per
cluster
Embarrassingly Parallel (EP)
4. MC-MPIの評価
34
実験1 結果--Manual (2/3)
200%
90%
Relative performance
100%
Relative performance
250%
150%
80%
100%
50%
70%
Manual
0%
60%
Manual
50%
0 10 20 30 40 50 60
Number of forwarding processes per
cluster
Integer Sort (IS)
0 10 20 30 40 50 60
Number of forwarding processes per
cluster
Lower Upper (LU)
4. MC-MPIの評価
35
実験1 結果--Manual (3/3)
90%
80%
Relative performance
100%
Relative performance
100%
80%
60%
70%
60%
40%
Manual
50%
20%
Manual
0%
0 10 20 30 40 50 60
Number of forwarding processes per
cluster
Multi Grid (MG)
0 10 20 30 40 50 60
Number of forwarding processes per
cluster
Scalar Pentadiagonal (SP)
4. MC-MPIの評価
36
実験1 結果--NPB (1/5)
100%
Relative performance
90%
80%
70%
60%
MC-MPI
Random
Manual
50%
0% 20% 40% 60% 80% 100%
Maximum % of connections allowed
Lower Upper (LU)
Successive Over-Relaxation
(SOR)
4. MC-MPIの評価
37
実験1 結果--NPB (2/5)
80%
90%
60%
80%
40%
70%
MC-MPI
20%
Relative performance
100%
Relative performance
100%
Random
60%
Manual
MC-MPI
Random
Manual
0%
50%
0% 20% 40% 60% 80% 100%
Maximum % of connections allowed
Block Tridiagonal (BT)
0% 20% 40% 60% 80% 100%
Maximum % of connections allowed
Multi Grid (MG)
4. MC-MPIの評価
38
実験1 結果--NPB (3/5)
100%
Relative performance
80%
60%
40%
MC-MPI
20%
Random
Manual
0%
0% 20% 40% 60% 80% 100%
Maximum % of connections allowed
Scalar Pentadiagonal (SP)
4. MC-MPIの評価
39
実験1 結果--NPB (4/5)
• EPはほとんど通信を
行わない
100%
Relative performance
90%
80%
70%
MC-MPI
60%
Random
Manual
50%
0% 20% 40% 60% 80% 100%
Maximum % of connections allowed
Embarrassingly Parallel
(EP)
4. MC-MPIの評価
40
実験1 結果--NPB (5/5)
800%
250%
Relative performance
600%
Relative performance
Random
200%
MC-MPI
MC-MPI
Manual
150%
Random
Manual
400%
100%
200%
50%
0%
0%
0% 20% 40% 60% 80% 100%
Maximum % of connections allowed
Integer Sort (IS)
0% 20% 40% 60% 80% 100%
Maximum % of connections allowed
Allreduce-Alltoall-Alltoallv
4. MC-MPIの評価
41
実験1 結果--DiVinE
120%
120%
100%
100%
80%
80%
60%
40%
20%
Relative performance
140%
Relative performance
140%
60%
MC-MPI
Random
40%
20%
Manual
Manual
0%
0%
0% 20% 40% 60% 80% 100%
Maximum % of connections allowed
0 10 20 30 40 50 60
Number of forwarding processes per
cluster
Distributed Verification Environment (DiVinE)
4. MC-MPIの評価
42
実験2 遅延接続確立
• MC-MPIの遅延接続確立とMPICH-likeな遅延接続
確立を比較
– MC-MPI
• 接続数が30%に制限されるようにβを選択
– MPICH-like
• 接続数に制限を設けずにオンデマンドに接続を確立
4. MC-MPIの評価
43
実験2 結果
200%
80%
MCMPI
MPICHlike
Speedup vs. MPICH-like
% of connections established
100%
60%
40%
MCMPI
MPICHlike
150%
100%
50%
20%
0%
0%
Benchmark
Benchmark
確立された接続の数
4. MC-MPIの評価
性能
44
実験3 ランク割当て
• 3つのランク割当てを比較
– Random（ベースライン）
– Hostname（よく用いられる手法）
• 実ホスト名（1パターン）
• ホスト名が違っていたら？（23パターン）
– MC-MPI (QAP)
suzukXXX
chibaXXX
kototoiXXX
istbsXXX
4. MC-MPIの評価
45
実験3 結果 (1/3)
2
2.5
Speedup vs. Random
Speedup vs. Random
3
2
1.5
1
1.5
1
0.5
0.5
0
0
LU
Random
Hostname
MG
Hostname (Best)
4. MC-MPIの評価
Hostname (Worst)
MC-MPI (QAP)
46
実験3 結果 (2/3)
4
Speedup vs. Random
Speedup vs. Random
4
3
2
1
0
2
1
0
BT
Random
3
Hostname
SP
Hostname (Best)
4. MC-MPIの評価
Hostname (Worst)
MC-MPI (QAP)
47
実験3 結果 (3/3)
1
Speedup vs. Random
Speedup vs. Random
1
0.8
0.6
0.4
0.8
0.6
0.4
0.2
0.2
0
0
EP
Random
Hostname
IS
Hostname (Best)
4. MC-MPIの評価
Hostname (Worst)
MC-MPI (QAP)
48
MC-MPIのまとめ
• 広域環境用の接続管理とランク割当てを提案
• それらを用いてMC-MPIを実装
• 4クラスタ256コアの実広域環境で提案手法の有
効性を確認
– 接続管理
• 全対全/Random/Manual以上の性能
– 遅延接続確立
• MPICH-like以上の性能
– ランク割当て
• Random/Hostname以上の性能
4. MC-MPIの評価
49
発表の流れ
1.
2.
3.
4.
5.
6.
はじめに
関連研究
MC-MPIの設計と実装
MC-MPIの評価
SSOCK
おわりに
50
Scalable Sockets (SSOCK)
• ACM/IEEE Grid 2008（ポスター）
• MC-MPIをより汎用的にしたライブラリ
– Socket APIを提供することによってより多くの並列ア
プリ（ミドルウェア）を支援
• 通常のソケットの機能に加えて以下の機能（性
能）を提供
–
–
–
–
任意のノード間で接続を確立できる
全ノード間で接続を確立できる
通常のソケットと1対1通信性能が同等
通常のソケットより集合通信性能が高い
5. SSOCK
51
LibssockとSsockd
• Libssock
– 並列アプリにリンクするライブラリ
– プリロードしてOSのconnect、sendの代わりにlibssock
のものが実行されるようにする
• Ssockd
– 中継デーモン
– MC-MPIと同じ接続管理手法を用いる
5. SSOCK
52
動作図
ノード
libssock
ssockd
ssockd
オーバレイ
5. SSOCK
仮想接続
53
実験環境
InTrigger 11クラスタ + 東大 2クラスタ
13クラスタ、506ノード (1,264コア)
5. SSOCK
クラスタ
ネットワーク
Chiba
Global
Hiro
Global
Hongo
Global
Imade
NAT
Istbs
Global
Keio
Global
Kobe
Firewall
Kototoi
Global
Kyoto
NAT
Kyushu
Global
Mirai
Global
Okubo
Global
Suzuk
Global
54
実験1 接続性とスケーラビリティ
• 全1,264コアで1プロセスずつ立ち上げ、全対全
で接続を確立しようとした
• 通常のSocketライブラリ
– Imade (NAT)とKyoto (NAT)が通信できなかった
• SmartSockets-like
– 1プロセスが開けるファイルディスクリプタの数の制
限（1,024）に引っかかった
– Imadeが他のクラスタと53,800本接続を確立したとこ
ろでImadeのNATテーブルが溢れた
• SSOCK
– 全1,264プロセス間で接続を確立できた
5. SSOCK
55
実験2.1 1対1通信性能 (1/2)
クラスタ内(Kototoi)のピンポン性能
(240ノードのオーバレイ利用時)
1000
Bandwidth [Mbps]
800
600
400
200
SmartSockets-like
SSOCK
0
0
0.5
1
1.5
2
Message size [MB]
5. SSOCK
2.5
3
56
実験2.1 1対1通信性能 (2/2)
クラスタ間(Hongo-Okubo)のピンポン性能
(240ノードのオーバレイ利用時)
Bandwidth [Mbps]
80
60
40
20
SmartSockets-like
SSOCK
0
0
5
10
Message size [MB]
5. SSOCK
15
20
57
実験2.2 集合通信性能
Aggregate bandwidth [Mbps]
All-to-allの性能
(13クラスタ、338プロセス)
300
250
200
150
100
SSOCK
SmartSockets-like
50
0
0
1000
2000
3000
Message size [B/process/process]
5. SSOCK
4000
58
実験3 同時接続確立 (1/2)
• 多数のプロセスが同時に接続を確立しようとし
たときの挙動を調査
– 各クラスタで同じ数のプロセスを起動
• 各クラスタで1〜26プロセス
合計13〜338プロセス
– 全プロセスに同時に互いにノンブロッキングコネク
トをさせた
5. SSOCK
59
実験3 同時接続確立 (2/2)
50
SmartSockets-like
SSOCK
Completion time [s]
40
30
20
10
0
0
50
100
150
200
250
Total number of processes
5. SSOCK
300
350
60
SSOCKのまとめ
• MC-MPIをより汎用的にしたSocketライブラリ
SSOCKを実装
• 13クラスタ338〜1,264コアの実広域環境を用い
てSSOCKの有効性を確認
– 接続性・スケーラビリティ
• 通常のSocketライブラリ/SmartSockets-likeより良い
– 1対1通信性能
• SmartSockets-likeと同等
– 集合通信性能 (all-to-all/同時接続確立)
• SmartSockets-like以上
5. SSOCK
61
発表の流れ
1.
2.
3.
4.
5.
6.
はじめに
関連研究
MC-MPIの設計と実装
MC-MPIの評価
SSOCK
おわりに
62
予備審査での指摘に対する回答 (1/3)
• アプリケーションとしてNPBは適切か？
– NPBには様々なベンチマークが含まれていて、適切な
ものとそうでないものがある
• LUの性能: 4クラスタ > 1クラスタ（グリッド向き）
• ISの性能:
4クラスタ < 1クラスタ（グリッド不向き）
• EPの性能:
4クラスタ > 1クラスタ（グリッド向きだが、
MC-MPIがなくても高速に実行できる）
– NPBは並列化によるスピードアップにのみ注目してい
るが、より多くのメモリが使えることも並列化の嬉
しさである
• 多くのメモリを要する計算の高速化の例としてDiVinEの実験
を追加した
6. おわりに
63
予備審査での指摘に対する回答 (2/3)
• 実験の比較対象は適切か？
– よく用いられる既存手法との比較が不十分だったの
で、それらの手法との比較を追加した
– 接続管理の実験ではManualを追加した
– SSOCKの実験ではSmartSockets-likeを追加した
• New Renoのせいで性能が出ていないということ
がないか？
– New RenoではなくBICが用いられていることを確認し
た
– All-to-allの性能が落ちる理由としてウィンドウサイズ
が小さくなってしまうことに加えてRTO待ちがあるこ
とを確認した
6. おわりに
64
予備審査での指摘に対する回答 (3/3)
• 無線ネットワークのアダプティブルーティング
で似た研究はないか？
– 接続が限られている点やリンク性能を測定して環境
に適応する点では似たものがある
– 無線ネットワークでは遠いノードと接続できない
「遠いノードとつなぎすぎ」という問題はそもそも
ない
• 手を広げすぎない方が良いのでは？
– 計算中のプロセスの参加・脱退を許すアプローチな
どの新たなことに手を出すのは止めた
– ManualやSmartSockets-likeとの比較やDiVinEを用いた実
験を追加して、既に提案していた手法の評価を充実
させた
6. おわりに
65
発表のまとめ
• 広域計算環境で煩雑な設定をすることなく大規
模な並列計算を効率良くできるようにするため
に、通信ライブラリの設計と実装を研究した
– 接続管理とランク割当てを提案
– MC-MPIとSSOCKを実装
– 4〜13クラスタ、256〜1,264コアという大規模な実広
域計算環境で既存手法に対する優位性を示した
6. おわりに
66
今後の課題
• SSOCK
– Socket APIの（ほとんど）すべてをサポートすること
– 様々なミドルウェアが広域環境で利用可能になる
• MC-MPI vs. MPICH2にSSOCKをリンクしたもの
• より大きな目標
– 広域リンクのバンド幅のばらつきに注目した手法の
研究
• 提案手法は、広域リンクが性能のボトルネックになり、ス
ケーラビリティを妨げることは、正しく捉えている
• しかし、広域リンクのバンド幅にはばらつきがあり、それは
必ずしも遅延とは相関がない
6. おわりに
67
発表文献
• 論文誌
– Collective Operations for Wide-area Message Passing Systems Using
Adaptive Spanning Trees (IJHPCN)
– 広域MPI用の局所性を考慮した接続管理とランク割当て (ACS 20)
– 適応スパニングツリーを用いた広域メッセージパッシングシス
テム用の集合通信 (ACS 11)
– Expedite: An Operating System Extension to Support Low-latency
Communication in Non-dedicated Clusters (ACS 7)
• 国際会議
– Locality-aware Connection Management and Rank Assignment for
Wide-area MPI (IEEE CCGrid ‘07)
– Collective Operations for Wide-area Message Passing Systems Using
Adaptive Spanning Trees (IEEE/ACM Grid ‘05)
• その他34件
6. おわりに
68