Prescott発表前夜(短所の補強編)   

2004年2月1日




☆短所の補強   
さて、先日からの続きである。

では、短所の補強を考えてみよう。 まずは、分岐予測ミスとキャッシュミスに弱いという弱点について考えてみる。

既に公開されているのが分岐予測機構の改良プリフェッチ機構の改良である。

これは、Net-Burstアーキテクチャの欠点を考えれば当然予想できた対策である。 なぜならば、深深度パイプライン方式最大の欠点はキャッシュミスと分岐予測ミス であるからだ。あたりまえのことではあるが、 分岐予測機構の改良は分岐予測ミスを減らし、プリフェッチ機構の改良は キャッシュミスを減らす。

追加された13個の新命令に明示的プリフェッチ命令が無いことから、 プリフェッチ機構の改良はハードウエア方式である事が予想される。

Net-Burstアーキテクチャでは数回データミスが続くと発動し、256byte先の内容を キャッシュライン2つ分取り込むというデータプリフェッチ機構が 既に内蔵されている。 しかし、これは行列計算等の定型的データ処理には効くかもしれないが、 一般論としては取込先決め打ちのこの方法では効果的とは言い難いだろう。

従って、この辺りを決め打ちではなく、何byte先を取り込むかの 予測機構付きプリフェッチに改良したりするのではないだろうか?

なお、Net-Burstアーキテクチャのもう一つの欠点として 滅茶苦茶に電気を喰うことがある。

電気バカ食いの解決としては90nmプロセスの採用という方法を与えたわけであるが、 それがうまくいかなかったのは余人の知るところである。 この点については、現状では白旗で降参状態。 今後のプロセス改良を待たねばならないようだ。

☆低IPCをいかに克服するか?   
もう一つの短所は低IPCであることだ。 世間的には、同時実行命令の上限がAthlonXPの9命令に対し、 Pentium4では6命令しかないことが原因とされている。 つまり、低並列が低IPCの原因であるとされている。

しかし、たるさん的には以前に述べた通り、パイプライン段数が多いことによる キャッシュミス・分岐予測ミスのペナルティー増大が最大の原因と見ている。 これらは不可分の関係だろう。

だから、低IPC克服の一番良い解決策は実行ユニットを増やすことではなく、 パイプライン段数を減らすことだと思う。 なぜならば、パイプラインストール中のゼロIPC状態が一番IPCを落とすからだ。 その点では、IPC対策=分岐予測ミス対策・キャッシュミス対策でもある。

しかし、この対策は「高クロック化」というNet-Burstアーキテクチャの根本に 抵触するため考えられない方法である。 あちらを立てればこちらが立たずである。

では、どうするのがよいのだろうか?  分岐予測機構改良とプリフェッチ機構の改良は先に述べたので、 それ以外で考えてみよう。

まず、よく言われている実行ユニットの増強による高IPC化であるが、 単独で実行ユニットだけ増強してもあまり効果がないだろう。 なぜならば、Hyper-Threadingの導入により命令デコード能力の限界が 近くなっているからである。

Pentium4では平均2.1命令/サイクルの動作だそうだが、 Hyper-Threadingで30%高速化するとされているので、 Hyper-Threading動作中は2.1命令/サイクル×1.3倍=2.73命令/サイクル のIPCとなる。

しかし、Net-Burstアーキテクチャでは3命令/サイクルでしかμOPsを取り込めない。 このため、実行ユニットだけ増強しても限界がすぐ近いのである。 (分岐予測ミスでパイプラインが破棄される可能性を考えれば、 余裕が0.27μOPsしかないのはマズイ。)

このため、たるさんはPrescottではμOPsフェッチの能力が高められるのでは、 と考えている。 (以前はトレースキャッシュの読み込み能力を強化せよと主張した事もある。)

しかし、Web記事の情報からは、命令フェッチ能力の強化は無い事が 既に明らかになっている。命令フェッチ能力の強化は、 すなわちパイプライン本数の増強なので結構な大変革になる。 トランジスタ資源をもう少し喰わない方法で達成したいというのが、 たぶんintelの本音なんだろう。

では、トレースキャッシュの読み込み能力を強化せずに μOPsフェッチ能力を増やす方法は無いものであろうか?

☆μOPs-Fusionの導入を進言する。   
実はこれがintel自身によって既に成し遂げられているのである。 それはPentium-Mで導入されたμOPs-Fusionテクノロジだ。

μOPs-Fusionでは、Fusion可能な命令対が見つかると 二つのμOPsを一つの代替μOPsに置き換える。

その上で、パイプラインを通った代替μOPsはリオーダーバッファ寸前で 本来のμOPs2つに置き換えられて、リオーダーバッファに投入。 その後、実行されるのである。

つまり、μOPs-Fusion発動中は1本のパイプラインで2本のパイプラインと ほぼ同等の働きをするのである。

これなら、μOPs-Fusion可能かどうかの検証&置換ステージと、 代替μOPsの本来のμOPsへの分解ステージという2つのステージを 追加するだけで済む。

Pentium-MでのμOPs-Fusion効果はスケジューリングするμOPsが10%以上 減ったことに相当するそうである。 Fusion可能な命令対はPentium-MとPrescottではたぶん違うであろうから (μOPsの命令セットがPrescottとPentium-Mで同じとは思えないから。)、 同じ割合と断じる事は危険だが、他に推測する方法もないので同じと仮定してみよう。

すると、実質的フェッチ能力は10%アップして3.3命令/サイクル相当となる。

Hyper-Threading導入前のPentium4ではトレースキャッシュからの読み込み能力 3命令/サイクルに対し、IPCは2.1命令/サイクル。 つまり能力比は43%ほどデコード能力 (Pentium4ではトレースキャッシュからの読み込み能力)が上回っている。

しかし、Hyper-Threading導入後には余裕度はIPCが2.73命令/サイクルまで 高まるので、デコード能力の余力は10%にまで低下してしまう。 これでは、命令供給能力が不足してパイプラインストール直後の 並列性が高まらないだろう。 車で言ったら加速の悪い鈍重なスポーツカーみたいなものだ。

では、μOPs-Fusion導入後ではどうだろうか?

デコード能力が3.3命令/サイクルまで高まった事に相当するため、 余力は21%まで回復するのである。 十分とは言えないが、ずっとマシになる事がおわかりいただけるだろう。

これにより、パイプラインストール回復直後の並列性回復における立ち上がり加速が 速くなると思われる。(分岐予測ミスが発生すると、リオーダーバッファ内のμOPsも 破棄されてしまうので、ストール回復直後の並列性がどれ位になるかは、 μOPs読み込み能力の余力に大きく依存すると予想される。)

☆μOPs-FusionはNet-Burstアーキテクチャと相性がいいハズ。   
実はこのμOPs-Fusionであるが、Pentium-MよりもPrescottの方が相性が いいのではないだろうかと考えている。

μOPs-Fusionに関しては、Pentium-Mのアーキテクチャに関する詳細が非公開のため ブロックダイアグラムが書けない。だから、μOPs-Fusionと同等の技術を 既に搭載済みでブロックダイアグラムが公開されているAMD64系CPUのアーキテクチャと 比較してみよう。

AMD64系アーキテクチャの場合
1次命令キャッシュ
フェッチ
デコード1
デコード1
デコード1
デコード2
デコード2
デコード2
パック パック パック
アンパック アンパック アンパック
それぞれの実行ユニットのスケジューラへ


AMD64ではデコードした命令2つをいったんパックし、スケジューラ直前で再度 アンパックしてスケジューラに引き渡す。 やっていることもその狙いもμOPs-Fusionとほとんど違いはないハズである。

では、これをNet-Burstアーキテクチャに当てはめてみよう。

Prescottの場合(推定1)
トレースキャッシュ
フェッチ
デコード1
デコード1
デコード1
デコード2
デコード2
デコード2
パック パック パック
アンパック アンパック アンパック
それぞれの実行ユニットのスケジューラへ


まず推定図1は、μOPs-FusionをAMD64同様にそのまま組み込んだ場合だ。 これでも、AMD64の場合と同様な効果は出るだろう。

しかし、トレースキャッシュの保持内容は既にμOPsであるため、 トレースキャッシュの読み込み能力は6命令/サイクルまで拡大させなければならない。 なぜならば、パイプライン3本分すべてがμOPs-Fusion発動可能な命令だった場合、 Fusionする前のμOPsは2倍の6命令必要になるからだ。

パック以降のパイプライン段数は3本のままで良いが、 トレースキャッシュのフェッチ能力は2倍必要になるのである。 PrescottではμOPsのフェッチ能力は増やされていないとのことだし、 仮に増やしたとしても効率が悪い方法である。

☆Net-Burstアーキテクチャの特性を生かして改良してみる。   
では、もう少し知恵を働かせてみよう。Net-Burstアーキテクチャに最適化した、 より改良された構成を考えてみた。

Prescottの場合(推定2)
  2次キャッシュ  
  フェッチ  
  デコード1  
  デコード2  
  パック  
   
トレースキャッシュ
フェッチ
デコード1
デコード1
デコード1
アンパック アンパック アンパック
それぞれの実行ユニットのスケジューラへ


Net-Burstアーキテクチャでは、トレースキャッシュ前段のFrontEndPipeでx86命令を μOPsに変換する。 この構成では、μOPsのパックをFrontEndPipeで行ってしまう。 (図中、細めの幅で図示している部分がFrontEndPipe部分である。) トレースキャッシュにはパック済みの代替μOPsで記憶されるのである。

この方法では、コンベンショナルな推定1の構成と比べ、 いくつかのメリットがある。まとめると下記の通りだ。

  1. 分岐予測ミスのペナルティー増大を最小限にくい止められる。
  2. トレースキャッシュの容量を実質的に増やすことができる。
  3. デコード・パック回路が1/3で済む。(消費電力削減にも寄与する。)
まず、1.について考えてみよう。

μOPs-Fusionを導入すると、パック・アンパックのステージが増える事により パイプライン段数が増えるため、分岐予測ミス・キャッシュミスのペナルティーが 増えてしまうという欠点がある。これでは本末転倒だ。

しかし、トレースキャッシュでパイプラインを分断する構成の Net-Burstアーキテクチャでは、パックステージをトレースキャッシュ以前に 持っていくことができる。

こうすることで、トレースキャッシュにヒットする限り パック段の影響を受けなくする事ができるわけだ。 アンパック段はトレースキャッシュ以降なので、 影響ゼロとまでは行かないが、コンベンショナルな方法よりはダメージが少ない。

ループ処理等繰り返しの多い処理では、実質的低段数パイプライン化 が可能となるだろう。

2.はどうだろうか?

コンベンショナルな方法(推定1)ではトレースキャッシュには 普通のμOPsが納められている。 この場合、μOPs-Fusionの有無にかかわらずキャッシュ容量は同じだ。

しかし、μOPs-FusionをFrontEndPipeに持ってゆくとどうだろう?

トレースキャッシュにはμOPs-Fusion後の融合された 代替μOPsが混じって納められる事になる。 この場合、2個のμOPs-Fusionを1個で置き換えるため、 必要なキャッシュ容量が減る。

つまり、μOPs-Fusionにより10%命令が削減できれば、それは 10%分だけトレースキャッシュを増やしたのと同じ効果が得られるのである。

Net-Burstアーキテクチャではトレースキャッシュを増やす効果が他のCPUより大きい。 (非常に深いパイプラインだから。) しかし、高クロック化のために容量を増やしにくいという欠点がある。 このため、μOPs-Fusionによる実質的容量アップは効果的ではないだろうか?

3.はどうだろう?

これは簡単な話だ。トレースキャッシュに命令がある限り FrontEndPipeは動作する必要がない。 これはμOPs-Fusionされた命令でも同様である。

だからパックステージは1つでも、コンベンショナルな推定図1での 3つとほぼ同じ効果が得られるのである。 これはNet-Burstアーキテクチャがトレースキャッシュでパイプラインを 2つに分ける方式だから使える技である。 (たしか、こういうのをデカップルド・アーキテクチャというと思ったが... 間違っていたら済みません)

というわけで、μOPs-Fusionは本家Pentium-MよりNet-Burstアーキテクチャの方が 向いているのではないだろうか?

☆まとめ   
既に公開されている短所の補強は分岐予測機構の改良とかプリフェッチ機構の 改良であり、まさに正統派的改良である。 消費電力対策は90nmプロセスであったが、これがうまくいかなかった事は 衆知の通り。

低IPCの克服には実行ユニットだけ増やしてもダメであると考えている。 いかに高並列性を抽出するかという問題を解決してからでないとムダだろう。 しかし、それには大きなダイコストと手間がかかる。

というわけで、低IPC克服には今のところHyper-Threadingの強化が一番良いと思う。 Prescottは小改良バージョンなので、 大きくダイをいじらなければならない選択枝は選べないという前提があるからだ。

さて、「短所の補強」であるが、たるさんオリジナルのアイディアは トレースキャッシュ前後に分断配置されたμOPs-Fusionである。 しかし、報道されている情報を総合しても、μOPs-FusionがPrescottに 内蔵されているという情報は今のところまったくない。 こうした方が良いと思うのであるが、「予想」としても的中する確率は低いだろう。

だから、μOPs-Fusionの導入はPrescottのアーキテクチャ予想ではなく、 たるさんからの「提言」としたい。

明日はPrescottの発表である。どうなっていることだろうか?