共有メモリ並列計算機上のスケーラブルな動的メモリ管理モジュール

共有メモリ並列計算機上のスケーラブルな動的メモリ管理モジュール

情報科学専攻米澤研究室遠藤敏夫

博士論文発表

プログラマの手間を軽くする自動メモリ管理

メモリオブジェクトを大量に使うプログラム自然言語処理、 ( 不規則 ) シミュレーション解探索問題、画像処理、ネットワークサーバ

において、明示的メモリ解放 (free()) はバグの温床マルチスレッドプログラムではさらに困難

自動メモリ管理によりプログラマの手間軽減本研究では探索型ガーベージコレクション (GC) を

対象

博士論文発表

メモリ管理モジュールはスケーラブルであるべき

共有メモリ並列計算機 : 高性能計算を可能とするプラットフォームの一つしかし、広まっているメモリ管理モジュール (OS 標準の

malloc(), Java VM などのメモリ管理 ) の多くは未並列化アプリによっては

スレッドあたり 100K 回 / 秒のメモリ確保 GC 時間の割合～ 20%

並列アプリの性能を保つにはスケーラブルなアロケータ +GC が必要

アプリを並列化してもメモリ管理が逐次のままでは無意味！

博士論文発表

研究の概要

共有メモリ並列計算機上のスケーラブルなメモリ管理モジュールの構築メモリアロケータ / GC の高速化技法の提案、実

装ボトルネック削減アーキテクチャの特徴 (SMP, DSM) を考慮した技法

性能モデルによる性能解析 ( フリーソフトウェアとして公開 )

http://www.yl.is.s.u-tokyo.ac.jp/gc/

博士論文発表

本モジュールの概要 (1)

対象ハードウェア : 共有メモリ並列計算機

対象ソフトウェア : マルチスレッドプログラム C/C++ Pthread, Solaris thread など

本発表では 1 スレッド =1 プロセッサを仮定各スレッドは共有ヒープ中の任意のオブジェクトをアクセス可

CPU

Mem

CPU

Mem

CPU

Mem

CPU

Mem

CPU

Mem

CPU

Mem

SMP: 対称型共有メモリマシン DSM: 分散共有メモリマシン

博士論文発表

本モジュールの概要 (2)

Conservative GC ライブラリ [Boehm et al. 88] の並列化拡張

BIBOP(Big-bag-of-pages) アロケータ各スレッドが並列にメモリ確保可能

マークスイープ GC複数スレッドが協調的に GC 処理ストップ並列 GC 並行並列 GC

本研究の技法の多くは BIBOP+ マークスイープ以外のシステムにも適用可能

博士論文発表

発表の概要

1. スケーラブルな並列アロケータ2. スケーラブルなストップ並列 GC ( 手短に )

3. ストップ並列 GC の性能モデル4. 並行並列 GC ( 手短に )

Part 1局所性を考慮したスケーラブルな並列アロケータ

(JSPP 2001 で発表 )

博士論文発表

並列プログラムのアロケータ :既存のアプローチ (1)

並列プログラムを記述するとき、アロケータをどうする？逐次アロケータ + 排他制御

Libc malloc などをそのまま使うと遅すぎる

○←

　→

×

SGI Origin 2000• 16byte のオブジェクト確保を繰り返した場合の malloc 回数 ( 全スレッド合計 )• 各スレッドを別プロセッサに割当• free 時間省いて計算

Libc malloc のスループット

0

0.2

0.4

0.6

0.8

1

1.2

0 20 40 60 80

スレッド数

mal

loc

(M

/)

回数

回秒

libc

博士論文発表

並列プログラムのアロケータ :既存のアプローチ (2)

各システム / アプリケーション独自のアロケータ高速にすることができるが、プログラミングの手間がかかる

汎用並列アロケータ ( 本研究のアプローチ ) [Larson ら 98] [Vee ら 99] …スケーラビリティ [Berger ら 00] …スケーラビリティ +消費量分散共有メモリ (DSM) マシンでの局所性への言及はまだない

博士論文発表

ローカルヒープさえ用意すれば充分か？

スケーラビリティ、局所性は良スレッド毎メモリ利用量が均一で

ない場合に問題各瞬間で必要なメモリ量はm だが、ア

ロケータによる消費量は 2m最悪、 ( 必要メモリ量 ×スレッド数 )の消費

m

mtime

time

thread 1利用量

thread 2利用量

スレッド毎のメモリ利用量の遷移例

スケーラビリティ局所性

メモリ利用効率トレードオフ

空き領域のスレッド間共有を許さない

許す

博士論文発表

並列アロケータが達成すべき目標

スケーラビリティ確保処理が並列にできる必要

局所性　 ( ここでは DSM に注目 ) 背景 : ローカル / リモートメモリのアクセスコスト差 (3 倍 ) 要求スレッドにローカルなメモリを渡せば、プログラム中のアクセス

コストが向上メモリ利用効率

アロケータによる消費量≧プログラムによる利用量消費量をなるべく小さく抑えるべき

スケーラビリティ、局所性プログラム性能のためメモリ利用効率他プログラムへの悪影響を小さくするため

博士論文発表

提案方式の概要

LPS(locality-aware page shared)方式 BIBOP(big bag of pages) 型アロケータの並列化方式スケーラブル

64プロセッサ (R10000 195MHz) で 25M malloc/s… 1 プロセッサ時の 36 倍

局所性・メモリ利用効率のトレードオフを連続的に調整可ユーザは許容消費定数 (k, 1≦k≦スレッド数 ) を調整

博士論文発表

BIBOP アロケータの概要

ヒープは固定サイズのページから成り立つ各ページは均一サイズのオブジェクトを含む空き領域を以下のリストで管理

フリーオブジェクトリスト ( サイズ毎 ) フリーページリスト

確保処理の流れ :- フリーオブジェクトリスト探索- 失敗ならフリーページリスト探索- 失敗なら OS から新ページ確保 / GC

freepage list

freeobj list

heap

博士論文発表

素朴な並列化方式

All Local(AL)方式空き領域をスレッド個別管理○ スケーラビリティ、局所性× メモリ利用効率

Page Shared(PS)方式空きオブジェクト : スレッド個別空きページ : 共有○ メモリ利用効率× 局所性

All-local(AL)

free obj list

free page listOS

threads

Page-Shared(PS)

free obj list

free page listOS

threads

博士論文発表

提案方式 : LPS方式

Locality-aware Page Shared (LPS)方式

空き領域のスレッド個別管理 + スレッド間の空きページ移動

1. 自フリーオブジェクトリストを探索2. 失敗なら、自フリーページリストを探索失敗したら、3a. 消費量が閾値を超えそうなとき、他リスト

を探索3b. 超えないとき、 OS から確保

Locality-aware page-

shared(LPS)

free obj list

free page listOS

threads

(k×max(l))

許容消費定数(ユーザが調節可能 )

最低限必要なメモリ量(PS の消費量に相当 )

k が小 → 利用効率重視k が大 → 局所性重視

博士論文発表

実験環境

計算機 : DSM マシン SGI Origin 2000 R10000 195MHz × 80 Hypercube network ページサイズ 16KB各ページは、プログラム中で最初にアクセスを行ったプロセッサ

にとってローカルな物理メモリノードに配置される (first-touch)

ベンチマークプログラム : Matmul( 行列積 ) CKY( 文脈自由文法パーザ ) BH(N体問題 ) 、論文参照C++, GC利用 , StackThreads/MP [田浦 99] 利用 (CKY のみ )

博士論文発表

予備実験 :確保処理のピーク性能

時間あたりのスレッド間合計 malloc 回数を計測 AL/LPS のスケーラビリティは良好

64 スレッドで 25M回 / 秒 (1 スレッド時の 36 倍 , libc 64 スレッドの 54 倍 )

0

5

10

15

20

25

30

0 20 40 60 80

スレッド数

mal

loc

(M

/)

回数

回秒

PSLPS(k=1)LPS(k=1.5)ALlibc

• 16byte のオブジェクト確保の繰り返し• メモリ利用量はスレッド間で均一• free/GC 時間省いて計算

○←

　→

×

博士論文発表

性能評価 (1): matmul

サイクリック分割された密行列の積行列積 1 回ごとに行列を確保しなおす各スレッドは自分の行 ( または列 ) を確保

AL方式以外ではローカルメモリとは限らない

1000×1000 行列同士の積を 30 回

× →

64スレッド実行時のデータ(MB)全確保量 496.2

(MB)最大生存量 43.9全確保回数 65065

(s)実行時間 25.7(/ s)確保頻度 2535.2

博士論文発表

性能評価 (2): matmul の性能

LPS/AL は PS より 3—19% 高速

0

20

40

60

80

0 20 40 60 80

スレッド数

(M

B)

最終

メモ

リ消費

量

0

0.2

0.4

0.6

0.8

1

0 20 40 60 80

スレッド数

リモ

ートペ

ージ

確保率

PSLPS(k=1)LPS(k=1.5)AL

0

50

100

150

0 20 40 60 80

スレッド数

()

実行

時間

秒

0

0.2

0.40.6

0.8

1

8 16 24 32 48 64

スレッド数

実行

時間比 PS

LPS(k=1)LPS(k=1.5)AL

博士論文発表

性能評価 (3): CKY

文脈自由文法パーザ文法データと文データから、あ

りうる構文を全て計算あらゆる部分文の構文要素をボ

トムアップに計算36—100単語の文を 200 文解析

単語

64スレッド実行時のデータ

各セルに解析結果のリストを格納

(MB)全確保量 1202.5(MB)最大生存量 31.6

全確保回数 79196965(s)実行時間 68.5(/ s)確保頻度 1155856.3

博士論文発表

性能評価 (4): CKY の性能

020406080

100120140

0 20 40 60 80

スレッド数

(M

B)

最終

メモ

リ消費

量

0

0.2

0.4

0.6

0.8

1

0 20 40 60 80

スレッド数

リモ

ートペ

ージ

確保率

PSLPS(k=1)LPS(k=1.5)AL

010203040506070

0 20 40 60 80

スレッド数

()

実行

時間

秒

0

0.2

0.4

0.6

0.8

1

8 16 24 32 48 64

スレッド数

実行

時間比 PS

LPS(k=1)LPS(k=1.5)AL

AL/PS 間消費量差が大きい LPS/AL は PS より最大 5% 高速

博士論文発表

考察

アロケータにより全体性能が変わる原因 : 確保処理の速度向上か？

32 スレッド以下でも差が出ている CKY でさえピーク性能の 10% 以下の確保頻度

局所性向上によるメモリアクセス速度向上か？ Matmul の速度向上が CKY より大きい原因は調査中

16 スレッド利用時のデータmatmul CKY

(/ s)確保頻度 980 1305000PSでのリモートアクセス率 0.84 0.87ALでのリモートアクセス率 0.72 0.48

考えにくい

(IRIX Memory Reference Counter により計測 )

博士論文発表

関連研究

ローカルヒープを用いたスケーラブルな並列アロケータ [ 市吉ら 94] … KLIC 用アロケータ。スレッドローカル GC [Larson ら 98] [Vee ら 99] … 共有ヒープへのアクセス頻度解析 [Berger ら 00] … BIBOP, メモリ消費量解析 [Boehm00] … BIBOP, 空きオブジェクトリストの一部のみス

レッドローカルいずれも DSM の局所性には言及せず

博士論文発表

Part1 のまとめ

並列 BIBOP アロケータ方式 LPS を提案ゴールは

スケーラビリティ　・・・　 64スレッドで 36 倍メモリ利用効率 DSM での局所性

ユーザは許容消費倍率の調節によって、トレードオフを自由に調節可

トレードオフ

Part 2スケーラブルなストップ並列GC

(SC97, JSSST 全国大会 98 で発表 )

博士論文発表

ストップ並列 GC

ストップ並列 GC方式 : 複数スレッドが協調的に GC を行う → GC 時間を短縮 GC 中は GC に専念 →　ライトバリアなどを避ける

ストップ GCスレ

ッド

並行 GC … × 飢餓状態の可能性


ユーザ GCtime

[Doligez 93] など

[Halstead 85] など並行並列 GC (Part 4)

[Cheng 01]

博士論文発表

並列マークスイープ GC(1) GC 開始時に全ユーザプログラムを停止全スレッドにより協調的にマーク処理 →　時間短縮したい ! 終わったらプログラム再開、少しづつスイープ

root

heap

root

heap

root

heap

博士論文発表

並列マークスイープ GC(2)

スケーラビリティのために、各スレッド毎にタスクプール ( マークスタック ) タスクスチール : ひまスレッドは他のマークスタックから仕事 ( マークすべきオブジェクト ) を獲得

スタックの底から一つだけ獲得　→　部分木を獲得することに相当

PE

PE

PE

Mark stack

PE

PE

PE

Mark stack

PE

PE

PE

Mark stack

PE

PE

PE

Mark stack

PE

PE

PE

Mark stack

Lazy task creation[Mohr et al. 90] の方式

博士論文発表

スケーラビリティのための最適化技法

巨大オブジェクトの分割スキャン

ボトルネックを除去した終了判定アルゴリズム DSM における、マークビットのメモリノード間均等配置

ボトルネック

博士論文発表

実験環境

計算機 Sun Enterprise 10000 SMP

Ultra SPARC 250 MHz × 64 10GB/s クロスバネットワーク

SGI Origin 2000 DSM プログラム

BH (N体問題 ) Cube (Rubik’s Cube近似解探索 ) CKY ( 文脈自由文法パーザ ) 論文参照

博士論文発表

アプリケーション : BH

Barnes-Hut アルゴリズムによる N 体問題プログラムフェーズ 1: 各質点を葉とする木構造を、位置を考慮し作成フェーズ 2: 各質点にかかる力を計算 ( 計算量 O(N log N))

近い点からの力を正確に計算遠い点からの力を木の中途ノードを用い近似計算

2 バージョンの並列プログラムフェーズ 2 のみ並列化 (BH-st)

→ 1 スレッドのみが木作成フェーズ 1,2 を並列化 (BH-pt)

30,000点を 20 ステップ計算ヒープサイズ : 50MB固定

A

点

60 スレッド実行時のデータ(Enterprise, BH-pt)



博士論文発表

アプリケーション : Cube

Rubik’s Cubeパズルの近似解幅優先探索を行い、時々枝刈り (点数の高い

局面だけ残す ) 局面の重複を防ぐために、局面を二分木で

管理ヒープサイズ : 35MB固定

枝刈り

各局面オブジェクトは回転履歴リストを含む



60 スレッド実行時のデータ(Enterprise)

博士論文発表

性能評価 (1):Enterprise での GC 速度向上

( マークオブジェクト量 / マーク時間 ) の平均値を計測負荷分散なしでは全く台数効果は出ない 60 スレッドで 19—32倍の速度向上

BH- pt on E10K

0

10

20

30

40

0 20 40 60

number of processors

spee

d-up

Opt Simple Linear

BH- st on E10K

0

10

20

30

40

0 20 40 60


spee

d-up

Opt Simple Linear

Cube on E10K

0

10

20

30

40

0 20 40 60


spee

d-up

Opt Simple Linear

博士論文発表

性能評価 (2):Origin での GC 速度向上

Enterprise より速度向上は低い Origin でのみ、 BH-pt と BH-st の差が大きい

なぜ？原因を Part3 で解析

BH- pt on O2K

0

10

20

30

40

0 20 40 60


spee

d-up

Opt Simple Linear

BH- st on O2K

0

10

20

30

40

0 20 40 60


spee

d-up

Opt Simple Linear

13 倍7倍

Cube on O2K

0

10

20

30

40

0 20 40 60


spee

d-up

Opt Simple Linear

博士論文発表

関連研究

ストップ並列 GC [Halstead et al. 85]: 負荷分散なし [Uzuhara 90] [Imai et al. 93]: 負荷分散を行うが、

ボトルネック除去が不完全 [Flood et al. 01] 負荷分散、ボトルネック除去。 Copy GC と mark-compact GC の並列化

博士論文発表

Part2 のまとめ

スケーラブルなストップ並列マークスイープ GCの構築負荷分散とボトルネックを除去する最適化 Enterprise 10000 60 スレッドで 19—32倍の台数効果

Origin 2000 64 スレッドで 7—20倍の台数効果

Part 3:ストップ並列 GC の性能モデル

( コンピュータソフトウェア掲載 , IPDPS2001 で発表 )

博士論文発表

メモリアーキテクチャの GC性能への影響

Part2 で、ストップ並列 GC の性能を計測 … SMP/DSM 間の性能差は何のため？

メモリレイテンシ？バスバンド幅？アーキテクチャを考慮した、定量的な解析を行いたい

GC の性能モデルを提案、性能予測器を構築

考えられる応用 : 未知のマシンでの性能評価オンライン最適化への利用 ( 論文参照 )

博士論文発表

性能予測器の特徴

スケーラビリティを低下させる以下の事項を考慮並列化によるキャッシュミス増加メモリノードへのアクセス衝突コスト

オブジェクト配置のばらつきができうる DSM で重要

CPU

cache

CPU

cache

CPU

cache

memory memory memory

CPU

cache

memory

CPU

cache

memory

CPU

cache

memory

Enterprise 10000 (SMP) Origin 2000 (DSM)

博士論文発表

性能予測器の概要 (1)

入力 : GC 対象のヒープスナップショット出力 : P スレッドでの並列 GC 時間の予測値

1. ヒープスナップショットに擬似マーク処理を行う Live オブジェクト量、メモリアクセスパターンを記録

2. 1 スレッド実行での CPU 時間、キャッシュミス数を見積もる

CPU 時間 ← Live オブジェクト量に比例キャッシュミス数 ← メモリアクセスパターン + キャッシュシミュ

レータ

3. 次ページへ

博士論文発表

性能予測器の概要 (2)

逐次時並列時

CPU 時間

キャッシュミス数

キャッシュミスコスト

T1 TP

Q1 QP

M1MP

TPM

TPM = TP + QPMP/P

予測並列 GC 時間

MVA

生存キャッシュライン解析

ヒープスナップショットから

• 本説明ではキャッシュミス = メインメモリアクセス• 実際には一次 /二次キャッシュ、 TLB を考慮

論文訂正 : 4.3.1 最終行× TP

M = TP + QPMP

○ TPM = TP + QPMP / P

博士論文発表

モデルが仮定する事項各オブジェクトがどのスレッドによりマークされるかは

ランダム 1/Pの確率でローカルメモリアクセス

アクセス要求はメモリノードでのみ衝突ネットワーク途中での衝突を無視 (cf. LoPC モデル [Frank et

al.97]) キャッシュ無効化の影響を無視

アクセス要求は常に CPU→ Mem→ CPU 参照カウント 2 以上のオブジェクトは非常に少量

グラフのほとんどの個所が合流のない木構造と仮定仕事移動自体のコスト、終了判定コストを無視

博士論文発表

並列時のミス数見積もり (1)逐次実行並列実行

PE1PE1PE2PE3

逐次実行では連続だった仕事が、並列実行では別スレッドによるかもしれない → ミス数の増加

A

B

A

B

博士論文発表

並列時のミス数見積もり (2)

並列時のキャッシュミス数の見積もり :QP = Q1 + ( タスクスチール数 ) * (平均生存キャッシュライン数 )

逐次実行 Q1 = 4

キャッシュライン

並列実行 QP = Q1+4=8キャッシュミス

キャッシュヒットキャッシュライン寿命

今のところ経験則P log(#live-objects)

ヒープスナップショットから取得

博士論文発表

実験結果 : 実測と予測の比較BH-st Cube

RealPred (full)Pred (no contention) Pred (no miss incr.)

BH(DSM) ではアクセス集中が最大原因 Cube ではミス数増加が最大原因予測誤差は 7%—38%

O2000DSM

0

10

20

30

40

50

0 10 20 30 40 50# of processors

GC

spe

ed-u

p

0

10

20

30

40

50

0 10 20 30 40 50# of processors

GC

spe

ed-u

p

E10000SMP

0

10

20

30

40

50

0 10 20 30 40 50# of processors

GC

spe

ed-u

p

0

10

20

30

40

50

0 10 20 30 40 50# of processors

GC

spe

ed-u

p

博士論文発表

関連研究 LogP モデル [Culler et al. 93]

latency, overhead, gap(bandwidth), #processor LoPC モデル [Vernon et al. 97]

active message の文脈でのアーキテクチャモデルメッセージ衝突のコストを考慮

Portable Parallel Memory [Frigo 99] 一般の不規則プログラムの性能モデルミスコスト一定を仮定 ← underestimate 並列ミス増を ( ライン数 x steal 回数 ) と見積もり

← overestimate

博士論文発表

Part3 のまとめ

並列 GC 実行時間を見積もるモデルを提案ヒープスナップショットから、 Pスレッドでの実行時間見積り

スケーラビリティを制限する以下の要素を考慮オブジェクトグラフの幅不足 ( 論文参照 ) 並列化によるキャッシュミス増加メモリノードでのアクセス衝突コスト

GC スレッド数の自動調整 ( 論文参照 ) 今後の仕事

モデルの改良 ( タスクスチール回数の正当な見積もりなど ) 高速かつ正確な予測器の構築

Part 4並行並列 GC

博士論文発表

並行並列 GC

リアルタイム性の必要なアプリケーションでは、 GC による停止時間が問題 → 並行 GC が望ましい

アプリケーションのスケーラビリティを落とさないためには？

GC とプログラムが同時に動き、 GC 自体も並列

並行並列 GC

ユーザ GC

博士論文発表

並行並列 v.s. ストップ並列

並行並列 GC の利害得失 :○ 停止時間の短縮× ライトバリアのオーバヘッド× 解放量 / GC仕事量比の悪化○ ひまプロセッサの GCへの利用可○ メモリへのアクセス集中緩和

プログラム速度低下

プログラム速度向上

影響最大

博士論文発表

並行並列 GC アルゴリズム

Mostly parallel GC[Boehm 91] の並列化負荷分散あり

Incremental update アルゴリズム [Dijkstra 78] に基づく実験では、終了フェーズの停止時間と全実行時間を測定

GC cycle

開始フェーズ終了フェーズ

GC cycle


今回実装した並行並列 GC

並行フェーズ

博士論文発表

ライトバリアの必要性

ユーザによるオブジェクト書き込みを GCへ知らせるマーク漏れを防ぐため

root

heap

root

heap

root

heap

root

heap

root

heap

root

heap

Incremental update アルゴリズムの流れ• 開始フェーズ : ルートをマークスタックへ• 並行フェーズ : 少しづつマーク• ユーザ : 書き込んだオブジェクトをGCへ通知• 終了フェーズ :

[A] 書き込みがあったオブジェクト[B] ルート

から再マーク ( ストップ並列マーク )ただし原理的に [A] は前倒し可 ( 論文参照 )

博士論文発表

ライトバリアの実装

2 種類のライトバリアを実装仮想メモリ機構のページ保護を利用

○ コンパイラの協力不要○ GC 中のみオーバヘッドがかかる× 保護コストはマルチプロセッサで大

コード挿入コンパイラの代わりに、アプリケーションコードに手作業で挿入

博士論文発表

性能評価 (1): 停止時間

ストップ並列 GC と、並行並列 GC(VM利用版 ) を比較 E10000 8 スレッドにおいて最も効果が高く、 1.7—3.2倍の短縮それ以上では、ストップ並列の方が相対的に速度向上しやすい

BH-pt Cube

O2K

E10K

0

100

200

300

400

0 20 40 60# of threads

paus

e ti

me

(ms) Stop avg.

Stop max.Conc avg.Conc max.

0

100

200

300

400


paus

e ti

me

(ms) Stop avg.


CKY

0200400600800

100012001400


paus

e ti

me

(ms) Stop avg.


0

100

200

300

400

500


paus

e ti

me

(ms) Stop avg.


0200400600800

10001200140016001800


paus

e ti

me

(ms) Stop avg.


0

100

200

300

400

500


paus

e ti

me

(ms) Stop avg.


0

20

40

60

80

100

120


paus

e ti

me

(ms) Stop avg.


0

50

100

150

200


paus

e ti

me

(ms) Stop avg.


0

20

40

60

80

100


paus

e ti

me

(ms) Stop avg.


020406080

100120140160


paus

e ti

me

(ms) Stop avg.


0

50

100

150

200

250


paus

e ti

me

(ms) Stop avg.


0

50

100

150

200


paus

e ti

me

(ms) Stop avg.


BH-pt Cube

O2K

E10K

CKY

博士論文発表

性能評価 (2): 実行時間

並行並列 GC はストップ並列 GC に比べ、同等または遅い (最悪 1.9倍 ) VM を使った並行並列はスレッドが増えるほどオーバヘッド大コード挿入の場合はスレッドが多いときに VM に勝つ

O2K

E10K

BH-pt CubeCKY

0

0.5

1

1.5

1 8 16 32 48 60# of threads

Nor

mal

ized

Exe

cutio

n T

ime

Stop

Conc-VM

Conc-Soft

0

0.5

1

1.5

1 8 16 32 48 60# of threads

Nor

mal

ized

Exe

cutio

n T

ime

Stop

Conc-VM

0

0.5

1

1.5

2

1 8 16 32 48 60# of threads

Nor

mal

ized

Exe

cutio

n T

ime Stop

Conc-VM

Conc-Soft

0

0.5

1

1.5

1 8 16 32 48 64# of threads

Nor

mal

ized

Exe

cutio

n T

ime

Stop

Conc-VM

Conc-Soft

0

0.5

1

1.5

1 8 16 32 48 64# of threads

Nor

mal

ized

Exe

cutio

n T

ime

Stop

Conc-VM

0

0.5

1

1.5

2

1 8 16 32 48 64# of threads

Nor

mal

ized

Exe

cutio

n T

ime

Stop

Conc-VM

Conc-Soft

博士論文発表

実行時間の考察並行並列化による GC コスト増加は見られるが、全体時間増加を説明するほどではない

ライトバリア頻度が高いほど全体時間が長い

ライトバリアのコストが最大要因

ストップ (VM)並行 (Soft)並行GC/ (%)全体 0.7 0.8 1.7

( / s)ライトバリア回 335 274KBH-pt/E10K

ストップ (VM)並行 (Soft)並行GC/ (%)全体 2.3 3.7 N/ A

( / s)ライトバリア回 496 N/ ACKY/E10K


( / s)ライトバリア回 767 42.3MCube/E10K

ストップ (VM)並行 (Soft)並行GC/ (%)全体 1.6 1.5 2

( / s)ライトバリア回 197 313KBH-pt/O2K

ストップ (VM)並行 (Soft)並行GC/ (%)全体 3.9 4.2 N/ A

( / s)ライトバリア回 213 N/ ACKY/O2K


( / s)ライトバリア回 499 47.1M

Cube/O2K

博士論文発表

関連研究

インクリメンタル GC/ 並行 GC[Steele 75] [Dijkstra 78] [Baker 78] [Yuasa 90] [Doligez 93] GC とユーザプログラムをインタリーブマルチプロセッサにおいて 1 スレッドが GC を行うと、スタベー

ション並行並列 GC [Cheng et al. 01]

並行並列コピー GC アルゴリズムの提案と性能評価 ML での実装、コンパイラによるライトバリア

→ 本研究よりもライトバリアの影響が小さい環境

博士論文発表

Part4 のまとめ

並行並列マークスイープ GC の構築実行時間・停止時間について、ストップ並列 GC と比較

停止時間の短縮ライトバリアのコストが実行時間に大きく影響

2 種類のライトバリアのオーバヘッド評価仮想メモリ版はコード挿入版よりスケーラビリティ低

今後の仕事 : ライトバリア効率化別アルゴリズム (Snapshot-at-beginning など ) との比較性能解析

GC仕事量 / 解放量の解析メモリアーキテクチャの影響の解析

博士論文発表

全体のまとめ

スケーラブルなメモリ管理モジュールにより、並列プログラムの性能向上が可能

1. メモリ管理処理自体の性能向上各スレッドからの要求を並列に処理する並列アロケータ (Part 1) 複数スレッドで協調的に GC 処理を行う並列 GC (Part 2, 4)

2. プログラムのメモリアクセス性能向上局所性を考慮したアロケータ　 (Part 1)

また、以下の点にも注目アロケータによるメモリ消費量 (Part 1) GC による停止時間 (Part 4)

博士論文発表

今後の仕事 :さらなる性能向上へ向けて

他アプローチとの融合 Region analysis 世代別 GC 参照カウントヒープ全体のスケーラブルな GC は依然必要

コンパイラの協力による最適化 Escape analysis → スレッド固有オブジェクト / 共有オブジェク

トの区別型情報、フロー解析などによるライトバリア除去

性能予測器の結果を利用した適応的 GC アルゴリズムマーク順序 /負荷分散方法の自動選択

博士論文発表

コメントお願いします

共有メモリ並列計算機上のスケーラブルな動的メモリ管理モジュール

Documents

Transcript of 共有メモリ並列計算機上のスケーラブルな動的メモリ管理モジュール

共有メモリ並列計算機上の スケーラブルな動的メモリ管理 モジュール

Documents

Transcript of 共有メモリ並列計算機上の スケーラブルな動的メモリ管理 モジュール

共有メモリ並列計算機上のスケーラブルな動的メモリ管理モジュール

Transcript of 共有メモリ並列計算機上のスケーラブルな動的メモリ管理モジュール