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

背景と目的

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

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

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

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

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

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

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

技術的な話

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

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

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

本方式の処理の流れ

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

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

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

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

実験的な話

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

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

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

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

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

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

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

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