実行時情報を用いて通信を最適化するPCクラスタ上の並列化コンパイラ

Presentation on theme: "実行時情報を用いて通信を最適化するPCクラスタ上の並列化コンパイラ"— Presentation transcript:

1 実行時情報を用いて通信を最適化するPCクラスタ上の並列化コンパイラ
横田 大輔（筑波大学） 千葉 滋（東京工業大学） 板野 肯三（筑波大学）

2 背景と目的

3 計算物理のプログラム =ある特定の計算パターンの 莫大な繰り返し 精度(反復解法) シミュレーション時間
(× NAS Para. BT:200,FT:6,IS:10….)

4 計算物理の最適化 最適化に時間をかけられる 実行時間そのものが長い(数週間～数ヶ月) コードの核になる部分は繰り返される
特定の部分はわずかな時間短縮でも劇的な効果

5 計算物理のための自動並列化Fortranコンパイラ
コンパイル中にソースコードの一部をプレ実行して最適化に使おう ソースコードに依存しない解析力 通信パターンが直接わかる 解析時間は延びる

6 動的な手法を用いたコンパイラ 動的な手法で通信を解析 コンパイル時にコードの一部を実行 ハードウェアに依存した通信の最適化
プレ実行＝PCクラスタ 本実行＝並列計算機　(まどろっこしい？) ハードウェアに依存した通信の最適化 通信をブロックストライドにまとめる TCW再利用型の通信を利用する 通信が少なくなるようにループを区切る

7 プレ実行と本実行 プレ実行をPCでやる理由 本実行を並列計算機でやる理由 コンパイラを実機で動かせない バッチ方式だと不利
餅は餅屋(CP-PACS/Pilot3(SR2201): 300MB/secの転送速度、実測値も遜色なし。)

8 開発したFortranコンパイラ 入力はHPFのサブセット 出力はCP-PACS/Pilot3用プログラム
BLOCK,INDEPENDENT,PROCESSOR,… 出力はCP-PACS/Pilot3用プログラム RDMA(ブロックストライド+TCW再利用型通信)を駆使したコード SPMDなFortran

9 これまでの我々の研究との比較 今回：プレ実行=PCクラスタ SWoPP00,IPSJ並列処理特集号00： プレ実行=1台のPC
各プロセッサの通信パターンが異なってもよい 通信面以外はつりあう 通信は実際にはおこなわない (通信パターンが通信によって決まるのは×) コンパイラも並列アプリケーションの一つ SWoPP00,IPSJ並列処理特集号00： プレ実行=1台のPC 並列機とはつりあわない→制限→問題 (プレ実行するソースコードは１PE分、全てのプロセッサは同じパターンで通信するソースしかコンパイルできない。）

10 技術的な話

11 CP-PACS/Pilot3 ブロックストライド (ハードウェアサポート) TCW再利用型通信 (ハードウェアサポート) 片側通信
クロスバーによる接続 2048PE(CP-PACS),128PE(Pilot3)

12 ブロックストライド ブロックストライド １ ２ ３ ４ 通常の通信

13 TCW再利用型通信 レイテンシの少ない通信 事前にセッティング 同じパターンの通信が繰り返される場合に有効 IDで送信元と受信先を選択
セッティング自体は比較的重い 同じパターンの通信が繰り返される場合に有効 IDで送信元と受信先を選択

14 本方式の処理の流れ

15 本コンパイラが行う最適化 通信量が少なくなるようにループを分割する 通信をブロックストライドにまとめる
通信のパラメータがループに依存しない場合、TCW再利用型の通信を使う

16 最適なループの分割 通信量が少なくなるようにループを分割する すべてのプロセッサに関して、ループの反復あたりの通信量を調べる
通信量が少ない反復を優先的にプロセッサに分ける

17 ブロックストライドの利用(1/2) 通信をブロックストライドにまとめる 実行時の情報をヒントにする
INDEPENDENT命令をヒントに通信を融合 INDEPENDENT命令があるループは反復の順番を無視していい 同時に発行できる通信の塊からブロックストライドを切り出す

18 ブロックストライドの利用(2/2)

19 実験的な話

20 実装 OS:Linux Red Hat7.1 HW:PIII733hz,128MbytesのPCクラスタ
バックエンド:日立製Fortran90コンパイラ(02-06-/C XF XJ)

21 予備実験 FT class-A (NAS Para.:HPF版) 繰り返し数=6
pde1 (Genesis Distribute Benchmarks) 規模=7,繰り返し数=1000 Pilot3上の1,4,8プロセッサ コンパイル環境はPCクラスタの4+(1),8+(1)ノード

22 実行結果(FT:class-A) (sec) ※　反復回数が足りない!!

23 実行結果(pde1:N=7,iter=1000) (sec) ※　反復回数が十分!!

24 まとめ ソースコードのうち、実行時間の支配的な部分を最適化した 最適化のための解析は動的に行った
前回の実装と違い、プロセッサの通信パターンが異なっても並列化可能(PCクラスタ) 計算物理に近いpde1では良好な結果が得られた NAS Para. BTは通信履歴があふれて並列化できなかった

25 関連研究 コードを書き換える パラメータを調整する 自動適応並列プログラム性能最適化ツールTEA Expert
佐藤三久，建部修見，関口智嗣，朴泰祐 パラメータを調整する ループ並列化の可否、tilling、serializing Voss, Eigenmann,

26 今後の課題 スケーラビリティの改善 SHADOW領域の対応 より物理シミュレーションに近い実験 通信パターンが変るプログラムは？
通信履歴の爆発(NAS Para.×BT) ソースコードの膨張 SHADOW領域の対応 より物理シミュレーションに近い実験 通信パターンが変るプログラムは？

27 まとめ2 ソースコードのうち、実行時間の支配的な部分を最適化した 最適化のための解析は動的に行った FTとpde1の実効時間を測定した
対象はブロックストライドとTCW再利用型通信、ループの分割である 最適化のための解析は動的に行った 重いがソースコードの影響を受けにくい FTとpde1の実効時間を測定した 計算物理に近いpde1では良好な結果が得られた