スケーラブルでないモジュールを含む

並列プログラムにおける高性能の達成

Achieving High Performance in Parallel Programs Containing Unscalable Modules

東京大学 大学院理学系研究科 情報科学専攻

大山恵弘

満足のいく性能モデル

• プロセッサ増加　⇒　実行時間減少 or 実行時間そのまま

はたして現実は？

すべてのプログラムで成立してほしい

Motivating Example

• 各スレッドが独立に fib(10) と共有カウンタの増加を交互に繰り返し実行するプログラム– C + Pthreads, Sun Enterprise 10000– 仕事量の総和はプロセッサ数に非依存

0

500

1000

1500

2000

0 10 20 30 40 50 60

number of processors

tim

e (m

sec) fib

fib + counter(spin)

fib + counter(mute x )

実行のほんの一部が逐次化↓

満足のいく性能モデルが破綻

実行を逐次化するモジュール（ボトルネックモジュール）

• Thread-unsafe ライブラリ– MPICH 、 GTK+

• 共有資源の操作– I/O 、 GUI 、大域変数、共有バッファ– 並列ループの誘導変数

• 暗黙に排他処理するライブラリ– 多くの malloc の実装

広範囲に存在！

現状

並列プログラム

逐次モジュールがほとんどないプログラム

多くの並列プログラムで不満足な性能モデル！

Fib行列積

暗号破り web サーバ

GUI

自然言語処理

並列分野の既存研究の多く

本研究の目的

• 満足のいく性能モデルを、すべての並列プログラムで実現する言語– 共有メモリ計算機が対象

We don’t like U

ボトルネックの最大性能ギリギリ

Q: 満足のいく性能モデルを 得ることに意味あるの？

A: ある！

time

number of processors

このへんで実行したら悲劇（最高性能の半分）

Ｕ字の底のプロセッサ数で実行すればいいのでは？

• 最適なプロセッサ数は予測困難– 動的な挙動の予測はときに困難– 最適な数は入力やプログラムの場面に依存

色々なプロセッサ数で何回も同じ計算をするのは処理系実装者やベンチマーク屋だけ！

我々の怒り

そんな苦労をプログラマに負わせておいていいのか？

こんな高飛車で、万人に並列処理が普及するか？

多くの並列プログラマが唯々諾々と従っている啓示

「並列化の恩恵受けたければ、 ボトルネックを皆無にすべし」

「最高性能を出すプロセッサ数は プログラマが自分で見つけるべし」

並列処理を大きくdiscourage ！

我々が取り組んだ問題

• ボトルネック存在下でも高性能を出すには

– 排他処理– スレッドスケジューリング– 言語設計

はどうあるべきか？

３つの本質的な部分問題

• ボトルネック部分の実行コストの削減– ボトルネック担当プロセッサの動的導入で達成

• ボトルネック部分の実行回数の削減– 複数の呼び出しの「融合」で達成

• ボトルネック部分での過大なメモリ消費の抑制– プロセッサ数の動的制御で達成

３つのポイントがもたらすものti

me

number of processors

１

２

３つのポイントがもたらすもの

number of processors

３

limitメモ

リ消費量

Part 0

我々の言語

我々の言語 Amdahl

• C++

+ 軽量スレッド

+ 排他メソッド

単純なプログラミングモデルを提供

スレッド

• API:athread_create(f, arg, thr_id);

• Lazy Task Creation [Mohr et al. 91] にもとづくスレッド管理– 低コストで多数のスレッドを生成可

• 「並列単位 1 つ　⇔　スレッド 1 つ」のプログラミング

– ランタイムが自動的に動的負荷分散• Task stealing

排他機構

• 排他メソッド– ≒ synchronized methods in Java– １つのオブジェクト上で排他的に実行されるメ

ソッドclass Counter { int value; … sync inc(int n) { value += n; } }

Part 1

ボトルネック部分の実行におけるメモリ通信コストの最小化

情報処理学会論文誌に掲載その拡張版を国際学会 PDSIA ’99 で発

表

ボ

ＣＰＵ１ ＣＰＵ２ ＣＰＵ３

既存の逐次化モジュールの実装法

• ロックを付加し呼び出しを逐次化

既存の方法の問題 （ 1 ）

• ロック操作で大きなメモリアクセス遅延– 同じアドレスへのアクセスの衝突

→アクセスコストの飛躍的増加

ＣＰＵ１ＣＰＵ２

ＣＰＵ３

ボ

ＣＰＵ１ ＣＰＵ２ ＣＰＵ３

a, b

既存の方法の問題 （ 2 ）

• 更新された情報の読出でキャッシュミス– 異なるプロセッサが交代で実行するため

Amdahl のランタイム技術

• アクセス衝突 →　呼び出しデータ（タスク）のリスト作成

• 複数の呼び出しを１プロセッサが連続実行

ＣＰＵ１

ＣＰＵ２ ＣＰＵ３

f(5) f(3) f(7)

ボ a, b

担当するぞ！

Amdahl のランタイム技術

ＣＰＵ１

ＣＰＵ２ ＣＰＵ３f(5) f(3) f(7)

ボ a, b

• アクセス衝突 →　呼び出しデータ（タスク）のリスト作成

• 複数の呼び出しを１プロセッサが連続実行

この方法がもたらす利益

• ロック操作の大幅減少– 例： １回ロック操作して、３０個メソッド実行– 全部消えはしない

• 連続実行中：オブジェクトの読出と更新　　　　　　　　　　　　⇔ キャッシュの読出と更新

• ボトルネックに常にプロセッサ

Amdahl のコンパイル時最適化

• メモリ読出コストをさらに削減– Prefetch 命令の挿入– 手続き間 register promotion

f(5) f(3) f(7)

これの実行中 この情報を prefetch

ＣＰＵ１ボ a, b

連続実行中は a,b をレジスタに

置く

実験

• アプリケーション– N body, RNA

• 比較したもの– C + Solaris threads + task queue

• Spin locks, mutex locks

– Amdahl• Spin locks, mutex locks, 我々の提案する方法

• Sun Enterprise 10000 （ 64 CPU ）

RNA

0

5000

10000

15000

20000

0 10 20 30 40 50 60number of processors

time

(mse

c)

C + Solaris threads(spin)C + Solaris threads(mutex)Amdahl (spin)

Amdahl (mute x )

Amdahl (detach)

N body, 木作成フェーズ

0

2000

4000

6000

8000

0 10 20 30 40 50 60number of processors

time

(mse

c)

C + Solaris threads(spin)C + Solaris threads(mute x )Amdahl (spin)

Amdahl (mutex)

Amdahl (detach)

N body, 全フェーズ合計

0

15000

0 10 20 30 40 50 60number of processors

time

(mse

c)

C + Solaris threads(spin)C + Solaris threads(mute x )Amdahl (spin)

Amdahl (mutex)

Amdahl (detach)

非衝突時の性能Cで書いたマイクロベンチマーク

0

200

400

600

800

1000

1200

tim

e (m

sec)

no lockroundrobinspinticketMCSSolar is m ut e xblockAmda h l

•Amdahl の方法の実行時間：•単純な blocking lock の 0.92 倍•単純な spin lock の 1.32 倍

Part 2

複数の排他的な操作を融合する機構

情報処理学会論文誌に掲載

既存の枠組みの問題

• プログラムの動的挙動に適応する効率化支援機構が少ない– 我々の観測：　アクセス衝突時に生じる効率化の

機会を　　　　　　 有効利用できていない

windowＣＰＵ１

ＣＰＵ２ ＣＰＵ３

repaint repaint repaint

重複して呼び出し

Amdahl のアプローチ

• 排他メソッドの複数の呼び出しの融合

– 動的に逐次化された２つの呼び出しを融合

– プログラマが融合規則を記述

プログラム例 （１ / ２）

class Window { … sync repaint() { … } fusion repaint() & repaint() { repaint(); }}

融合規則

repaint を「まびき」

プログラム例 （２ / ２）class Buffer { int len; double elements[...]; ... sync void put(double v) { elements[len++] = v; } sync double get() { return elements[--len]; }

fusion put(v) & get() { return v; }}

融合規則

put と get を「バイパス処理」

融合処理の実装

windowＣＰＵ１

ＣＰＵ２ ＣＰＵ３

repaint repaintrepaint

タスクリストの操作で実現

専念！ ♪

この融合の研究の広い見方

• 並列言語ならではの効率化の機会を指摘した– 逐次言語 :

– 並列言語 : 文面に現れない制御フロー•既存研究の盲点

x = y-2;x += 3;

x = y+1;

val +=1; val +=

2;

val +=3;

実験

• ImageViewer– repaint & repaint → repaint

• FileWriter– write & write → strcat + write

• RNA– inc & inc → inc

ImageViewer

0

5000

10000

15000

20000

0 2 4 6 8 10 12

number of processors

tim

e (m

sec)

no fusion fusion

FileWriter

0

2500

5000

0 10 20 30 40 50 60

number of processors

tim

e (m

sec)

no fusion fusion

RNA

0

2000

4000

6000

0 10 20 30 40 50 60

number of processors

tim

e (m

sec)

no fusion fusion

Part 3

プロセッサ数の動的調節によるメモリ消費量の制御

単純な実装における問題

• ボトルネックにおける大きなメモリ消費量

ボ

ＣＰＵ２

ＣＰＵ３f()

...

ＣＰＵｎＣＰＵ１

f() f()…..

生産者消費者アプリケーション一般が共有

メモリ消費量拡大による悪影響

• Cache miss, page fault の増加– Working set の増加による

• 他ジョブで使えるメモリが減少– １つの邪悪なプログラムが、その計算機上

の全プログラムを凍らせうる

Motivating Example

←

タス

ク数

ボトルネックに付加されるタスク数： 数百のオーダ

我々の目標

• １つのオブジェクト（モジュール）に付加されるタスク数の最大値を小さく抑える– 例：各オブジェクトに最大６４個

– 「メモリ消費量の制限⇔タスク数の制限」と問題を限定

目標達成のための単純な方法

• タスク数 ＝ 閾値→タスクを入れようとするＣＰＵはスピンして待つ

ボＣＰＵ３f()

ＣＰＵ１

f()…..

f()デッドロック発生！（詳細は論文を参照）

64

我々はより緩い目標をめざす

• Soft limit をほとんどの場合に越えない

タス

ク数

時間

soft limit

我々のアプローチの概要

• プロセッサ数の動的調節でタスク数を制御

– タスク数が soft limit を越えそう　　→プロセッサ減らす　　　 タスク生成ペースを遅らせる

– タスク数が soft limit を越える気配なし　　→減らしたプロセッサを復活させる

Amdahl の実装

ボf()

ＣＰＵ１f()…..

２８２８生存可能プロセッサ数カウンタ

定期的に更新

５０５０現プロセッサ数カウンタ

ＣＰＵ２

ＣＰＵ３

...

ＣＰＵ５０脱退！

プロセッサの脱退

ＣＰＵ１５ ＣＰＵ３７thread

thread

thread

thread

thread

thread

thread

プロセッサの増加

４８４８生存可能プロセッサ数カウンタ

３１３１現プロセッサ数カウンタ

ＣＰＵ１

ＣＰＵ２

...

ＣＰＵ３１

定期的にチェック

ＣＰＵ３２

ＣＰＵ３３

生存可能プロセッサ数の決定法

• 次のカウンタ更新時のタスク数を予測– 過去の履歴からタスクが入るペース、出るペースを予測

• その数が soft limit を越えないよう、入るペースを調節– 仮定： 入るペース∝プロセッサ数

ボ

...

soft limit = 64

プロセッサ数を 20/60 ＝ 1/3 に

44 20

......

60

実験結果

• ほとんどの時間で soft limit 以下• タスク数小 → プロセッサ数増 •最大タスク数 ＜ ２ ×soft limit

実行時間 ( ６０プロセッサ上）

0

0.5

1

1.5

2

Fib&Memwrite RNA N body

norm

aliz

ed e

xecu

tion

tim

e

numprocessors fixed numprocessors varied

（ Part 4 ）

クリティカルパスの実行時計算

国際学会 HIPS 2000 で発表（ LNCS vol. 1800 ）

クリティカルパスの実行時計算

• プログラムにコードを挿入• クリティカルパスを求めつつプログラムを実

行• Cilk [Blumofe et al. 95],

Paradyn [Hollingsworth 98]

• クリティカルパスの利益– 性能モデルの調査と検証を

助ける– チューニングすべき場所の

発見に役立つ

我々がやったこと

• 既存の方法を改良– メモリ通信コストを考慮– 第一級通信データ構造の導入

• 改良した方法を並列言語 Schematic に実装– 実験で有効性を確認

関連研究 （１ / ３）

• 互いに干渉しない排他処理間の並行性抽出– ICC++ [Chien et al. 96], OPA [Yasugi et al. 98],

Schematic [Taura et al. 96], Reader-writer locks

• Associative な操作の並行実行– CA [Chien 91], Reduction [Fisher et al. 94],

Adaptive object replication [Rinard et al. 99]

衝突した複数の排他操作

干渉しない Associative

関連研究 （２ / ３）

• Locality-Enhanced Staged Server [Larus 00]– 似た操作を固めて実行して局所性向上– まだアイデア段階。実験結果なし

• Network combining [Gottlieb et al. 83]– ネットワークスイッチによる複数の命令の融合

• プログラム変換による複数の処理の融合– Bird-Meertens Formalism [Bird 89], Loop fusion,

Deforestation [Wadler 90], Parallel scans,プログラム融合変換 [Onoue et al. 97]

– 静的に検出できる連続した操作を静的に融合

関連研究 （３ / ３）

• プロセッサ数の動的調節– [Hall et al. 97], [Thitikamol et al. 99], [Yue et al. 96], [Werner-

Kytölä et al. 00], [Nguyen et al. 96], [Severance 96]

– 過去の性能を基にイテレーションの切れ目や並列ループの直前のみで調節

• Congestion avoidance for TCP– [Jacobson 88], [Jain et al. 97], [Brakmo et al 95]– データ生成ペースの動的調節という点で共通

• Ninja [Welsh et al. 2000]– サーバの要求キューの長さの制限– まだアイデア段階。実験結果なし

今後の課題

• 各排他処理実装の性能のよりよい理解– 「なぜ我々の方式が速いか」を形式的に議

論

• 正しい融合規則の記述の支援– 明らかに誤った融合規則を静的に検出

• 性能向上を強く志向したプロセッサ数制御

まとめ

• 満足のいく性能モデルの実現に大きく近づける並列言語実装技術を提案　　　

全体性能 最低性能のモジュールの性能（ GUI, I/O, mem. allocator, counter… ）

極限まで近づけた！

• プロセッサを投入しすぎたときの悲劇を最小化• 「軽いスレッド ＋ 排他メソッド」による 快適な並列プログラミングモデルを維持

Amdahl がもたらすもの

並列実行

株

高 リスク高リターン

単純でないプログラム

逐次実行維持タンス預金

低リスク低リターン

Amdahl による

値下がりしない

低

並列処理がより広く普及！並列プログラマは待望のエル・ドラドを獲得！

なだれ

資産

おわり

• Visit

http://www.yl.is.s.u-tokyo.ac.jp/~oyama/publications/