CPUアーキテクチャについて語れ 8

このエントリーをはてなブックマークに追加
465MACオタ
ここのところPOWER6関連で、海外の掲示板等で紹介されていた特許や論文を漁っていたす。
POWER6に関してわ、高速化の代償として整数演算ユニット(FXU)がインオーダー実行になっている
ことが以前から指摘されていたすけど、これ以外にもコアに機能上のトレードオフとして削減された
部分やや改善が加えられた部分があるす。以下、興味深い点について書き残しておくす。
長くなるかと思うすけど、勘弁して欲しいす。

■レジスタリネームの削除
FXUでOoOEを削ったことに加えて、OoOEを残したFPUやVUでもレジスタリネーム機能を完全に
削っているす。つまり、ちゃんとpowerアーキテクチャで定義された32個レジスタを有効活用しないと、
レジスタ競合で始終パイプランが停止してしまうということになるす。
ただしHPC Linpackの成績を見ると、POWER4/5と同程度のパイプライン段数であるにもかかわらず
リネームレジスタ数を72->120に大増強したPOWER5とそれほど変わらない効率を出しているす
(POWER5: 84.8%, POWER6: 79.6%, 共にp570 16-way)。
命令キューも小さくなっていることでキャッシュにヒットしてデータが連続的に供給される限りわ、
シンプルな構造にしたことが成功していることが判るす。
ちなみにリネームレジスタわ存在しないものの、後述する投機実行機能に使う一時使用のための
レジスタファイルが一セット用意されている模様す。


466MACオタ@続き:2007/06/07(木) 20:56:23 ID:OCp7RXQD
■load/branch lookahead機能
L1キャッシュやTLBのミスで発生する長期のストール時に実行する一種の投機実行機能なんすけど、
「実行」する訳じゃない。。。ってのが面白いところす。
in-orderでリネームレジスタを持たないという設計により、投機実行中にレジスタの書き換え等、
プロセッサの内部状態が変わるようなことが一切できないす。そこで、冬季実行している間の
実行結果わ捨てて、L1キャッシュへのプリフェッチや分岐テーブルの更新のようなプロセッサの
内部状態を変えない動作のみを行うす。ストールが終わって後続の命令が開始されると、必要な
データがL1に入っていたり、分岐予測の精度が上がっていたりして万々歳ということになるす。

この機能、OoOEと違ってパイプラインバブルを埋めることわ出来ないすけど、普通のin-order実行
で問題となるキャッシュミス等での完全停止の対策としてわ面白いす。バブルについてわ高い動作
クロックと整数命令の実行レイテンシを1に削減したことで影響わ少ないという考えだと思われるす。

ちなみに投機実行中に全くレジスタに書き込めないと、本来の目的である後続のload命令や分岐
命令の実行まで行き着くことすらできないんで一時使用のためのレジスタファイルを一セット持って、
投機実行中の演算結果を書き込むようにしている模様す。

467MACオタ@続き:2007/06/07(木) 21:02:26 ID:OCp7RXQD
■プレデコードの強化
私わ以前から「POWER6わNetburstの衣鉢を継ぐ」とか書いているすけど、これもトレースキャッシュ
に近い機能す。RISCでわ下のメモリ階層からL1命令キャッシュに読み込む段階でプレデコードを行う
すけど、以前わ実行パイプラインで行っていた命令のグループ化の大半をこのプレデコードの段階で
行う模様す。
命令ごとに必要とするリソースを示すビットとグループ境界の参考用に使うビットが付加されるために、
L1キャッシュ内の命令わ32-bit幅のpower命令より若干肥大化するす。この肥大化分が64KBという
L1命令キャッシュのサイズに含まれているかどうかわ不明す。

ちなみにFXUのin-order化/FPUのOoOEの規模縮小により命令のcrackingやらmillicoding (より単純な
命令への変換機能)わ無くなった模様す。複数の実行ユニットを使用する命令わ存在するす。
後述の整数乗除算命令なんかわ、その一例す。
468MACオタ@続き:2007/06/07(木) 21:09:05 ID:OCp7RXQD
■命令ディスパッチレベルのSMT
以前に、
http://pc9.2ch.net/test/read.cgi/jisaku/1169393906/818
  ----------------------------
  issue queue内部でOoOE機構を持たないプロセッサにSMTって実装する意味があるすか(笑)
  ----------------------------
なんてことを書いた覚えがあるすけど、なんとPOWER6わ2つのスレッドから7命令をグループ化して
ディスパッチすることでSMTを実現しているす。グループ生成の制限わ、まず優先スレッドから
in-orderかつ所要リソースがダブらないという制限で最大5命令で、残りをサブスレッドから。。。
というモノす。場合によってわサブスレッドの命令のほうが多くなる筈す。

ちなみにPOWER4/5わ命令キューにサイクルあたり5命令のグループをディスパッチして、命令キュー
からアウトオブオーダーで7命令をイシューするという設計だったすけど、OoOEを縮小した分最初から
静的に7命令をイシューするようになったとも言えるす。なんとなく更にVLIW的になったという気もするす。
469MACオタ@続き:2007/06/07(木) 21:14:55 ID:OCp7RXQD
■FPUによる整数乗算/除算の実行
おかげで従来パイプライン化されていなかった整数乗除算がパイプライン化されるす。ただし
スループットわ2。

■FPUの逆数/平方根近似値命令の高精度化
14-bit精度になったとのことす。そのまま使えそうな値すね。

■FPUパイプラインの改善
除算や平方根のようにパイプラインを何周もする長レイテンシの命令がFPUを占有している間に、
前述の一時使用レジスタをその手の命令に回すことで後続の命令をパイプラインに投入できる
ようになっているす。
ただし論文でも「リネームレジスタが無いのでシングルスレッドでの効果わ今一つ」とあるす。
ただし片側のスレッドが除算とかを実行中に、もう一つのスレッドからのFPU命令をどんどん投入
できるそうす。

■単精度浮動小数点わ実行レイテンシが大きい?
倍精度FP演算わ6-cycle後の後続命令に結果をフォワードできるとのことすけど、単精度わ
丸めの追加処理が複雑になるのでフォワードが遅くなるらしいす。
470MACオタ@続き:2007/06/07(木) 21:19:36 ID:OCp7RXQD
■VMX (AltiVec)
VMXのイシューポートが一つだけになって、演算とvpermを同時実行できなくなっているという噂が
流れているすけど、それわ無い模様す。
特許でもVMXユニットが2つ(多分VIU/VFPUとVPERM)という実装例が記述されているし、何より
ダイ写真でベクトルレジスタが2ブロックあって、2つのパイプランが並列実行することを示しているす。
(POWER4以来、IBMの設計わパイプラインごとにレジスタを割り当てている。例えばFXU0とFXU1の
GPRわ別でそれぞれ32個づつある)

どうやらFPUとVMXの関係わ、PPEとよく似ていて命令キューを共有し、FPU命令とAltivec命令を
任意の組み合わせでサイクルあたり2つイシューできる模様す。

謎なのわダイ写真を見る限り、ベクトルレジスタが64-bit幅づつ2つに分割されていることで
四則演算ならともかくシフトやpermuteで不都合が無いのか非常に不思議す。

■リネームレジスタの話の続き
リネームレジスタを削ったかわりに、演算やロードの結果を引数として使う場合の優遇措置わ
色々ある模様す。
471MACオタ@ここまで:2007/06/07(木) 21:22:34 ID:OCp7RXQD
まとめるとベンチマークに現れている高性能っぷりわ、in-order実行の問題であるキャッシュミス等
によるストールが各種の新機軸によってうまくカバーされたことを証明しているかと思うす。
CELLのSPEでわ、そもそもストールが発生しないようにLSを採用した訳すけど、同じIBM社内で
in-orderでの性能向上策として色々考えていることが判るす。
POWER6の手法わ将来のPPEの実装にも適用できるネタであることも今後の注目点じゃないすかね。

IBMわ昔から「割り切った」設計をする癖があるすけど、今回の割り切りネタわ
  「パイプラインバブルわ放置」 
ってところに見えるす。キャッシュ/TLBミスによる長期の停止がIPC低下の主要な原因である
認識わCELL BEの設計方針にも通じるすね。

一方で、数年振りにSPECintの王者の地位を譲ったIntelが今後何をやってくるかわ楽しみす。
IBMと違ってIntelわ 「割り切らない」 会社す。
IBMがPOWER4で「クロックを上げれば命令の実行レイテンシわ多少悪くても良い」と考えた時に、
Intelわ超高クロックのPentium4の上に更に倍クロックのALUを内蔵することで命令のレイテンシを
短縮したす。同じくIBMがデュアルコアわL1をwrite-throughにしてL2で同期すれば良いと考えた時、
IntelわL1をcopy backのままにして、L1間のスヌープを実装したす。
Intelわ既知の性能向上策を決してサボらない会社す。powerを支持する私にとってIntelわ常に
恐ろしい競合相手す。
472MACオタ@補足:2007/06/07(木) 21:23:59 ID:OCp7RXQD
今回参考文献サボったすけど、ほぼソースわあるので質問があれば紹介するす。