1 / 29

並行計算に基づく 並列プログラミング言語のための 効率的なコンパイルの枠組

並行計算に基づく 並列プログラミング言語のための 効率的なコンパイルの枠組. 大山恵弘 東京大学大学院 理学系研究科 情報科学専攻 米澤研究室. 記述が楽. 実行が速い. かつ. 言語がほしい. 今日の並列プログラミング. ポピュラーな方法. C, Fortran,. 並列拡張ライブラリ. +. プログラマ の責任. メモリ管理. 同期、通信. スレッド（プロセス）の生成と終了. なぜポピュラーか？. C で書けば速いよ！. しかし、、、 多くの 開発時間、人員、能力. 細粒度スレッドをサポートする言語 （1/2）. 例

colby-moon
Download Presentation

並行計算に基づく 並列プログラミング言語のための 効率的なコンパイルの枠組

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 並行計算に基づく並列プログラミング言語のための効率的なコンパイルの枠組並行計算に基づく並列プログラミング言語のための効率的なコンパイルの枠組 大山恵弘 東京大学大学院 理学系研究科 情報科学専攻 米澤研究室

  2. 記述が楽 実行が速い かつ 言語がほしい 今日の並列プログラミング ポピュラーな方法 C, Fortran, ... 並列拡張ライブラリ + プログラマ の責任 メモリ管理 同期、通信 スレッド（プロセス）の生成と終了 なぜポピュラーか？ Cで書けば速いよ！ しかし、、、多くの開発時間、人員、能力

  3. 細粒度スレッドをサポートする言語（1/2） • 例 • 並列オブジェクト指向言語 • 並行論理型言語 • 関数型言語＋並列拡張 • 特徴 • 動的スレッド生成で並列性抽出 （Fibの例: 2つの子をスレッド生成して計算） • 多数のスレッドを生成可能（何十万、何百万）

  4. 細粒度スレッドをサポートする言語（2/2） • 利点 • 均等な負荷分散 • プロセッサ効率の向上 • アルゴリズムの自然な記述 • 実装上の問題 • 動的スレッド生成オーバヘッド • 同期、通信オーバヘッド

  5. London Moscow New York Los Angeles Hong Kong Dakar Singapore Salvador Cape Town Sydney Antarctic 細粒度スレッドをサポートする言語（2/2） 細粒度スレッド技術 97年度輸出状況（推定）

  6. 負荷の不均衡 細粒度マルチスレッドが有効な例 （1/2） • 例題１: 枝刈りつき並列木探索（RNA） 仕事の単位を 細かく分ける必要 特徴: 部分木の計算量予測困難 64台CPU使用時に65個の スレッドができたら困る 細粒度マルチスレッド言語: 言語が細かい仕事を管理

  7. 細粒度マルチスレッドが有効な例 （2/2） • 例題2: 並列文法解析（CKY） Cによる単純な記述: スピンロックで待つ 長時間無駄仕事する可能性 細粒度マルチスレッド言語: CPUを無駄にせず 別の仕事を実行 特徴: 同期待ち時間 予測困難

  8. 貢献 • 細粒度スレッドの効率的なコンパイルの枠組み • 並行計算を利用 • スレッドスケジューリングの回数を減らす技法 • スレッド間通信をレジスタで行う技法 • 並列オブジェクト指向言語Schematicの実装 • 単一プロセッサWS & SMP • Lazy Task Creation 方式による動的負荷分散を実装 • 現実的なアプリケーションで性能評価 • Cと比較

  9. 以降の発表の流れ • 我々の使用する言語 • ナイーブなコンパイル技法 • 提案するコンパイル技法 • コンパイル時スケジューリング • Unboxed チャネル • 動的負荷分散 • 性能評価 • 関連研究

  10. 我々の言語の概要 • 表層言語: Schematic [田浦ら 96] • Scheme ＋非同期呼び出し拡張 • 高効率なスレッド生成 • 呼び出しコスト: 同期呼び出し ≒ 非同期呼び出し • 1st-class の通信媒体（チャネル） • 中間言語: 並行計算HACL [小林ら 95] • プロセスがチャネル通信によって計算 • ごく少数の本質的なプリミティブ • 単純で解析や最適化の platform に適する

  11. 受信成功: を実行可能な仕事として タスクキューにエンキュー 受信失敗: を待ちキューにエンキューし タスクキューから仕事を取り出して実行 細粒度マルチスレッド言語のナイーブな実行方式 スレッド生成 ＝ タスクキューへのエンキュー タスクキュー内の各仕事はメモリで通信

  12. 提案するコンパイル技法[大山らEuro-Par 97] • 最適化1: コンパイル時スケジューリング • 複数のスレッドのコードを並べて生成 • タスクキュー操作の回数を削減 • 最適化2: unboxed チャネル • レジスタにチャネルの内容と状態を持たせる • メモリを使用しないスレッド間通信

  13. 変換規則によるコンパイルアルゴリズムの記述変換規則によるコンパイルアルゴリズムの記述 Receive Parallel F (r(v)=>P) U k = if (r has a value) then let valv= get_value(r) inF (P::U) kend else let funs(l,v) =F [P] l in put_process(r,s); FU k end F (P1|P2) U k = F (P1::(P2::U)) k Send F (r<=v) U k = if (r has a process) then let valp = get_value(r) fun s(k) =p(k, v) inFU (s::k) end else put_value(r,s); FU k Process instantiation Conditional F ( f(x1, ...,xn)) U k = let funs(k) =FU k inf((s::k),x1, ...,xn)end F (ifxthen P1 elseP2) U k = ifxthenF (P1::U) k elseF(P2::U) k .....

  14. if （受信成功） then else no を待ちキューに格納 コンパイル時スケジューリング （1/2） 受信 スレッド

  15. no をスタックにプッシュ f (r,1,2)の本体へ飛ぶ コンパイル時スケジューリング（2/2） タスクキューが不要なわけではない f (r,1,2) unknownな関数 スタック: 実行可能なクロージャの集合を保持

  16. 全く複製しないコードサイズ × プログラマが与えた定数 ≦ 生成されるコードサイズ if （受信成功） then コード複製戦略 else 複製を行わずコード生成

  17. Unboxed チャネル • [田浦ら94]で最初に提案 • レジスタ上にチャネルの状態と内容を保持 • 必要に応じメモリにチャネルを作成 unboxed チャネル unboxed チャネル レジスタ上で値通信 スタック

  18. メモリ上通信 仕事を盗む 動的負荷分散 • Lazy Task Creation [Mohr et al. 91] に基づく レジスタ上 通信

  19. 性能測定 • 同じアルゴリズムのCプログラムと比較 • 逐次版: SS20 (HyperSparc 150MHz) • 並列版: Sun Enterprise 10000 (UltraSparc 250 MHz × 64) • Schematicの動的型チェックは除いている • 並列版SchematicのGC時間は除いている

  20. 逐次版性能測定結果（各最適化の効果）

  21. 逐次版性能測定結果（Cとの比較）

  22. 並列版性能測定結果（単純な並列性を持つ問題）並列版性能測定結果（単純な並列性を持つ問題）

  23. 並列版性能測定結果 （RNA）

  24. 並列版性能測定結果 （CKY）

  25. 関連研究 （1/3） • Id[Schauser et al. 95], Fleng[荒木ら97] • 依存関係解析によるスレッドの静的融合 • 我々は同様の効果をコード複製によって実現 • Pict[Turner96] • 我々と同じく並行計算のコンパイルを扱う • すべてのチャネル操作にメモリ操作が必要 • 受信前と後の実行を同一スレッド内で行えない

  26. 関連研究 （2/3） • StackThreads[田浦ら94, 97] • Unboxed チャネルを最初に提案 • 我々は unboxed チャネルを、一般的な 並行計算のコンパイルの枠組みの中に導入 • リニアチャネル[小林ら96,五十嵐ら97] • リニアチャネル ＝ 一回だけ使われるチャネル • リニアチャネルによる通信を静的に除去 • Unboxed チャネルとは直交した方法で、共存可能

  27. 関連研究 （3/3） • CPS[Appel 92] • 逐次言語のためのコンパイルの枠組み • Unboxed チャネルの定式化に 彼らの callee-save レジスタの技術を使用 • Cilk [Blumofe et al. 95] • Cを非同期関数呼び出し拡張 • 我々と同じく細粒度スレッドを効率よく実行 • 我々の言語よりも同期構造が制限されている • 親が子の終了を待つ以外の同期ができない

  28. 結論 • 並行計算を効率的にコンパイルする枠組み • コンパイル時スケジューリング (スレッドの融合) • Unboxed チャネル (レジスタ上スレッド間通信) • 並列オブジェクト指向言語Schematicの実装 • 逐次版: 平均してCの 2.5 倍 • 並列版: 高い台数効果 (50台でFib:47倍, RNA:24倍, CKY:15倍)

  29. 今後の研究 • RNA, CKYの台数効果をさらに向上 • RNA:ビジー時間が伸びる原因の究明 • CKY:アイドル時間を減らす手法の提案 • DSMマシン上高性能実装技術の提案 • 外山（四年）の手によってすでに移植は完了 • コード複製戦略の改良 • 頻繁に実行される部分を優先的に複製 • マルチスレッド拡張Cの実装

More Related