名古屋大学大学院工学研究科博士課程（前期課程）
修士学位論文
単一チップ・マルチプロセッサ SKY
におけるデータフローを考慮した
スレッド分割技法
平成 16 年 3 月
電気工学・電子工学・電子情報学専攻
山口 武
概要
非数値計算プログラムに対し，マルチスレッド実行により性能を向上させる単一チップ・
マルチプロセッサとして SKY が提案されている．SKY において大きな性能向上を達成する
には，コンパイラはプログラムを並列性の高いスレッドに分割する必要がある．非数値計
算プログラムでは，粒度の小さなスレッドレベル並列性（TLP: Thread-Level Parallelism）
を利用することが不可欠である．SKY ではノンブロッキングな同期／通信機構を使用する
ことで，細粒度の TLP を効率よく利用することができる．しかし従来のコンパイラではノ
ンブロッキングな同期／通信機構を考慮していないため，ハードウェアを十分に活用する
ようなスレッドに分割しているとはいえなかった．本論文では，SKY が備えるノンブロッ
キングな同期／通信機構を最大限に利用することで性能が向上するスレッドに分割できる
よう，データフローを考慮したスレッド分割技法を提案する．4 プロセッサ構成の SKY に
よる評価の結果，ノンブロッキングな同期／通信機構を考慮していない従来のスレッド分
割技法に対して，最大 13.4%ポイント，平均 4.5%ポイントの性能向上を得ることができた．
i
目次
1 はじめに
1
2 関連研究
2.1 マルチスレッド・アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . .
2.2 コンパイラによるスレッド分割 . . . . . . . . . . . . . . . . . . . . . . . .
4
4
6
3 SKY の概要
3.1 アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 コンパイラ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
10
4 従来の利得計算手法
4.1 従来手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 従来手法の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
14
5 データフローを考慮したスレッド分割技法
5.1 提案手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 利得計算をより正確にするための先行制約の追加 . . . . . . . . . . . . . .
16
16
19
6 評価
6.1 評価環境 . . . . . . . . . . . . . . . . . . . . . . .
6.2 データフローを考慮したスレッド分割技法の評価
6.2.1 静的なスレッド分割数 . . . . . . . . . . .
6.2.2 性能向上率 . . . . . . . . . . . . . . . . .
24
24
25
25
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 まとめ
35
A 利得の閾値の評価
36
B プロセッサ台数を変化させた場合の評価
38
C SKY 専用命令の動的な出現数
43
D 利得計算の計算時間
45
謝辞
47
ii
目次
参考文献
iii
48
第 1章
はじめに
スーパスカラ・プロセッサに代わるアプローチとして，近年，複数のプロセッサを単一
チップに集積するマルチプロセッサ（CMP: Chip MultiProcessor）が注目を集めている．
その背景には，単一制御流において利用可能な命令レベル並列性（ILP: Instruction-Level
Parallelism）が限界に近づきつつあるなど，スーパスカラ・プロセッサに対する悲観的観測
に加え，半導体回路技術の進歩にともない，複数のプロセッサの単一チップへの集積化が実
現可能なことがある．商用の CMP として Power4 [5]，Power5 [7, 8]（IBM），UltraSPARC
IV [15]（SUN），SPARC64 VI [16]（Fujitsu）などが発表されている．これらは，複数の
プログラムの同時実行や，オンライン・トランザクションといった特定の処理の高速化 [3]
を目的としている．
これに対し，1 つのプログラムをスレッドに分割し並列実行することで性能を向上させ
る研究が行われている [22, 21, 19, 10, 13]．CMP はプロセッサ間通信のレイテンシを減少
させることができるという特徴があるため，粒度の小さなスレッドレベル並列性（TLP:
Thread-Level Parallelism）を利用することができる．このため，粒度の大きな TLP が少な
い非数値計算プログラムの高速化が期待できる．
細粒度の TLP を効率よく利用するためには，CMP の特徴を活かした同期／通信機構が
必要である．そこで，レジスタ値を直接通信し，同期を行う機構 [21, 22] が提案された．こ
れは，マルチプロセッサで一般的なメモリを介して同期／通信を行う機構に比べ，オーバ
ヘッドを大幅に減少させることができる．しかし，この同期／通信機構にはまだ改善の余
地がある．なぜならば，同期が成立しなかった命令が現れたとき，その命令が受信待ちで
停止するのに加え，それに後続する命令の実行も停止するからである．これは，要素プロ
セッサとしてアウト・オブ・オーダ実行のスーパスカラ・プロセッサを前提とした場合，ILP
1
第 1 章 はじめに
2
の利用を阻害しているといえる．この問題に対し，同期が成立しなかった命令が現れても，
その命令とデータ依存関係にない後続命令の実行を停止させない，ノンブロッキングな同
期／通信機構 [14] が提案された．これにより，ILP と TLP の両方をハードウェアは十分に
引き出すことができる．
マルチプロセッサで大きな性能向上を得るには，コンパイラはプログラムを並列性が大
きいスレッドに分割しなければならない．数値計算プログラムに対しては，ループレベル
並列化（例えば Polaris [6] や SUIF [9]）で大きな性能向上を達成している．しかし，一般
に非数値計算プログラムは内在する並列性が乏しい上，制御構造が複雑で不規則なデータ
依存が多いため，この手法は有効に働かないと考えられる．
非数値計算プログラムのこのような性質から，大きな性能向上が得られるスレッドに分
割するには，より細かな基本ブロック・レベルでの制御依存解析と命令レベルでのデータ
依存解析が必要である．特に乏しい並列性を余すことなく利用するためには，データ依存
解消のタイミングまでをも考慮した解析に基づく，性能向上の正確な見積もりが要求され
る．このような要求に対し，いくつかの研究がなされているが [24, 11]，依然としてノンブ
ロッキングな同期／通信機構が影響を与える動的命令スケジューリングを考慮していない
ため，性能向上を正確に見積もることができない．
本論文では，スレッド間データ依存の他に，スレッド内のデータフローも詳細に解析し，
命令がどのように動的スケジューリングされるかを考えることで，ハードウェアを有効利
用して性能を向上させるスレッドへの分割技法を提案する．プログラムのスレッドへの分
割は様々な方法が考えられるが，本論文では SKY コンパイラ [11] において本提案手法を
適用する．
2 章では関連研究について述べる．3 章では，本研究の対象となる SKY のアーキテクチャ
およびコンパイラについて述べる．4 章では SKY でのスレッド分割技法における性能向上
の見積もり方法（これを利得計算と呼ぶ）について述べる．5 章では本論文における提案
手法である，データフローを考慮したスレッド分割技法について述べる．6 章で評価を行
3
い，7 章でまとめる．
第 2章
2.1
関連研究
マルチスレッド・アーキテクチャ
CMP はプロセッサ間通信レイテンシを減少させることができるため，TLP を効率よく
引き出すことができる．そのため，CMP を利用したマルチスレッド・アーキテクチャの研
究が広く行われている．
Olukotun らは，単純なスーパスカラ・プロセッサで構成される CMP と，同一のチップ
面積で広い命令発行幅を持つ単一のスーパスカラ・プロセッサの性能比較を行った [19]．非
数値計算プログラムにおける IPC の評価では，CMP は単一のスーパスカラ・プロセッサ
より 10∼30%性能が低いという結果であった．しかし，CMP は単純なスーパスカラ・プロ
セッサを用いているので，高いクロック周波数を実現でき，その結果性能差はなくなると
述べている．
Hammond らは，Hydra と呼ぶアーキテクチャを提案した [10]．これは，従来型のマル
チプロセッサを拡張し，非数値計算分野に適用することを目的としている．Hydra では，ソ
フトウェアによりスレッド管理を行う必要があるため，スレッド生成・終了に必要なオー
バヘッドが大きい．また，スレッド間の通信がメモリを介して行われるため，同期／通信
で生じるオーバヘッドも大きい．これらから，粒度の小さいスレッドの並列性を利用する
ことが難しいといえる．
Sohi らは，逐次的にスレッドを生成し，レジスタ通信を行う Multiscalar と呼ぶアーキ
テクチャを提案した [21]．レジスタ通信は，メモリを介さずに，レジスタ・ファイル間で
行われる．スレッドの分割，レジスタ値の送信はコンパイラの支援により行う．スレッド
が送信するレジスタ，および受信するレジスタはコンパイラが指定する．送信側では指定
されたレジスタに書き込みが起こると，後続のプロセッサのレジスタ・ファイルに値が送
4
2.1. マルチスレッド・アーキテクチャ
5
られる．受信側のプロセッサでは，コンパイラが指定したレジスタが未受信の場合で，そ
のレジスタを使用する命令は，プロセッサは実行を停止し受信を待ち合わせる．
鳥居らは，非常に少ないサイクル数ですべてのレジスタの内容をコピーできる特別なレ
ジスタ・ファイルを持つ MUSCAT（MUlti-Stream Control ArchiTecture）と呼ぶアーキ
テクチャを提案した [22, 17]．レジスタ・ファイル間に高いバンド幅を実現することにより，
スレッド間通信のオーバーヘッドを小さくした．しかし，スレッド生成後に定義されたレ
ジスタ値についてはメモリを介して同期／通信を行う必要があり，このオーバヘッドは削
減されていない．
上記のものとは異なり，単一のプロセッサでマルチスレッド実行を実現している研究が
ある．この方法は利用可能な資源が単一プロセッサ分に限られるため，複数のプロセッサ
を集積した CMP ほど TLP を利用することはできない．しかしプロセッサ内の資源の利用
効率を上げることができるという特徴がある．
Tullsen らは，単一のスーパスカラ・プロセッサにおいて，命令レベルで複数のスレッド
を実行する SMT（Simultaneous MultiThreading）と呼ぶ方式を提案した [23]．SMT は，
豊富な機能ユニットを持つスーパスカラ・プロセッサにおいて，複数のプログラムを命令
レベルで同時に実行することにより，プロセッサのスループットを向上させることができ
る．しかし，SMT だけでは，1 つのプログラムの実行時間を短縮することはできない．
Akkray らは，コンパイラを用いず，動的にプログラムをスレッドに分割し，並列実行を
行う DMT（Dynamic MultiThreading）と呼ぶアーキテクチャを提案した [2]．DMT は動
的にループや関数を発見してスレッドに分割し，それを SMT プロセッサ上で並列実行す
る．スレッド並列実行時に発生するスレッド間データ依存について，レジスタに関する依
存については，値予測を行うことにより解消を行う．スレッド間のメモリに関する依存に
ついては，依存がないものとして投機的に実行を行う．DMT はスレッド分割にコンパイラ
を用いていないため，明らかに通信を行った方が良い箇所についても値予測を行わなけれ
ばならないという欠点がある．またあるスレッドが複数の後続スレッドを生成することを
第 2 章 関連研究
6
許すため，スレッド並列実行の機会が増加するという利点がある反面，スレッド管理が複
雑であるという欠点がある．
2.2
コンパイラによるスレッド分割
マルチスレッド・アーキテクチャで大きな性能向上を達成するためには，コンパイラは
プログラムを並列性が大きいスレッドに分割しなければならない．数値計算プログラムに
対しては，ループレベル並列化 [6, 9] によって並列性を引き出すことができる．
しかし，非数値計算プログラムは，数値計算プログラムと比べてループレベル並列性が
少ない [12] 上，制御構造が複雑で不規則なデータ依存関係が多い．このため，スレッドに
分割することで性能向上を得るためには，基本ブロック・レベルの制御依存解析と，命令
レベルのデータ依存解析が必要であると考えられる．また，並列に実行するスレッド間で
生じるデータ依存が多いため，この同期／通信にかかるコストが性能に与える影響を無視
することはできない．そこで，データ依存解消のタイミングまでをも考慮した解析に基づ
いて性能向上を正確に見積もり，性能向上が期待されるように分割する必要がある．
Vijaykumar らは，Multiscalar において基本ブロック・レベルのスレッド分割を行うこ
とにより，並列性を引き出すことが可能であることを示した [24]．彼らの手法では，まず
スレッドを単一の基本ブロックを基準とし，スレッドの大きさ，スレッド間制御依存，ス
レッド間データ依存を考慮しつつスレッドを拡大していく．スレッド間データ依存について
は，データ依存の発生頻度に着目している．これは，スレッド間で生じる通信の頻度が少
ないスレッドは性能向上が大きいと見積もっていると考えることができる．発生頻度の高
いデータ依存関係にある命令は同じスレッド内に含まれるようにスレッド分割を行う．そ
のような分割ができない場合は，スレッド間データ依存による待ち合わせが少なくなるよ
うに，値を定義する命令が属する基本ブロックをスレッドの開始点となるように分割する．
しかし，一般にデータ依存関係は非常に多いので，スレッド間データ依存をなくすことは
ほとんどできない．また，依存解消のタイミングによってはスレッド間通信は性能に影響
2.2. コンパイラによるスレッド分割
7
を与えない．すなわち，依存の発生頻度と性能向上は直結しない．これから発生頻度だけ
では性能向上の見積もりが正確でないといえる．
第 3章
SKY の概要
本章では，本論文において評価対象とする SKY の概要について述べる．まず SKY のアー
キテクチャ[14] について説明する．次に SKY コンパイラにおけるスレッド分割技法 [11] に
ついて述べる．
3.1
アーキテクチャ
はじめに，マルチスレッド・モデルについて述べる．スレッド並列実行のオーバヘッド
を小さくするため，SKY のマルチスレッド・モデルは通常のマルチスレッド・モデルと比
べて次に示す制約を課している．これは，Multiscalar や MUSCAT で採用されているモデ
ルと同様である．
• 各スレッドは，逐次実行における動的に連続する部分で構成される．
• 各スレッドは，逐次実行の順における自身の直後のスレッドを逐次生成する．
図 3.1(a) に逐次実行命令列を，図 3.1(b) にこれに対する SKY におけるスレッド分割の
様子を示す．同図に示すように，SKY における各スレッドは，動的な命令列における単一
の連続した部分からなり，異なる複数の部分からは構成されない．したがって，スレッド
に結合はなく，制御に関する同期は必要ない．
図 3.1(b) に示したスレッドを並列に実行する様子を，図 3.1(c) に示す．図 3.1(b) におい
て，各スレッドに T0 ，T1 ，T2 と逐次実行の順に名前をつける．図 3.1(c) に示すように，ス
レッド Ti は実行途中で，スレッド Ti+1 を生成するという逐次生成を繰り返す．このように
新たにスレッドを生成することをフォークという．実行のできるだけ早い時期にフォーク
することにより，スレッドの並列実行を実現する．スレッドの生成は，fork と呼ぶ専用の
8
3.1. アーキテクチャ
9
T0
プロセッサ０
プロセッサ１
プロセッサ２
fork
T0
fork
T1
T1
T2
finish
finish
finish
T2
(a) プログラムの
動的な命令列
(b) スレッド
(c) スレッド生成
図 3.1: SKY のマルチスレッド・モデル
命令を用い，終了は finish と呼ぶ専用の命令を用いて行う．以下，Ti+1 を Ti の子スレッ
ドと呼び，Ti を Ti+1 の親スレッドと呼ぶ．また fork 命令を挿入する位置をフォーク点，
finish 命令を挿入する位置を子の開始点と呼ぶ．
次に，ハードウェア構成について述べる．SKY を構成する各プロセッサは，単方向のリ
ング・バスで結合される．各プロセッサは従来のスーパスカラ・プロセッサとなっており，
スレッド内の命令レベル並列性を引き出す．機能ユニット，命令ウィンドウ，レジスタ・
ファイルなどはそれぞれ独立に持っている．メモリは各プロセッサで共有する．命令キャッ
シュ，データキャッシュも共有である．4 プロセッサの構成を図 3.2 に示す．プロセッサ i は
プロセッサ i + 1(modn) にのみデータを送り，プロセッサ i − 1(modn) からのみデータを
受け取る．以下，プロセッサ i + 1(modn) をプロセッサ i の後続プロセッサ，プロセッサ
i − 1(modn) をプロセッサ i の先行プロセッサと呼ぶ．
SKY は細粒度の TLP を利用するため，send と呼ぶ専用命令を使用してプロセッサ間で
レジスタ値を直接通信し，同期／通信のオーバヘッドを 2 サイクルまで減少させている．ま
た，命令ウィンドウ・ベースの同期と呼ぶ同期機構を導入している．この機構は，命令ウィ
第 3 章 SKY の概要
10
命令キャッシュ
プロセッサ0
プロセッサ1
リング・バス
プロセッサ3
プロセッサ2
データキャッシュ
図 3.2: SKY の構成（4 プロセッサ）
ンドウで受信値に対応するタグを用いてレジスタに関する同期をとる機構であり，ノンブ
ロッキングな同期を実現している．この機構により，同期のために後続命令の実行がブロッ
キングされることなく，プロセッサは ILP を効率よく利用することができる．
3.2
コンパイラ
コンパイラが行うスレッド分割の処理について，全体の流れを図 3.3 に示す．最初にス
レッド分割に必要な，分岐プロファイル等の情報を得るために前処理を行う．次に実際の
スレッド分割に入る．分割はプログラム内の関数ごとに行う．スレッド分割は具体的には，
フォーク点 f ，子の開始点 c，レジスタ通信集合 Comm，利得 g を求めることである．
これらの値及び集合の組 （f,c,Comm,g） を分割情報と呼び，その集合を F とする．以
下に F を求める手順を説明する．
まず，ある関数の中で制御等価 [20] な基本ブロックの組の集合 B を抽出する．ここで，
制御等価とは以下のものである．一般に，制御フロー・グラフにおいて，入口ノードから
基本ブロック Y へ向かうどの経路も基本ブロック X を通るとき，X が Y を支配 [1] する
3.2. コンパイラ
11
前処理;
各関数について{
制御等価な基本ブロックの組の集合 B を求める;
B の各要素について{
フォーク点 f, 子の開始点 c を求める;
レジスタ通信集合 Comm を求める;
利得 g を求める;
利得 g が閾値よりも大きいならば分割情報の集合 F に加える;
}
分割情報の集合 F の中から選択する;
}
命令挿入;
図 3.3: コンパイラの処理の流れ
といい，X から出口ノードに向かうどの経路も Y を通るとき，Y は X を後支配するとい
う．組（X,Y）が制御等価とは，X が Y を支配し，同時に Y が X を後支配することをいう．
フォーク点と子の開始点を含む基本ブロックをそれぞれ X，Y とすると，SKY のマルチス
レッド・モデルでは，Y は X を後支配しなければならない．しかし Y が X を後支配する
組は数が非常に多いので，現実的な計算量で分割するために，制御等価な組をスレッド分
割の候補とする．図 3.4 の制御フロー・グラフにおいて，制御等価な基本ブロックの組は
{(1, 4), (4, 7), (1, 7)} である．
次に抽出されたすべての基本ブロックの組について，フォーク点 f ，子の開始点 c を求め
る．f ，c は，基本ブロックの先頭とする．
次にレジスタ通信集合 Comm を求める．各レジスタに関する send 命令の挿入位置は，
送るべきレジスタ値が子の開始点に到達する [1] ことが決定する点とする．
最後に利得 g を求める．これは，注目しているスレッド分割を選択することによって期
待される性能向上の見積もりを示す．計算方法の詳細は 4 章で述べる．利得があらかじめ
定められた閾値より大きい場合，分割情報（f,c,Comm,g）を F に加える．
このようにして F を作った後，F の中から SKY のマルチスレッド・モデルにおいて利
得が最大となるような分割情報の組合せを選ぶ．その後，選択された分割情報にしたがっ
第 3 章 SKY の概要
12
1
2
3
4
5
6
7
図 3.4: 制御等価
て fork，finish，send の各命令を挿入する．
第 4章
従来の利得計算手法
SKY におけるスレッドへの分割方法では，性能向上の見積もりである利得が重要である．
なぜならば，利得を正確に計算しなければ，性能向上に寄与する分割情報を選択できない
ためである．そこで，本論文では利得計算に注目した．
本章では，まず従来の利得計算方法について説明し，次にその問題点について述べる．
4.1
従来手法
利得とは，スレッド並列実行によってオーバラップして実行された命令数である．オー
バラップ実行される命令数は通る経路によって異なる．そこで，あるスレッド分割の利得
は，フォーク点から子の開始点を経由し，関数の出口に至るまでのすべての経路について，
それぞれの経路でオーバラップ実行される命令数をその経路を通る確率で重み付けした期
待値として計算する．
SKY コンパイラでは，オーバラップ実行される命令数を命令間の距離という基準で計算
する．ここで，命令 a から命令 b までの距離とは，命令 a から命令 b に至るまでのすべて
の経路について，それぞれの経路に存在する命令数をその経路を通る確率で重み付けした
期待値である．経路を通る確率は分岐のプロファイルから得る．利得計算では以下の 3 つ
の距離を計算する．
• フォーク距離
• スレッド間レジスタ依存距離
• スレッド間メモり依存距離
以下にそれぞれの距離の計算方法を述べる．
13
第 4 章 従来の利得計算手法
14
フォーク距離は，ある分割におけるフォーク点から子の開始点までの距離である．
レジスタ依存距離とは，あるレジスタ依存に関して値を定義する命令とその値を使用す
る命令の間の距離を示す．スレッド間レジスタ依存距離は，ある分割によって発生するス
レッド間のレジスタ依存距離の期待値を示す．これは，フォーク点から子の開始点に至るす
べての経路毎にスレッド間で生じるレジスタ依存のレジスタ依存距離の最小値を求め，そ
の経路を通る確率で重み付けを行うことで求める．
スレッド間メモリ依存距離は，注目する依存がロード／ストア命令に関するメモリ依存
であること以外は，スレッド間レジスタ依存距離と同様に求める．
これらの距離のうち，最も小さい距離だけスレッドがスレッド並列実行によりオーバラッ
プして実行されると考える．よってその距離を利得とする．
4.2
従来手法の問題点
従来手法は，データ依存関係にある命令間の距離に着目しているため，同期の成立しな
かった命令が後続命令の実行を妨げる，逐次実行（インオーダ・1 命令発行）のプロセッサ
で構成されるマルチプロセッサでは，利得を正確に見積もることができる．しかし，スレッ
ド内の ILP を利用し，ノンブロッキングな同期／通信を行うマルチプロセッサに対しては，
利得を正確に見積もることができないという問題がある．これを図 4.1 を用いて説明する．
図 4.1(a) に，スレッドに分割する前のプログラムの命令列を示す．破線は命令間にデー
タ依存関係があることを示す．この命令列を命令 i3 と i4 の間でスレッドに分割する場合
の利得を計算することを考える．図 4.1(b) に，逐次実行のプロセッサで構成されるマルチ
プロセッサにおける実行例を示す．従来の距離に着目した方法では，上で述べたように図
4.1(b) のような状態を想定していることになる．その結果，命令 i3，i5 間で生じるスレッ
ド間データ依存が並列実行を制限し，利得はほとんどないと計算される．このため，この
スレッド分割は選択されない．これに対し，図 4.1(c) に，SKY における実行例を示す．ノ
ンブロッキングな同期／通信により，命令 i5 と依存関係にない命令 i6-i9 までは命令 i5
4.2. 従来手法の問題点
15
スレッド1 スレッド2
i1
i1
i2
i3
i4
スレッド1
スレッド2
i1
i4
i2
i2
i6
i3
i3
i7
分割点
i4
i5
i5
i6
i6
i7
i7
i8
i8
i9
i9
i8
i5
i9
(a) プログラム
(b) 逐次実行のプロセッサで構成される
マルチプロセッサでの実行
(c) SKYでの実行
図 4.1: 距離を用いた利得計算手法の問題点
よりも早く実行可能である．また，スレッド内の ILP を利用できるため，命令 i8，i9 は
それぞれ命令 i7，i4 と並列実行可能である．これから，従来の距離に着目した利得計算で
は，利得が少ないと計算され選択されないスレッド分割の中に，実際には性能向上に寄与
するものが存在するといえる．
以上に述べた従来手法の問題に対して，本論文ではスレッド内のデータフローを詳細に
解析し，スーパスカラ・プロセッサの行う動的命令スケジューリングを考慮した利得計算
手法を提案する．こうすることで，図 4.1(c) の命令 i6-i9 のような，並列性を有効利用可
能なハードウェアでのスレッド並列実行においてオーバラップ実行される命令を検出する
ことができる．この結果，利得計算が正確になり，性能向上に寄与するスレッドをより多
く検出することができる．
第 5章
データフローを考慮したスレッド分割技法
本章では，はじめに提案手法であるデータフローを考慮したスレッド分割技法について
述べる．これは性能向上の見積もり，すなわち利得を正確に計算するものである．次に利
得をさらに精度よく計算する方法について述べる．
5.1
提案手法
利得であるオーバラップ命令数は，fork 命令によって生成されたスレッド（子スレッド）
の命令のうち，親スレッドの実行が終了するまでに実行される命令数のことである．そこ
で，親スレッドの実行終了サイクルと子スレッドの各命令の実行サイクルを見積もること
で利得計算を行う．プロセッサの行う動的命令スケジューリングを考慮して実行サイクル
を見積もることで図 4.1(c) のように実行されることを利得に反映することができる．
実行サイクルの見積もりにはリスト・スケジューリング [4] を用いる．リスト・スケジュー
リングによる実行サイクルの計算では，命令に対応するノードと，命令の実行順序を決定す
る制約（これを先行制約と呼ぶ）を表すエッジからなる先行制約グラフ（PCG: Precedent
Constraint Graph）を使用する．図 5.1 に PCG の例を示す．この図において，各ノードは
命令を表し，ノードを結ぶエッジは先行制約を表す．ここでは，先行制約はデータ依存と
している．エッジに付けられたラベルは，そのエッジで制約されるノードに対応する命令
が課されるべき遅延（サイクル数）を表す．例えば，命令 i1 は命令 i0 が実行されてから
1 サイクル待たなければ実行できないことを意味する．
PCG において，ノードは先行制約がなくなり次第実行可能となり，機能ユニットが使用
可能な最も早いサイクルにおいて実行されると計算する．このようにして各命令の実行サ
イクルを見積もる．このアルゴリズムを図 5.2 に示す．この図において，READY とは，先行
16
5.1. 提案手法
17
先行制約 （データ依存）
i0
1
i1
i4
i3
1
i5
1
i2
2
1
i6
1
i7
図 5.1: 先行制約グラフ
ノードがないノードの集合の内，現在のサイクルにスケジュールできるノードの集合であ
り，LEADER とは，先行ノードがないノードの集合の内，現在のサイクルでは遅延の条件を
満たさず，スケジュールできないノードの集合である．図 5.1 の PCG では，このアルゴリ
ズムにしたがって，先行制約のない命令 i0，i3，i4 から順番に実行サイクルが計算される．
命令の実行サイクルを正確に計算するため，一般的なリスト・スケジューリングに以下
の変更を加えた．まず，通常の先行制約はデータ依存であるが，本手法ではデータ依存の
他にプロセッサの構成要素であるリオーダ・バッファ（ROB: ReOrder Buffer）とロード／
ストア・キュー（LSQ: Load/Store Queue）に関する制約を追加した（詳細は 5.2 節で述べ
る）．次に，各ノードの優先度の設定方法を変更した．通常のリスト・スケジューリングの
優先度はクリティカル・パス上の命令が高くなるように設定される．これは，リスト・ス
18
第 5 章 データフローを考慮したスレッド分割技法
READY = 先行ノードがないノードの集合;
current_cycle = スケジュール開始サイクル;
while (READYが空でない && LEADERが空でない) {
foreach ノードn in READY (優先度が高い順に) {
current_cycleにnのスケジュールを試みる;
if (成功) {
PCGよりnを削除する;
READYとLEADERを更新する;
}
}
current_cycle++;
READYとLEADERを更新する;
}
図 5.2: リスト・スケジューリング
ケジューリングの目的が実行時間が短い最適なプログラム順の生成であるからである．し
かし，一般にプロセッサの動的命令スケジューリングではプログラム順に優先度が付けら
れるため，本手法でも同様に各ノードの優先度をプログラム順に設定することとした．
利得計算の手順を以下に示す．以下の説明において，親スレッドとは利得計算対象のス
レッド分割のフォーク点から子の開始点まで，子スレッドとは子の開始点以降のことを表す．
利得計算は各スレッド分割のフォーク点から子の開始点を経由し，関数の出口に至るま
での経路毎に行う．計算対象の経路について，親スレッドの PCG を作成し，親スレッドの
実行終了サイクル，send 命令の実行サイクル，ストア命令がデータをメモリに書き込むサ
イクルを計算する．send 命令の実行サイクルとストア命令の書き込みサイクルは，スレッ
ド間データ依存を満足するよう子スレッドの命令をスケジューリングするために使用する．
次に，子スレッドの PCG を作成し，子スレッドの各命令の実行サイクルを計算する．こ
のとき，スレッド間レジスタ依存がある命令は，当該レジスタが親スレッドの send 命令に
よって送信され，子スレッドで受信するサイクルまで実行できないとすることで，スレッ
ド間レジスタ依存を満足させる．また，スレッド間メモリ依存がある命令は，親スレッド
の依存関係にあるストア命令がメモリにデータを書き込むサイクルまで実行できないとす
ることで，スレッド間メモリ依存を満足させる．子スレッドのある命令について実行され
5.2. 利得計算をより正確にするための先行制約の追加
19
るサイクルが親スレッドの終了サイクルよりも早い場合，その命令はオーバラップ実行さ
れるとする．子スレッドでまだ実行されていないどの命令も親スレッドの終了サイクル以
前に実行できないことがわかった時点で計算を終了し，それまでにオーバラップ実行され
た命令数を数える．これをすべての経路について行い，各経路を通る確率で重み付けした
期待値をそのスレッド分割の利得とする．
5.2
利得計算をより正確にするための先行制約の追加
命令の実行サイクルを決定する要因はデータ依存と機能ユニットだけではない．プロセッ
サの他の構成要素も先行制約として加味することで，利得を実際にオーバラップ実行され
る命令数にさらに近づけることができると考えられる．本論文では，命令が実行されるサイ
クルに大きな影響を与えると考えられる ROB と LSQ に関する先行制約を追加した．これ
らをそれぞれ，ROB 制約と LSQ 制約と呼ぶ．ROB に注目した理由は，動的にスケジュー
リングできる命令の範囲が命令ウィンドウ内に限られており，これが ROB のエントリ数
で制限されるためである．LSQ については，ロード命令の実行には真のメモリ依存の他に，
保守的なメモリ曖昧性除去による偽のメモリ依存が影響するためである．
命令は ROB のエントリが割り当てられないと実行不可能である．ROB のエントリはプ
ログラム順に割り当て，実行が終了した命令からプログラム順に解放する．ROB に空きエ
ントリがない場合，ROB のエントリが割り当てられている命令の中で，プログラム順で最
も古い命令がリタイアするまで，ROB に新たな命令を割り当てることはできない．すなわ
ち，あるノードに対する ROB 制約とは，ROB に空きエントリがない場合において，ROB
内の命令の中でプログラム順で最も古い命令がリタイアするまで実行できないというもの
である．このような状況において，ある命令に対してプログラム順で最も古い命令とは，
ROB のエントリ数分前の命令である．これは，全命令に対しプログラム順に番号をつける
ことで計算可能である．n 番目の命令を in とすると，命令 in に対する先行制約となるの
は命令 in−#ROB （#ROB ：ROB のエントリ数）のリタイアである．実行サイクルの計算
第 5 章 データフローを考慮したスレッド分割技法
20
ROB制約
1
i0
i3
1
1
i1
i4
1
1
i2
i5
1
2
1
1
i6
1
i7
図 5.3: ROB 制約を追加した先行制約グラフ
時に，リタイアする命令の番号を得ることによって ROB 制約を考慮した．図 5.1 の PCG
に，ROB のエントリ数を 4 とした場合における ROB 制約を追加したものを図 5.3 に示す．
この図において，破線の矢印が ROB 制約を表す．エントリ数が 4 であるので，例えば命令
i4 の先行制約となるのは命令 i0 のリタイアとなるようにエッジをつける．
LSQ を使用する場合，ロード／ストア命令はアドレス計算部とメモリ・アクセス部とに
分離され別々にスケジューリングされる．そこで，ロード／ストア命令を PCG に追加する
ときに，アドレス計算部とメモリ・アクセス部の 2 つのノードに分ける．これによりアド
レス計算部とメモリ・アクセス部を別々にスケジューリングすることを考慮できる．また，
5.2. 利得計算をより正確にするための先行制約の追加
21
LSQ制約
i0
1
i4
1
i1
i3a
1
i5a
i3s
1
1
i2a
1
1
1
1
i2s
i5l
1
i6
1
i7
図 5.4: LSQ 制約を追加した先行制約グラフ
ロード命令は先行するストア命令の実効アドレスがすべて判明するまで実行できないこと
から，ロード命令のメモリ・アクセス部に対応するノードの先行制約として，真のデータ
依存の他に，先行ストア命令のアドレス計算部が実行完了するまで実行できないという制
約を加える．上記 2 点の変更によって，LSQ 制約を考慮した．図 5.1 の PCG に，命令 i2，
i3 がストア命令，i5 がロード命令である場合における LSQ 制約を追加したものを図 5.4 に
示す．この図において，1 点破線が LSQ 制約を表す．上記の命令はノードを 2 つに分ける．
図中の i2a，i3a，i5a と示したノードがアドレス計算部を示す．保守的なメモリ曖昧性除
去による偽の依存を考慮するため，ロード命令のメモリ・アクセス部（i5l）と i2a，i3a
第 5 章 データフローを考慮したスレッド分割技法
22
ROB制約
LSQ制約
1
i3a
i0
1
1
i1
1
1
1
i5a
i4
i3s
1
i2a
1
1
1
i2s
i5l
1
1
1
1
i6
1
i7
図 5.5: ROB 制約と LSQ 制約を追加した先行制約グラフ
の間にエッジをつける．
図 5.1 の PCG に，ROB 制約と LSQ 制約を追加したものを図 5.5 に示す．LSQ を考慮す
るときにロード／ストア命令に対応するノードを 2 つに分けることにより，ROB 制約の加
え方に修正が必要となる．ROB 制約によって実行の制約を受ける命令がロード／ストア命
令である場合，そのアドレス計算部が制約を受けるようにエッジをつける．メモリ・アク
セス部はアドレス計算部の実行終了が先行制約となっているため，このノードに制約を加
える必要はない．逆に，ROB 制約によって実行を制約する命令がロード／ストア命令であ
る場合，そのメモリ・アクセス部が制約を課すようにエッジをつける．これは，ロード／
5.2. 利得計算をより正確にするための先行制約の追加
23
ストア命令を 2 つのノードに分けているが，プロセッサ内では ROB のエントリは 1 つしか
割り当てられず，アドレス計算部は単独ではコミットできないためである．
第 6章
評価
本章ではまず，評価環境について述べる．その後，データフローを考慮した利得計算を
用いてスレッド分割を行った場合の評価結果を示す．
6.1
評価環境
ベンチマーク・プログラムとして，SPECint95 の全 8 種を使用した．使用したベンチマー
ク・プログラムとその入力セットおよび命令数を表 6.1 に示す．この表において，プロファイ
ル用の入力はコンパイラがスレッド分割時に使用したものを，シミュレーション用の入力は
評価に使用したものを示す．ベンチマーク・プログラムのバイナリは，GNU GCC Version
2.7.2.3（コンパイル・オプション: -O6 -funroll-loops）を用いて作成した．評価はトレース
駆動シミュレータを用いて行った．トレースは SimpleScalar Tool Set Version 3.0 を利用し
て採取した．
表 6.2 に SKY の基本モデルを示す．性能比較における基準プロセッサは，SKY を構成す
る 1 つのプロセッサとした．表 6.3 に，各ベンチマークにおける基準プロセッサの IPC を
示す．SKY のプロセッサ数は 4 とした1 ．
スレッド分割を生成する際に使用した利得計算手法が，距離を用いたものを DIST，提案
手法において先行制約がデータ依存のみ，すなわち PCG がデータフローを表すものを DF
とした．また，DF において ROB 制約を考慮したものを DF w/ R，ROB 制約と LSQ 制約
を考慮したものを DF w/ R,L とした．提案手法ではプロセッサのパラメータを指定する必
要があるが，これは表 6.2 と同じ値を指定した．以後の図のベンチマーク名の表記におい
て，compress95，m88ksim，vortex をそれぞれ comp.，m88k.，vort. と表す．また，GM は
1
付録 B にプロセッサ台数を変化させた場合の評価結果を示す．
24
6.2. データフローを考慮したスレッド分割技法の評価
25
表 6.1: 使用したベンチマークと入力セット
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
プロファイル用
入力
命令数
train/test.in
42M
ref/regclass.i
141M
11×11 board, level 4,
106M
ref/null.in
train/vigo.ppm,
92M
68 × 48 pixcels
test/test.lsp
474M
test/ctl.in,
499M
test/dhry
perl
train/jumble.pl,
train/jumble.in
vortex
ref/persons.1k,
ref/vortex.in
(reduced iterations)
シミュレーション用
入力
命令数
30000 e 2231
95M
ref/genoutput.i
84M
9×9 board, level 6,
94M
train/2stone9.in
ref/specmun.ppm
400M
train/train.lsp
train/ctl.in,
train/dcrand
train/scrabbl.pl,
61M train/scrabbl.in
(add three words)
183M
136M
ref/persons.1k,
ref/vortex.in
100M
80M
80M
全ベンチマークの幾何平均を表す．
6.2
6.2.1
データフローを考慮したスレッド分割技法の評価
静的なスレッド分割数
利得計算方法を変更したことにより選択されたスレッド分割がどのように変化したかに
ついて述べる．表 6.4 に各利得計算手法における静的なスレッド分割数を示す．
表からわかるように，利得計算を変更したことにより，選択されたスレッド分割数が増
加した．これは，DIST ではスレッド間データ依存のために利得が小さいと判断されたス
レッド分割が，提案手法である DF，DF w/ R，DF w/ R,L ではノンブロッキングの効果
により利得が大きいと判断されたためである．これから，提案手法では距離を用いた利得
計算では見つけることのできなかったスレッド分割を見つけることができたといえる．
第 6 章 評価
26
表 6.2: SKY の基本モデル
(a) プロセッサ
命令フェッチ幅
命令デコード幅
命令発行幅
命令コミット幅
命令ウィンドウ
ROB
LSQ
8 命令
8 命令
8 命令
8 命令
64 エントリ
128 エントリ
128 エントリ
(b) 共有資源
1024 エントリ，履歴長 4 の PAp
分岐予測機構
分岐予測ミスペナルティ4 サイクル
完全
命令キャッシュ
データキャッシュ
完全
メモリ曖昧性検出機構 理想
提案手法においても，制約を追加することでスレッド分割数が変化している．DF と DF
w/ R とを比較すると，DF w/ R の方が分割数が少ない．DF では，PCG を作成したスレッ
ドの中の命令で先行制約のない命令ならば，プログラムの順序に関係なくすべて実行可能
である．これから，オーバラップ実行されると判断される命令数も多くなり，利得を大きく
計算してしまう．しかし，プロセッサがスケジューリング可能な命令はプロセッサ内で処
理中の命令のみであり，ROB 制約を考えることでこの制限をつけることができる．このた
め，DF w/ R は DF と比べて利得が小さくなり，選択される分割も減少したと考えられる．
DF w/ R と DF w/ R,L とを比較すると，DF w/ R,L の方が分割数が多い．DF w/ R,L
ではロード命令のメモリ・アクセス部に生じる偽の依存を先行制約として加えている．こ
のため，ロード命令のメモリ・アクセス部の実行サイクルは遅くなり，その結果プログラ
ム全体の実行サイクルが長くなると計算される．これにより，親スレッドの実行終了サイ
クルが遅くなり，子スレッドでオーバラップ可能な時間が長くなるため，DF w/ R と比べ
6.2. データフローを考慮したスレッド分割技法の評価
27
表 6.3: 基準プロセッサの IPC
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
GM
IPC
3.51
2.82
2.36
4.82
3.48
4.39
3.75
4.20
3.59
表 6.4: 静的スレッド分割数
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
DIST
8
293
533
95
2
14
57
132
DF
14
883
568
158
15
51
170
598
DF w/ R DF w/ R,L
8
11
853
888
529
580
163
162
14
12
44
48
168
169
492
543
て利得が大きくなる．これが分割数が増加した原因であると考えられる．
6.2.2
性能向上率
利得計算方法を変更したことによる性能向上率の変化について図 6.1 に示す．この図に
おいて，縦軸は基準プロセッサに対する性能向上率を，横軸はベンチマーク名を表す．各
ベンチマークに 4 本の棒グラフがあり，左から利得計算方法を DIST，DF，DF w/ R，DF
w/ R,L として生成したスレッド分割による性能向上を示す．
図からわかるように，DIST に対して DF はベンチマークによって効果のばらつきが非常
第 6 章 評価
28
基準プロセッサに対する性能向上率 [%]
60
DIST
DF
DF w/ R
DF w/ R,L
50
40
30
20
10
0
comp. gcc
go
ijpeg
li
m88k. perl vort.
GM
図 6.1: 各利得計算手法における性能向上率
に大きい．最大で 7.8%ポイントの性能向上が得られたが，平均では 2.2%ポイントの性能
低下であった．これは，データフローと機能ユニットを考慮しただけでは命令の実行サイ
クルの計算の誤差が大きく，利得計算の精度が低いためと考えられる．
これに対して，ROB 制約を考慮することで，多くのベンチマークで性能が向上した．DF
w/ R は DF に対して最大で 23.0%ポイント，平均では 4.5%ポイントの性能向上となった．
さらに LSQ 制約も考慮することで性能は向上し，DF w/ R,L は DF w/ R に対して最大
10.2%ポイント，平均では 2.2%ポイントの性能向上となった．また，DIST に対し，最大
で 13.4%ポイント，平均では 4.5% ポイントの性能向上となった．ijpeg は DF w/ R,L でも
DIST より性能が低い．これは，実行時には空きプロセッサがなくスレッド生成に失敗す
ることがあるが，コンパイラはスレッド分割の選択時にプロセッサ台数を考慮せず，すべ
ての分割が新たなスレッドを生成可能としていることが原因である．以上より，データフ
ローに加えて，プロセッサの資源を考慮することは実行サイクルの計算に有効であったと
6.2. データフローを考慮したスレッド分割技法の評価
29
いえる．ROB と LSQ の制約は共に効果があったが，中でも ROB 制約の効果が大きいこと
がわかった．これは，ROB がプロセッサにおける命令の実行に大きな影響を及ぼしている
ためと考えられる．
以上の結果から，データフローとプロセッサの資源を考慮することによって，DIST と
比べて正確に性能向上を計算することができるようになり，実際に性能向上に寄与するス
レッド分割を選択できるようになったといえる．
図 6.1 において，DF w/ R,L と DIST を比較すると，性能向上の差が大きいプログラム
と，ほとんど差がないプログラムとがある．これは，距離を用いた利得計算ですでに十分
正確に利得を計算できているプログラムでは，提案手法の有効性は小さいためと考えられ
る．そこで，コンパイラが計算した利得から，コンパイラの見積もった基準プロセッサか
らの性能向上 espeedup を，DIST と DF w/ R,L について計算した．espeedup は以下の式
で与えられる：
espeedup = α
t∈F
Ninst −
e(t)g(t)
e(t)g(t)
t∈F
ここで，Ninst は全動的命令数，e(t)，g(t) はそれぞれスレッド分割 t の実行回数および利得
である．また，α はマルチスレッド実行により生じるオーバヘッドを表す係数で，0 < α < 1
である．以下にこの式の意味を説明する．利得はオーバラップ実行される命令数であるの
で，すべてのスレッド分割について利得とその実行回数の積を合計すると，プログラム全
体でオーバラップ実行される命令数がわかる．図 6.2 に示すように，スレッドがオーバラッ
プした分だけ実行時間を決定する演算量が減ると考えることができる．これから，Ninst か
らオーバラップ命令数の合計を引いたものと Ninst の比が分割したことによる性能向上であ
るといえる．しかし，スレッドに分割することで，fork 命令，finish 命令，send 命令と
いう命令数の増加，スレッド間データ依存の同期といったオーバヘッドが生じるため，命
令数の比ほど性能向上は望めない．このオーバヘッドは，各スレッドの IPC の低下として
現れる．そこで，ベンチマーク毎にスレッドの平均 IPC を求め，これと基準プロセッサの
第 6 章 評価
30
マルチプロセッサ
1プロセッサ
t0
fork
t1
fork
t2
Ninst - Σ e(t)g(t)
Ninst
g(t1)
g(t2)
図 6.2: オーバラップによる演算量の減少
IPC との比 α を用いてオーバヘッドの影響を考慮した．各ベンチマークにおけるスレッド
の平均 IPC と α の値を，DIST と DFw/ R,L についてそれぞれ表 6.5，6.6 に示す．以上の
ように求めた性能向上を基準プロセッサからの差として表したものが espeedup である．
測定により求めた Ninst ，e(t)，α を使用した espeedup の計算結果を図 6.3 に示す．この
図において，縦軸は espeedup，横軸はベンチマーク名を表す．各ベンチマークに 2 本の棒
グラフがあり，利得計算が左は DIST，右は DF w/ R,L である．
図 6.1 において DIST に対して DF w/ R,L の性能向上が大きかった gcc，perl は，espeedup
でも差が大きい．よって，これらは提案手法が有効に働いているといえる．また，図 6.1 に
おいて DIST に対して性能が向上しなかった compress95，ijpeg，li は espeedup でも差がな
いので，提案手法が有効に働かないベンチマークであるといえる．go，m88ksim，vortex
は espeedup では DIST に対して性能向上が見込めるが，実際には見積もりほど性能の差は
ない．この原因として以下の 2 つを考えた．1 つは，この原因は子スレッドの生成のタイ
ミングをコンパイラでは正確に計算できないこと，もう 1 つは複数スレッドの並列実行に
6.2. データフローを考慮したスレッド分割技法の評価
31
表 6.5: スレッドの平均 IPC とオーバヘッドを表す係数 α（DIST）
ベンチマーク スレッドの平均 IPC
α
compress95
2.67
0.76
1.82
0.65
gcc
1.34
0.57
go
2.02
0.42
ijpeg
0.28
0.08
li
2.76
0.63
m88ksim
2.77
0.74
perl
2.81
0.67
vortex
表 6.6: スレッドの平均 IPC とオーバヘッドを表す係数 α（DF w/ R,L）
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
スレッドの平均 IPC
2.76
1.88
1.46
1.79
1.55
2.78
2.65
2.86
α
0.79
0.67
0.62
0.37
0.46
0.63
0.71
0.68
伴ってスレッド間に相互作用が生じることである．
1 つ目の原因について，子スレッドの生成のタイミングが正確に計算できない理由は，
SKY では子スレッドを生成する fork 命令は制御依存が解消するまで実行できないとして
いるが，本研究で作成したコンパイラでは利得計算は fork 命令以降のみを扱っており，制
御依存が解消するタイミングがわからないためである．より高い性能向上を得るためには，
コンパイラがハードウェアの動作をより正確に利得計算に反映させるか，ハードウェアを
コンパイラの想定に近い動作をするように改良することが必要であると考えられる．
コンパイラの想定に近い動作をハードウェアにさせる方法として，SKY 専用命令の投機
第 6 章 評価
32
2.4
1.0
DIST
DF w/ R,L
espeedup
0.8
0.6
0.4
0.2
0
comp. gcc
go
ijpeg
li
m88k. perl
vort.
図 6.3: コンパイラにおける性能向上の見積もり
的実行 [18] がある．上で述べたように，fork 命令は制御依存が解消するまで実行できない．
これと同様に，レジスタ値を送信する send 命令も制御依存が実行を制限している．これに
対して，投機的実行では，fork 命令と send 命令について，命令がデコードされた段階で実
行可能とする．投機的に fork 命令を実行することで，子スレッドの生成タイミングは命令
がデコードされたサイクルとなる．これは我々のコンパイラの想定と等しくなるため，実
際のオーバラップ量が利得に近くなると考えられる．send 命令については，コンパイラは
一部の send 命令は制御依存を考えている．send 命令には 2 種類あり，fork 命令の直後に
挿入される転送命令と，fork 命令よりも後方に挿入される真の送信命令である．fork 命
令以降で値が変更される可能性があるレジスタについては真の送信命令を，それ以外は転
送命令として挿入される．提案手法の利得計算時は 2 種類の send 命令のうち，真の送信命
令については制御依存を考えている．しかし，転送命令については制御依存を考えていな
い．これは fork 命令と同様の理由である．send 命令の投機的実行を行うことにより，転
6.2. データフローを考慮したスレッド分割技法の評価
33
送命令の実行サイクルがコンパイラの想定に近くなるが，真の送信命令については実行サ
イクルがコンパイラの想定とは異なってしまう．しかし，真の送信命令に比べて転送命令
の数の方が多いので2 ，投機的に send 命令を実行することはコンパイラの想定に近くなる
と考えられる．
投機的に fork 命令を send 命令を実行した場合の性能向上率の変化について図 6.4 に示
す．この評価では，よりコンパイラの想定に近づけるためにプロセッサ台数は無限とした．
評価に使用した利得計算は DIST と DF w/ R,L である．この図において，横軸はベンチ
マーク名を，縦軸は基準プロセッサに対する性の向上率を示す．各ベンチマークに 4 本の
棒グラフがあり，左から DIST で fork 命令と send 命令を制御依存が解消してから実行し
たもの（DIST），DIST で fork 命令と send 命令を投機的に実行したもの（DIST spec），
DF w/ R,L で fork 命令と send 命令を制御が確定してから実行したもの（DF w/ R,L），
DF w/ R,L で fork 命令と send 命令を投機的に実行したもの（DF w/ R,L spec）を表す．
図から，多くのベンチマークは fork 命令と send 命令の投機的実行は DF w/ R,L の方が
DIST よりも効果が大きいことがわかる．投機的実行により，DIST では m88ksim で最大
28.5%ポイント，平均 12.0%ポイントの性能向上，DF w/ R,L では m88ksim で最大 40.9%ポ
イント，平均 13.8%ポイントの性能向上となった．特に m88ksim では，制御依存が解消す
るまで実行できない場合では 3.2% ポイントの性能差しかなかったが，投機的実行により
15.6%ポイントと大きな性能差が生じた．これより，本研究で作成したコンパイラが fork
命令以降しか扱っていないことは利得計算の正確さに悪影響を及ぼしているといえる．
一方，見積もりでは性能差が大きかった go は fork 命令と send 命令を投機的に実行して
も DIST と DF w/ R,L との性能差は広がらなかった．これは，コンパイラの見積もりほど
性能が向上しない原因の 2 つ目にあげたスレッド間の相互作用であると考えられる．これ
は，本研究で作成したコンパイラは，利得計算を行うときに 1 つのスレッド分割にのみ注
目している．これは，あるスレッド分割の子の開始点で分けられる 2 つのスレッドしか存在
2
付録 C に SKY 専用命令の動的な出現数を示す．
第 6 章 評価
34
基準プロセッサに対する性能向上率 [%]
120
DIST
DIST spec
DF w/ R,L
DF w/ R,L spec
100
80
60
40
20
0
comp. gcc
go
ijpeg
li
m88k. perl vort.
GM
図 6.4: fork 命令と send 命令の投機的実行時の性能向上率の変化
しないとして利得計算しているということである．実際のスレッド並列実行時には，注目
している 2 つのスレッド以外に，プログラムの前方や後方に存在するスレッド分割による
スレッドも並列に実行されている．前方のスレッドからはデータが送られてくるため，注
目している 2 つのスレッドの実行サイクルに影響を及ぼすと考えられる．また，後方のス
レッドにより，注目している 2 つのスレッドのうち，子スレッド側に別のスレッド分割に
よる SKY 専用命令が挿入され，そのためオーバラップ実行される命令数が減少することが
考えられる．選択の前に行う利得計算時にはどのスレッド分割が前方あるいは後方に存在
するかは分からないため，容易には上記のスレッド間の相互作用を考慮することはできな
い．しかし，これを考慮できれば，さらに利得計算の精度が上がることが期待できる．
第 7章
まとめ
本論文では，細粒度の TLP を効率よく利用するハードウェアに適したスレッドに分割す
るため，データフローを考慮したスレッド分割技法について述べた．これは，要素プロセッ
サがアウト・オブ・オーダ実行を行うスーパスカラ・プロセッサであり，ノンブロッキン
グな同期／通信機構を備える SKY アーキテクチャにおいて，スレッド分割による性能向上
を正確に見積もるための手法である．
SKY コンパイラでは性能向上の見積もりを利得と呼び，従来は距離を用いた方法で計算
していた．しかし，この方法では逐次実行のプロセッサで構成されるマルチプロセッサで
は利得を正確に計算できるが，命令レベル並列性を効率よく利用可能なプロセッサで構成
される SKY では正確ではないという問題点があった．そこで，データフローを考慮し，動
的命令スケジューリングを考えて各命令の実行サイクルを計算することで利得計算を行う
方法を提案した．実行サイクルの計算には命令の実行順序を表す先行制約グラフ（PCG）
に基づいたリスト・スケジューリングを用いた．一般に先行制約はデータ依存であるが，プ
ロセッサにおける動的命令スケジューリングを正確に計算するため，ROB 制約，LSQ 制約
というプロセッサの資源制約を表した先行制約を追加した．
4 プロセッサ構成の SKY における評価の結果，命令間の距離を用いる従来の SKY コンパ
イラによるスレッド分割と比較して，提案手法を用いたスレッド分割は，ROB 制約と LSQ
制約を追加することにより最大 13.4%ポイント，平均 4.5%ポイントの性能向上を達成した．
35
付録A
利得の閾値の評価
本章では，3.2 節で述べた利得の閾値の評価結果を示す．この閾値はマルチスレッド実行
によるオーバヘッドであり，スレッドに分割したことによる ILP の損失が原因である．ILP
の損失は，スレッドの開始時と終了時の命令不足が原因として考えられる．スレッドの開
始時には，スレッドの最初の命令がフェッチされてから実行されるまでに時間がかかり，こ
の間プロセッサは実行する命令がない．また，スレッドの終了時には，finish 命令によっ
て命令フェッチが停止するため，finish 命令が発行された後，リオーダ・バッファからリ
タイアするまでの間発行できる命令は単一のプロセッサよりも少ない．このような期間は
マルチスレッド実行により生じたものであるから．ILP の損失ということができる．
本論文の提案手法では，子スレッドの開始サイクルを，親スレッドで fork 命令が実行さ
れてから 6 サイクル1 後とすることで，スレッド生成のオーバヘッドは考慮している．一
方，ILP の損失は考慮していない．そこで，閾値であるマルチスレッド実行によるオーバ
ヘッドの値を決定するために，オーバヘッドの値を 0，15，30，45 と変化させて選択を行
い，性能を測定した．その結果を図 A.1 に示す．グラフの横軸はベンチマーク名を表し，縦
軸は基準プロセッサからの性能向上率を表す．各ベンチマークに 4 本の棒グラフがあり，左
から，オーバヘッドが 0，15，30，45 のときの性能向上を表す．この結果から，最も性能
向上が大きかった 30 をマルチスレッド実行によるオーバヘッドの値と決定した．
1
この値は，fork 命令のレイテンシである 2 サイクルと，後続プロセッサで最初の命令が実行されるまで
のサイクル，すなわち分岐予測ミスペナルティである 4 サイクルの合計である．
36
37
基準プロセッサに対する性能向上率 [%]
90
OH0
OH15
OH30
OH45
80
70
60
50
40
30
20
10
0
comp. gcc
go
ijpeg
li
m88k. perl vort.
図 A.1: 利得の閾値を変化させたときの性能向上率
GM
付録B
プロセッサ台数を変化させた場合の評価
本章では，SKY を構成するプロセッサ台数を 2，4，8，無限と変化させたとき評価結果
を示す．表 B.1 ∼ B.4 に各プロセッサ台数における IPC を，図 B.1 ∼ B.4 に，各プロセッ
サ台数における基準プロセッサからの性能向上率を示す．各図の見方は，図 6.1 と同様で
ある．図 B.4 は提案手法によるスレッド分割における性能の上限を表す．
38
39
表 B.1: 各利得計算手法における IPC（プロセッサ台数 2）
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
GM
DIST
3.79
3.22
2.92
5.53
3.56
4.88
3.90
4.78
3.99
DF
3.61
3.29
2.76
5.53
3.56
4.97
4.09
4.86
3.99
DF w/ R
3.67
3.40
3.03
5.54
3.56
5.01
4.14
4.88
4.07
DF w/ R,L
3.98
3.38
3.01
5.55
3.56
4.96
4.23
5.03
4.13
基準プロセッサに対する性能向上率 [%]
90
DIST
DF
DF w/ R
DF w/ R,L
80
70
60
50
40
30
20
10
0
comp. gcc
go
ijpeg
li
m88k. perl vort.
GM
図 B.1: 各利得計算手法における性能向上率（プロセッサ台数 2）
付 録 B プロセッサ台数を変化させた場合の評価
40
表 B.2: 各利得計算手法における IPC（プロセッサ台数 4）
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
GM
DIST
3.98
3.50
3.57
5.65
3.57
6.53
4.09
5.70
4.45
DF
3.65
3.62
3.10
5.45
3.57
6.71
4.38
5.65
4.37
DF w/ R
3.67
3.84
3.64
5.49
3.57
6.68
4.47
5.87
4.53
DF w/ R,L
4.03
3.82
3.65
5.49
3.57
6.66
4.59
6.00
4.60
基準プロセッサに対する性能向上率 [%]
90
DIST
DF
DF w/ R
DF w/ R,L
80
70
60
50
40
30
20
10
0
comp. gcc
go
ijpeg
li
m88k. perl vort.
GM
図 B.2: 各利得計算手法における性能向上率（プロセッサ台数 4）
41
表 B.3: 各利得計算手法における IPC（プロセッサ台数 8）
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
GM
DIST
3.98
3.64
4.01
5.58
3.61
6.56
4.17
5.76
4.55
DF
3.65
3.75
3.30
5.68
3.62
6.74
4.45
5.73
4.47
DF w/ R
3.67
4.03
4.07
5.76
3.62
6.72
4.66
6.00
4.69
DF w/ R,L
4.03
3.99
4.09
5.78
3.62
6.70
4.82
6.11
4.78
基準プロセッサに対する性能向上率 [%]
90
DIST
DF
DF w/ R
DF w/ R,L
80
70
60
50
40
30
20
10
0
comp. gcc
go
ijpeg
li
m88k. perl vort.
GM
図 B.3: 各利得計算手法における性能向上率（プロセッサ台数 8）
付 録 B プロセッサ台数を変化させた場合の評価
42
表 B.4: 各利得計算手法における IPC（プロセッサ台数 ∞）
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
GM
DIST
3.98
3.75
4.39
5.61
3.75
6.57
4.18
5.76
4.65
DF
3.65
3.81
3.45
5.77
3.75
6.74
4.48
5.74
4.54
DF w/ R
3.67
4.14
4.34
5.89
3.75
6.73
4.70
6.00
4.79
DF w/ R,L
4.03
4.11
4.38
5.92
3.75
6.70
4.82
6.12
4.87
基準プロセッサに対する性能向上率 [%]
90
DIST
DF
DF w/ R
DF w/ R,L
80
70
60
50
40
30
20
10
0
comp. gcc
go
ijpeg
li
m88k. perl vort.
GM
図 B.4: 各利得計算手法における性能向上率（プロセッサ台数 ∞）
付録C
SKY 専用命令の動的な出現数
6.2.1 節で，静的なスレッド分割数が増加したことを述べた．この結果，SKY 専用命令を
多く実行することが考えられる．そこで，SKY 専用命令について，その動的な出現数を，
DIST，DF w/ R,L についてそれぞれ表 C.1，C.2 に示す．send 命令については，fork 命
令の直後に挿入される転送命令と，それ以外である真の送信命令に分けて示す．これらの
表において，右端の割合とは，プログラム本来の命令数（表 6.1 を参照）に対して SKY 専
用命令が占める割合を表す．また，AVG は全ベンチマークの平均を表す．
DIST と DF w/ R,L の send 命令の内訳を比較すると，DF w/ R,L の転送命令の比率が
DIST よりも低いことがわかる．DIST ではスレッド間データ依存が利得を決定するため，
できる限りスレッド間の通信が実行を妨げないようなスレッド分割が選択される．このよ
うなスレッド分割は多くのレジスタ値の送信が fork 命令実行時に転送命令によって行わ
れるものである．しかし，提案手法の DF w/ R,L では，スレッド間の通信が生じても，そ
の影響がノンブロッキングな同期によって緩和されることを考慮している．すなわち従来
手法よりも真の送信命令の存在を許容できるといえる．これが転送命令と真の送信命令の
比率の違いとして現れたと考えられる．
SKY 専用命令は平均では 10%以下であるが，DIST の compress95 のように 20%を超える
ベンチマークがあり，これはメモリ・システムに悪影響を与える可能性がある．特に，転
送命令が多いことがわかる．これから，転送命令を工夫して命令数を削減することができ
れば，メモリ・システムに悪影響を与える可能性を減らすことができると考えられる．
43
付 録 C SKY 専用命令の動的な出現数
44
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
AVG
表 C.1: SKY 専用命令の動的な出現数（DIST）
send 命令 [M]
fork 命令 [M]
finish 命令 [M] 合計 [M]
転送 真の送信
0.6 18.2
1.7
0.6
21.1
0.4
6.6
2.0
0.4
9.3
0.5
7.4
3.1
0.5
11.4
0.4
7.2
2.1
0.4
10.2
0.1
1.4
0.1
0.1
1.7
0.5
7.7
3.4
0.5
11.9
0.3
5.6
1.1
0.3
7.3
0.4
6.8
5.0
0.4
12.7
0.4
7.6
2.3
0.4
10.7
割合 [%]
22.26
11.06
15.19
2.27
0.94
11.91
9.10
15.84
7.46
表 C.2: SKY 専用命令の動的な出現数（DF w/ R,L）
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
AVG
fork 命令 [M]
0.6
0.3
0.4
0.7
0.1
0.5
0.3
0.4
0.4
send 命令 [M]
転送 真の送信
5.5
1.4
2.4
1.4
2.9
2.6
7.1
3.4
1.1
0.1
5.4
3.7
2.9
1.2
3.3
4.2
3.8
2.2
finish 命令 [M] 合計 [M] 割合 [%]
0.6
0.3
0.4
0.7
0.1
0.5
0.3
0.4
0.4
8.1
4.4
6.2
11.9
1.3
10.2
4.8
8.4
6.9
8.50
5.27
8.24
2.65
0.70
10.14
6.00
10.50
4.81
付録D
利得計算の計算時間
本章では利得計算にかかった時間を示す．評価環境は，プロセッサが AMD AthlonXP
2400+，OS が FreeBSD 4.7-RELEASE である．利得計算プログラムのコンパイルには GNU
GCC Version 2.95.4（コンパイル・オプション：-O0）を使用した．表 D.1 に DIST，DF，
DF w/ R，DF w/ R,L の各利得計算時間を示す．この表から，提案手法の方が明らかに計
算時間が長いことがわかる．これは，従来手法は依存関係にある命令間の命令数を数える
だけであるが，提案手法では PCG の作成，リスト・スケジューリングを行うので，計算量
が従来手法と比べて多くなってしまうためである．計算時間に関係する要素として，スレッ
ド分割候補の数が挙げられる．これを表 D.2 に示す．この表において，括弧内の数字はプ
ロファイル入力を用いた場合に通る経路上に存在するスレッド分割候補の数である．経路
上にあるスレッド分割候補が多いものは計算時間が長いことがわかる．
この問題の対処方法としては，頻繁に実行される関数内のスレッド分割候補については
提案手法を用い，稀にしか実行されない関数内のスレッド分割候補は従来手法を用いるこ
とが考えられる．
提案手法である DF，DF w/ R，DF w/ R,L について見ると，多くのベンチマークでは
制約を追加するに従って計算時間が増加している．これは，制約を追加することで計算量
が増加するためと考えられる．しかし，compress95 や vortex では制約を追加する毎に計算
時間が減少している．これは，制約を追加することによって各命令の実行サイクルが遅く
なり，オーバラップ命令数の計算が早く終了するためと考えられる．5.1 節で述べたように，
子スレッドの命令については，まだ実行がスケジュールされていないどの命令も親スレッ
ドの実行終了サイクル以前にスケジュール不可能なことが判明した時点で計算を終了する．
命令の実行を決定する制約が少なくなれば，より多くの命令をオーバラップ実行可能と計
45
付 録 D 利得計算の計算時間
46
表 D.1: 各利得計算手法における計算時間（分）
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
DIST
1.3
12.1
11.2
3.7
6.2
15.3
2.6
10.7
DF
10.1
146.1
123.4
38.7
7.7
20.5
16.1
289.5
DF w/ R
5.7
251.1
250.1
53.4
8.6
22.9
22.1
136.5
DF w/ R,L
5.4
302.5
266.8
71.7
8.9
26.1
28.0
107.9
表 D.2: 分割候補の数
ベンチマーク
compress95
gcc
go
ijpeg
li
m88ksim
perl
vortex
候補数
76
(48)
6080 (5182)
4853 (3982)
1477 (1004)
1099
(26)
1548 (133)
2392 (446)
12190 (887)
算してしまうため，制約の少ない方が利得計算時間が長くなったと考えられる．
謝辞
本研究を進めるにあたり，多大なる御指導と御鞭撻を賜りました名古屋大学大学院工学
研究科教授 島田俊夫先生，名古屋大学大学院工学研究科助教授 安藤秀樹先生に心より感
謝いたします．
本研究を遂行するにあたり懇切丁寧に御指導くださいました名古屋大学大学院工学研究
科助 小林良太郎先生に深く感謝いたします．また，本研究の遂行を支えて下さいました名
古屋大学大学院工学研究科電子情報学専攻 島田研究室の諸氏に深く感謝致します．
47
参考文献
[1] A. V. Aho, R. Sethi, and J.D. Ullman, Compilers: Principles, Techniques and Tools,
Addison-Wesley Publishing Company, 1986.
[2] H. Akkray and M. A. Driscoll, “A Dynamic Multithreading Processor,” In Proc. 31st
Int. Symp. on Microarchtecture, pp.226-236, Nov. 1998.
[3] L. A. Barroso, K. Gharachorloo, R. McNamara, A. Nowatzyk, S. Qadeer, B. Sano,
S. Smith, R. Stets, and B. Verghese, L. A. Barroso et al., “Piranha: A Scalable
Architecture Based on Single-Chip Multiprocessing,” In Proc. 27nd Int. Symp. on
Computer Archtecture, pp.282-293, June 2000.
[4] Jr. E. G. Coffman, editor, Computer and Job-Shop Scheduling Theory, John Wiley
and Sons, New York, 1976.
[5] K. Diefendorff, “Power4 Focuses on Memory Bandwidth: IBM Confronts IA-64, Says
ISA Not Important,” Microprocessor Report, Vol. 13, No. 13, Oct. 1999.
[6] R. Eigenmann, J. Hoeflinger and D. Pauda, R. Eigenmann et al., “On the Automatic
Parallelization of the Perfect Benchmarks,” In IEEE Trans. on parallel and distributed
systems, Vol. 9, No. 1, 1998.
[7] P. N. Glaskowsky, “IBM Previews Power5,” Microprocessor Report, 9/8/03-02, Sep.
2003.
[8] P. N. Glaskowsky, “IBM Raises Curtain on Power5: More Details Disclosed at Microprocessor Forum,” Microprocessor Report, 10/14/03-01, Oct. 2003.
48
参考文献
49
[9] M. W. Hall, J. M. Anderson, S. P. Amarasinghe, B. R. Murphy, S.-W. Liao, E.
Bugnion, M. S. Lam, M. W. Hall et al., “Maximizing Multiprocessor Performance
with the SUIF Compiler,” In IEEE Computer, 1996.
[10] L. Hammond, M. Willey, and K. Olutotun, “Data Speculation Support for a Chip
Multiprocessor,” In Proc. Eighth Int. Conf. on Architectural Support for Programming
Laguages and Operating Systems, pp.58-69, Oct. 1998.
[11] 岩田充晃, 小林良太郎, 安藤秀樹, 島田俊夫, “制御等価を利用したスレッド分割技法,”
情報処理学会研究報告 98-ARC-128, pp.127-132, 1998 年 3 月.
[12] 加納正晃, 小林良太郎, 安藤秀樹, 島田俊夫, “非数値計算プログラムにおけるスレッド・
レベル並列性の限界,” 情報処理学会研究報告 2000-ARC-140, pp.55-60, 2000 年 11 月.
[13] 木村啓二, 尾形航, 岡本雅巳, 笠原博徳，“シングルチップマルチプロセッサ上での近細
粒度並列処理,” 情報処理学会論文誌, Vol.40, No.5, pp.1924-1933, 1999 年 5 月.
[14] 小林良太郎, 小川行宏, 岩田充晃, 安藤秀樹, 島田俊夫, “非数値計算応用向けスレッド・
レベル並列処理マルチプロセッサ・アーキテクチャ SKY,” 情報処理学会論文誌, Vol.42,
No.2, pp.349-366, 2001 年 2 月.
[15] K. Krewell, “UltraSPARC IV Mirrors Predecessor: Sun Builds Dual-Core Chip in
130nm,” Microprocessor Report, 11/10/03-02, Nov. 2003.
[16] K. Krewell, “Fujitsu Makes SPARC See Double: SPARC64 VI Uses Process Shrink to
Double Cores,” Microprocessor Report, 11/24/03-01, Nov. 2003.
[17] N. Nishi, T. Inoue, M. Nomura, S. Matsushita, S. Torii, A. Shibayama, J. Sakai, T.
Ohsawa, Y. Nakamura, S. Shimada, Y. Ito, M. Edahiro, K. -i. Minami, O. Matsuo, H.
Inoue, T. Manabe, T. Horiuchi, M. Motomura, M. Yamashina, and M. Fukuma, “A
50
参考文献
1GIPS 1W Single-Chip Tightly-Coupled Four-Way Multiprocessor with Architecture
Support for Multiple Control Flow Execution,” In Proc. 2000 IEEE Int. Solid-State
Circuits Conf., pp.418-419, Feb. 2000.
[18] 小川行宏, 小林良太郎, 安藤秀樹, 島田俊夫, “オンチップマルチプロセッサアーキテク
チャSKY の評価,” 情報処理学会研究報告 99-ARC-135, pp.17-24, 1999 年 11 月.
[19] K. Olukotun, B. A. Nayfeh, L. Hammond, K. Wilson, and K. Chang, “The Case for
a Single-Chip Multiprocessor,” In Proc. 7th Int. Conf. on Architectual Support for
Programming Language and Operating Systems, pp.2-11, Oct. 1996.
[20] M. D. Smith, M. A. Horowitz, and M. S. Lam, “Efficient Superscalar Performance
Through Boosting,” In Proc. 5th Int. Symp. on Architectural Support for Programming
Languages and Operating Systems, pp.248-259, Oct. 1992.
[21] G. S. Sohi, S. E. Breach, and T. N. Vijaykumar, “Multiscalar Processors,” In Proc.
22nd Int. Symp. on Computer Archtecture, pp.414-425, June 1995.
[22] 鳥居淳, 近藤真己, 木村真人, 池野晃久, 小長谷明彦, 西直樹, “オンチップ制御並列プロ
セッサ MUSCAT の提案,” 情報処理学会論文誌, Vol.39, No.6, pp.1622-1631, 1998 年 6
月.
[23] D. Tullsen, S. Eggers, and H. Levy, “Simultaneous Multithreading: Maximizing OnChip Parallelism,” In Proc. 22nd Int. Symp. on Computer Archtecture, pp.24-35, June
1995.
[24] T. N. Vijaykumar and G. S. Sohi, “Task Selection for a Multiscalar Processor,” In
Proc. 31st Int. Symp. on Microarchitecture, pp.81-92, Dec. 1998.
© Copyright 2024 Paperzz
