クラスタ型プロセッサのための分散投機メモリフォワーディング

2004/05/27 SACSIS2004スライド資料 1

クラスタ型プロセッサのための分散投機メモリフォワーディン

グ

入江英嗣 #1　服部直也 #2　高田正法

坂井修一　田中英彦 #3

東京大学情報理工学系研究科#1 現在、科学技術振興機構#2 現在、日立中央研究所#3 現在、情報セキュリティ大学院大学


研究の背景：クラスタ型プロセッサ

• 複数の実行コアの接続で一つのマイクロプロセッサを構成–近年注目されている

フロントエンド処理

実行コア発行キュー

レジスタ

バックエンド処理

クラスタ化

フロントエンド処理

実行クラスタ 0発行キューレジスタ

バックエンド処理

実行クラスタ 1発行キューレジスタ


研究の背景：クラスタ化の利点発行キューレジスタ

発行キューレジスタ

発行キューレジスタ

1cycle

1cycle

クラスタ化クラスタ間通信遅延

タイミング・クリティカル・パスが縮まる

同じ規模の集中型プロセッサに較べて○：より速い動作クロックの実現（連続実行可）×：処理が分散してしまうと IPC低下

ポテンシャル：高クロック動作＆積極的な並列実行の両立


研究の目的• クラスタ型プロセッサに必要なメモリ参照（ load/store）処理–クラスタ化の利点：高クロック高 IPC （ Instructions

Per Cycle)

–メモリ参照がボトルネックとならないためには• 高クロックハードウェアで（シンプル、小容量）• 後続命令の実行を滞らせないデータ供給が必要

– 特にロード命令の遅延は IPCに大きく影響する

• 実際のメモリ参照：長い遅延–クラスタ化によりさらに増大　←この後議論

オーバヘッド隠蔽手法を提案

乖離


発表の流れ• ロード命令オーバヘッドの検討

–クラスタ型プロセッサにおけるメモリ命令• ロード命令高速化のアイデア

–発行、参照の局所化• 提案手法の実装

–スケジューラと連動したフォワーディング制御• 評価• まとめ


ロード命令オーバヘッドの検討

クラスタ型プロセッサにおける


LSQ

steeringlogic

D1cache

issue queue

register file

issue queue

register file

frontend(fetch/decode/

rename)

dataforward

tagforward

×8

想定プロセッサ

バイナリ互換を持ち、動的に実行クラスタを決定するクラスタ型スーパスカラ

高クロックで動作する

1命令実行幅のクラスタ

以降の評価でベースラインモデル

として利用

高速なクラスタ

8個による構成で高クロック高 IPCを狙

う


クラスタ型プロセッサにおけるメモリ構成（ 1）

• ローカルなキャッシュ (D0)を各クラスタに配置して高速化する事が自然だが・・–ここでは“キャッシュ”：キャッシュ＋ストアキュー

cluster cache(D0)

cluster cache(D0)

cluster cache(D0)

frontend steer issue/execute memory

load

?

steer時に依存関係が判明していないのでどの D0にデータがあるのか分からない

cache(D1)


クラスタ型プロセッサにおけるメモリ構成（ 2）

• 先行研究では、メモリステートを一括して管理する集中キャッシュで近似する事が多い

cluster

cache(D1)


loadcluster

cluster

どこを選択してもOK！

この構成についてロード命令のオーバヘッドを考える


ロード命令処理の遅延• 処理遅延は主に二つの要素から成る• （メモリ）発行遅延

– メモリ依存関係を正しく反映するため• ロード命令は依存のあるストア命令の発行を待つ• ストア命令は一般に順番に処理される

– メモリ依存関係は演算後まで確定しない• メモリ依存予測の精度が悪いと、待ちすぎたり早すぎたり

• 参照遅延– キャッシュ参照にかかる遅延

• キャッシュアレイが大きいと長くなる– アドレス計算終了から、ロード値が利用可能となるまで

Store a

Store b

Store c

Store d

Load x

発行キュー内のメモリ発行条件チェイン

（メモリ）発行遅延


発行遅延の増加• クラスタ型プロセッサ

– より深いパイプライン– より広い実行幅

– ステアリング次第では、メモリ発行条件の伝播に通信遅延が加わる

• simによる計測– 通常のメモリ依存予測 (wait table)を用いたものにくらべて、理想メモリ依存予測を仮定した場合の IPCは約 70%増し（想定アーキテクチャ）

• 集中型では約 40%増し

（一部の投機不可能なロード命令では）発行条件チェインが長くなる

Store a

Store b

Store c

Store d

Load x

ロード処理遅延発行遅延参照遅延


参照遅延の増加• クラスタ型プロセッサのキャッシュ参照遅延は？– 往復の通信遅延＋キャッシュアレイ参照遅延

• 通信遅延を 2サイクルとすると、往復で４サイクルの遅延

– 双方とも配線遅延のため、クラスタ型実行コアの動作遅延に較べて相対的に増大

cache(D1)

cluster

cluster

ロード処理遅延発行遅延参照遅延

• simによる計測– 参照遅延が 1サイクル増えると約 5%の IPC低下

通信アレイ参照+


ロード命令オーバヘッド：まとめ

• クラスタ型プロセッサでは、ロード命令のオーバヘッドが増大する–クラスタ化の利点を活かせない

• なぜ増大するか？–発行遅延が増える原因：メモリ発行条件がクラスタ外から来る

• 親ストアが発行したという情報がなかなか伝わってこない

–参照遅延が増える原因：クラスタ外と通信しなくてはならない /参照アレイが大きい


ロード命令高速化のアイデア

クラスタ型プロセッサにおける


ロード命令処理の局所化• なぜロード命令処理遅延が増大するか？

–発行遅延が増える原因：発行条件がクラスタ外から来る

–参照遅延が増える原因：クラスタ外と通信しなくてはならない /参照アレイが大きい

• これを防ぐためには・・–発行条件がクラスタ内から来る–クラスタ内の小容量バッファを参照する

ロード命令処理をクラスタ内に局所化できれば速い！


分散投機メモリフォワーディング

• steer時にメモリ依存予測を利用することにより分散局所化の利点を得る事はできないだろうか？

cluster

cluster

cluster

buffer

buffer

buffer


読むべきデータはメモリ依存関係のある親ストア命令が実行されたクラスタにあるはず

steeringscheme

cache(D1)

store


分散投機メモリフォワーディング

• steer時にメモリ依存予測を利用することにより分散局所化の利点を得る事はできないだろうか？

cluster buffer

cluster buffer

cluster buffer


load

読むべきデータはメモリ依存関係のあるストア命令が実行されたクラスタにあるはず

memory dep.predictor

cache(D1)

?

親 storeIDをキーとして参

照＜高速＞

verify

アドレスをキーとしてベリファイ


手法の特徴• クラスタ内の小容量バッファを介して親ストア値を直接利用（投機メモリフォワーディング）–投機フォワーディングの利点

• バッファ容量の利用効率高→小容量• アドレスではなく動的 IDで参照→制御がシンプル

• ステアリングを利用して局所化–発行、参照共にクラスタ外と通信しなくて良い


提案手法の実装


クラスタ型プロセッサへの実装• タイミング・クリティカルパスへの追加ロジックを極力さける– 出来ることはフロントエンド、バックエンドで– 依存予測情報はフロントエンド時に取得

• スケジューラ駆動– ロード処理遅延が早まるなら、後続命令の発行も早まらなくてはならない

• データ駆動方式では高速化できない– ×：“アクセスした結果データがバッファにあったら～”

– フォワーディングを consumer命令のソースオペランドに対して行う

• consumer命令：ロード結果を使用する命令


提案ハードウェア

fetchdecoderename

retire

issue executeREG

steer

クラスタ

issue executeREG

依存検出器依存予測器(store set)

load PC, store PC

PCstore ID

addressstore cluster

store set予測と同様のメモリ依存予測器過去依存のあった

ストア -ロード命令の対を PCで保持

steer

親 store-consumer対を

同じクラスタへ

LFBstore value/ID

LFBstore value/ID

“ローカルフォワードバッファ”

依存予測に基づいて値をローカルに受け渡し



fetchdecoderename

retire

issue executeREG

steer

issue executeREG


load PC, store PC

PCstore ID


steer

LFBstore value/ID

LFBstore value/ID

store

STPC

loadPC storePC storePC LFSTIDsteeredcluster

store set

confidencecounter

自分は親ストア

通常のステアリング

スキームに従う

ステア先を記録

steeredcluster

発行条件OP.A OP.BOP.A OP.B

OP.AOP.B execute

キャッシュへ書き込み

LFBへ値を保持

STIDvalueSTIDvalueSTIDvalue

動的 IDを保持LFSID


REG


fetchdecoderename

retire

issue executeREG

steer

issue execute


load PC, store PC

PCstore ID


steer

LFBstore value/ID

LFBstore value/ID

loadPC storePC storePC LFSTIDsteeredcluster

store set

confidencecounter

親ストアのステア先へ

steeredcluster

execute

STIDvalueSTIDvalueSTIDvalue

LFSID

consumer

レジスタ依存解析

loadPC 親ストア IDとステア先を渡す

REG発行条件

OP.A OP.BSTID

OP.BSTID

＜フォワーディングによる発行＞

OP.B

OP.A


パイプラインへの効果

ISSUEEXE

CUTEREG

READ

ISSUEEXE

CUTEREG

READ

store inst.

load inst.

tagforward

dataforward

consumer inst.

MEM

MEM

ISSUEEXE

CUTEREG

READMEM

latencyprediction

tagforward

dataforward

分散メモリフォワーディング適用

speculativewakeup

localforward


評価


提案手法の評価• 分散局所化の適用率

–ハードウェアはどの程度必要か• もっとも影響があると思われるのはバッファサイズ

• 性能 (IPC)への影響–ゲインはあるか

• SPECint95から 10種類のベンチマークについて、最大 256M命令を実行して計測、平均をとる–タイミングシミュレータ使用


ベースライン設定（構成）

フェッチ /リタイアスループット

up to16insts/cycle

メモリ依存予測 wait table予測（１６ｋエントリ）クラスタ数 8clusters

各クラスタの構成 ooo発行キュー（６４エントリ） , 複製物理レジスタ（ 256エントリ） , ALU×１

D-cache 64kB, 2-waySA, 64byte lines

3 read ports 1read/write port

steering scheme reg. dependence + load balance (Parcerisa方式 )

最初に紹介した“想定アーキテクチャ”


ベースライン設定（遅延）

総パイプライン段数 16stages

フロントエンド処理 (fetch – dispatch) 11cycles

issue – issue latency 1cycle

execute latency (int) 1cycle

execute latency (int MULT) 15cycles

execute latency(float) 4cycles

クラスタ間通信遅延 2cycles


分散局所化の適用率

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

1 e

ntr

y L

FB

2 e

ntr

y L

FB

4 e

ntr

y L

FB

8 e

ntr

y L

FB

16 e

ntr

y L

FB

32 e

ntr

y L

FB

64 e

ntr

y L

FB

128 e

ntr

y L

FB

predict

forwarded consumer/allload

ロード命令の何%が予測対象となり、何%がフォワードされたか

正しく依存予測（フォワード適用の上限）≒

フォワード適用（高速化されたロード命令）

依存予測は成功しているが、バッファ容量が足りていない

少ないエントリ数で上限に近い

値

1エントリ96bit（ STID32bit+val

ue64bit)とすると、 128entryで

1.5Kbyte


IPCへのインパクト

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5

1.6

1 2 3 4 5 6 7 8

D1 cache latency

IPC

分散投機メモリフォワーディングベースライン

提案手法によるゲイン

キャッシュ参照遅延の設定（クラスタ型アーキテクチャでは右の方へシフトする）


まとめ


まとめ• クラスタ型プロセッサのロード命令処理遅延に着目– 参照遅延、発行遅延共に増大– 対策は？　クラスタ内への局所化

• 分散投機メモリフォワーディングの提案– メモリ依存関係を予測して、メモリ依存のある命令同士を同じクラスタへ割り当て

– クラスタ内に小容量のバッファを設け、値を受け渡す• 評価

– 小容量のバッファを加えることにより、ロード命令の30％以上を局所化（高速化）

– IPCへのインパクト


今後の課題• 最適なステアリングの検討

–メモリ依存、レジスタ依存、クラスタ負荷の最適なバランス

• 最適なメモリ構成の検討–バンク分割型、複製型との比較評価

クラスタ型プロセッサのための 分散投機メモリフォワーディング

Documents

クラスタ型プロセッサのための分散投機メモリフォワーディング