« フロリダ7日目〜帰国 | メイン | 夕暮れ »

2006年08月07日

ベンチマーク記事の補足

Core2ベンチマークの完成版が割と好評(?)な様で、3週間もかけてベンチ取った甲斐があるというものである。で、色々な場所でそれぞれ批評を頂いていたりする。

そんなお一つが「Intel Core 2各種ベンチまとめ記事@MYCOM」であるが、やっぱり結論に至る途中過程が判りにくかったようなので、補足。

こちらの記事での指摘、簡単に言えば「Decode段のスループットが3命令/Cycleなので、『実質的にはx86命令で3命令/Cycleを狙ったアーキテクチャである。』と考察しているが、でもALU命令ばっかりしかテストしてないじゃん」という話。

この指摘はその通りなのですが、もう少し話は複雑だったりします。

そもそも判りにくいのが、μOpレベルのIPCとx86命令相当でのIPCの換算。実はCore2に関しては、1つのx86命令が幾つのμOpに変換されるか、今のところ明示的に示されてません。ただ過去の経緯から言えば、x86が1つないし2つのμOpに変換されると考えるべきです。なので、x86でIPC=3を実現するためには、最大6つの実行ユニット(≠ALU)が必要となります。何で≠かというと、1つのx86が2つのμOpになるのは、ALU命令+ロードストア命令、というパターンがあるからで、この場合ALUが6個あっても無駄で、ALU3つとロードストア3つが無いとIPC=3を実現できません。これを馬鹿正直に実装したのがK7/K8ということになります。

んでCore2は?というと、(元記事にも指摘がありましたが)これで指摘があるように、Simple ALUが3組、LoadとStoreが別々に1つという構成。FPUを別にすれば、最大5つのμOpを実行できる計算になります。なので、1つのμOpに変換できるx86命令を上手く組み合わせれば、x86換算でIPC=5が狙えるんじゃないのか?という事でしょう。言い換えれば、今のデコードスループットが3Bytes/Cycleなり6Bytes/Cycleなのは、特定の命令ばっかりまとめて処理してるからこのあたりでピークが来るのであって、もっとバラエティに富んだ命令だったら実行段のスループットがもう少し上がり、結果としてデコードスループットももう少しあがるんじゃないのか?というあたりが指摘されております(解釈が間違っていたらご指摘ください)

で、この指摘に対するお答えですが「その可能性はあるが、微妙」というもの。まずはこちらをごらん頂きたいのですが、そもそもデコード段は最大4命令/Cycleで、うちDecode 0のみ全x86命令を、Decoder 1〜3はSingle μOpのみをサポートしていると明記しています。つまり、デコード段では最大5μOpを生成できる「筈」です。

で、NOPを始めとするSingle μOpに関してはほぼ3μOps/Cycleで実行できていることから、Decoder 1〜3のスループットは1μOp/Cycleであると想像されます。問題はDecoder 0のスループットです。これがどの位か?というのは概ね想像が付きます。それはこれ。LCP(Length Change Prefix)がついた命令はおそらくDecoder1〜3では扱えないのでしょう。結果、0.275命令/Cycleという、かなり遅めの結果になっていますが、Decoder 0はこのあたりが性能の限界ではないかと思っています。このあたりはもう少し様々な命令を突っ込んでみないと断言できないので記事には書かなかったんですが。なので、フルに動いても3.3命令/Cycle(x86換算)程度という可能性が非常に高いと私は考えています。

勿論ここにはMacroOps Fusionの話は一切加味してません。なので、これの効果でひょっとするともう少し性能が上がるかもしれませんが、それでも4命令/Cycleには行かないと思っています。というのは、MacroOps Fusionは2つのALUに対しての命令(こちらの最後でまとめてますが)なので、Load/Storeユニットは使ってくれないからです。

あと、このデコーダ段の制約を抜きに話をすると、Core MicroarchitectureがピークでIPC=5を狙えるというのなら、K7/K8はIPC=6を狙えるアーキテクチャっつーことになっちまいます。K7/K8は一応デコード段がx86命令換算で3命令/Cycleのデコード性能なので、普通に考えるとこんな形でμOpが投入される可能性は低いのですが、今スケジューラに3つのLoad命令がデータ待ちしていて、そこに後から3つのALU命令(例えばNOP)がデコーダからやってきて、これが一斉に実行ユニットに投入されるとピーク時にはIPC=6という事になります。これは別にAMDのみならずIntelのP6/P4も同じなんですが、にも関わらずAMDやIntelがこーいう事を言わないのは「そんなケースは殆どない」からです。上の例(つまり3つのLoadと3つのNOP)のケースでは、確かに投入したCycleではIPC=6ですが、その前はIPC=0(つまりデータ待ちをしている)なので、平均すればやっぱりIPC=3っつーことになりますし。

そういった事も加味して、「Coreではデコード段が最大5μOps/Cycleと言っているけど、実質は(x86で)3命令/CycleそこそこがSustained Rateっぽい。また実行ユニットも最大5μOps/Cycleと言っているけど、x86で換算すると概ね3命令/Cycleがピークっぽい。ということで、『x86命令換算で3命令/Cycleを狙ったアーキテクチャ』とみなすのが妥当であろう」という判断をしております。

というような話は、本当は記事にして原稿料を稼ぐのが賢明なんだろうなぁ(笑)

23:17補足:
というよーな事を書いたら編集部から「勿体無いのでこっちに送ってください」といわれた(笑)。
でも記事にするとTB送ったりコメントつけたりできない(編集部にメールを送っていただければ転送してもらえますが)のと、ちょこちょこ手直しできない(上の文章、5回ほど書き直してます)のがネック。だからといってMYCOM JournalをMTで作れというのも無茶な話だしなぁ。

投稿者 ohara : 2006年08月07日 19:56

トラックバック

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

コメント

はじめまして。詳しい解説ありがとうございます。
結局、x86命令相当で持続IPCが4命令/Cycleを超えるには、Decoder 0のスループットが重要という事ですね。
Intelから資料も出ていないようですし、私は実機で確認出来ないのでなんとも言えませんが、ここの性能次第では評価が変わる可能性有り、と考えています。

追伸.
新しく書いた記事からトラックバックを送信したのですが、上手く送れてない様なのでコメントで書かせて頂きます。
記事のURLはhttp://streakeagle.blog15.fc2.com/blog-entry-625.htmlです。

投稿者 アベント : 2006年08月08日 19:44

コメントしてください




保存しますか?

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