« 夕暮れ | メイン | 64bitがわかる »

2006年08月10日

ベンチマーク記事の補足の補足

このエントリと、このエントリに対する簡単な補足など。

x86命令レベルでIPC=4を目指すためには何が必要か、を考えると3つの要件が出てきます。

(1) デコーダがSustainedで4命令/Cycleのデコードが可能なこと
(2) スケジューラが、Sustainedで4命令/Cycle相当のμOpsを送り込めること
(3) 実行ユニットが、Sustainedで4命令/Cycle相当のμOpsを実行できること

で、実は(1)と(3)はすごく簡単。要するに力技でデコードユニットと実行ユニットを並べれば済みます。当然キャッシュ帯域とかメモリ帯域はより高い性能が必要になるわけですが、これはCPUコアの外の問題なので、ここでは割愛。

で、一番難しいのはおそらく(2)です。つまり命令間の依存関係を上手くほぐして、独立に実行可能な様にすることで、これがうまく行かないと幾らデコーダや実行ユニットを並べても、実効性能が低いまんまということになります。

そもそもK7→K8でIPCが20%ほど向上してるわけですが、これが何で成し遂げられたかというと、デコード→スケジューラ段の見直しなんですね。これは両方のパイプラインを比較するとわかります。で、今のCoreが、んじゃIPC=4に耐えるだけの依存関係解消能力を持っているか、というと甚だ怪しい気がします。

あとDecoder 0のスループット。これでも判るとおり、NOPですらIPCは2.9命令/Cycle程度になってます。そもそもRMMAでNOPをひたすら投入した場合に、それをどのDecoderで処理するかが明確になってないんですが、仮にNOPの場合はDecoder 0〜3が均等に使われるとします。そうすると、スループットの期待値はDecoder 0のスループットをα、Decoder 1〜3のスループットを1とすると

仮にDecoder 0のスループットをαとすると、
((α+2)×3+3)÷/4
つーことになります。で、この結果が2.9なわけですから、計算すると
α=(2.9×4)÷3−3≒0.87(命令/Cycle)
というあたりですね。

で、一番疑ってるのは「仮にNOPの場合はDecoder 0〜3が均等に使われる」という前提そのものだったりします。つーのは、そもそもCoreはFetch/PreDecodeのステージで、Length Markingの処理を行う訳ですが、この時点でSingle μOpかどうか判断ができる訳です。で、Single μOpと判ってるものを、わざわざComplex Decoderに送り込むかなぁ?と。このあたりはもう少し考察しないといけないんですが、そんな非効率的な事はしないんじゃないかなぁ、というのが私の率直な感想です。つまり、Decode 1〜3がそもそもスループットが1よりちょい少なく、結果としてIPC=2.9程度になっている、と。
ただこれを確認するためには、LCP以外で2つのμOpsになるようなx86命令で同じことをやってスループット確認しないといかんのですが、まずプログラム考えるところから始めないといけないのがなんとも(苦笑)

つーわけで、そのうち時間ができたら何か書くかもしれません。出来ない気もするけど(自爆)

投稿者 ohara : 2006年08月10日 04:41

トラックバック

このエントリーのトラックバックURL:
http://www.nekobaka.com/cgi-bin/MT-3.11/mt-tb.cgi/152

コメント

コメントしてください




保存しますか?

(書式を変更するような一部のHTMLタグを使うことができます)