きょうはぼやくぞ、別件だけど。(Core 2 Duoのデコード能力) 　　

2006年9月5日


さて、前々回はAMDのATI買収で久々に昔からの主張が的中したのかと大喜びだったのだが、 やはりはしゃぎすぎたのがいけなかったのだろうか？読者様の反応はやはり不人気である。 (プラスにご評価いただいたのは、一部のプロの方のみ。)

と言うわけで、今回はぼやきネタである。 (．．．と思ったのだが、実は解析をして行くうちにぼやく必要があるのか？ないのか？ はっきりしなくなってきて．．．ぼやきネタでは無くなってしまったので、最後に別件でぼやく事となった。)

☆Core 2 Duoは実質何命令/Cycleを目指しているのか？ 　　
今回考えてみたのはCore 2 Duoのデコード能力だ。 参考にさせていただいたのは Intel Core 2 全方位ベンチマーク という記事である。

今回はこの記事のベンチマーク結果からCore 2 Duoは実質何命令/Cycleを目指しているのか考えてみたわけだが、 最初に一言お断りを。

今回の結論は上記記事の結論とは異なる結論になるわけだが、 だからと言って上記記事の誤りを指摘するものではないという点にはご注意いただきたい。 結果の解釈について、「その結論とは別に、こう考えても矛盾はないと思う。」という話であり、 いくつかある可能性のうち別の可能性を当サイトで指摘しているに過ぎないとお考えいただきたい。 繰り返しになるが、上記記事の結論の間違いを指摘している訳ではない。１）

というわけで、注意書きの前置きをして本題に入る。

実は、その記事の (2) Core 2のアーキテクチャを追求する・その1 の中でベンチマークとしてRightMark Memory Analyzerを使用してCore 2 Duoのデコード能力を評価している。

この記事はなかなかに気合いの入ったもので、典型的なベンチマークを数本ズラズラと並べて速い遅いだけを評価．．． といったよくある手抜き記事とは違う読み応えのあるものだ。 そこから導き出される結論は、「命令のフェッチ / デコードの性能に関する限り、CoreはK8と概ね同等であろう。」 というもので、intel自身が強調する４命令デコード能力の重要性とは逆の指摘となっている。

Core 2 Duoのintelの公式見解な特徴として４命令デコード能力とMacro・Micro-Fusion等が挙げられる。 当サイトの評価は、μOPs-Fusionについては以前からその重要性を指摘。 ４命令デコードに関しては、そのデコード能力を生かすためには デコードが４命令並列だけではダメなのであって、並列性の抽出能力と、 実行ユニットの並列数を高める努力も並行して行われていなければならないというもの。 (４命令デコードは重要だが、その能力を生かすためにはスケジューリング能力と実行ユニットの強化が必要という意見。)

このため、 Core 2 Duoの謎として４並列デコードの割に実行ユニット(ポート数)が５ポートと少ない点を指摘したこともある。 (Net-Burst、K8ではそれぞれデコード能力の２倍、３倍の並列処理能力を有する。)

このような背景の中で出てきたのが同記事の見解であり、 「命令のフェッチ / デコードの性能に関する限り、CoreはK8と概ね同等であろう。」という見解だ。 これが正しければμOPs-Fusion系技術の重要性を指摘している当サイトの見解は確かに間違っている事になる。

だが、実際の所はどうなのであろうか？

もちろん、記事通りの読み方でも間違いではないし、それはそれで一つの可能性である。 しかし、ここでRightMark Memory Analyzerの結果について、別の視点から見た当サイト流の解釈を示しておこうと思う。 (なお、ここでは64bitでの結果は扱わないのでご注意いただきたい。また、以下の話はすべてCore 2 Duoの1コア分についての話である。)

それは、RightMark Memory Analyzerで３命令/Cycleの処理能力という結果が得られているのは、 デコード能力が実質的に３命令/Cycleだからと解釈する事でも説明可能だが、 別の可能性として指摘しておきたいのは、このベンチマークではμOPs-Fusionが全く効かず、また その先の実行ユニットの処理能力が３命令/Cycleしかないからだというものである。

RightMark Memory AnalyzerのテストではNOP、SUB、XOR、TEST、XOR & ADDという 命令をひたすら与え続けて処理能力から各種機能ユニットの能力を推測するという方法を行っている。 ここで問題なのは二点。 Core 2 DuoのALUが三つしか無いことと、これら命令の単純な連続では(おそらく)μOPs-Fusion系の機能が働かないことだ。

Core 2 Duoでは５つのポートのうち２つはLOADとSTOREであり、 アドレス計算とレジスタへまたはレジスタからのデータの移動を担当している。 つまり、整数演算での並列性はALUが完全対称だったとしても最大で３命令/Cycleでしかない。

また、NOP、SUB、XOR、TEST、XOR & ADDの命令がそれぞれ連続したとしても 当然Macro-FusionやMicro-Fusionが効くハズもないから、それによる処理能力の拡大も期待できない。 そしてCore 2 DuoのALUはもちろんNet-Burstのような２倍速ALUでも無いから、 ALUの数はサイクル毎に処理できる整数演算数の理論上限に一致するハズである。

つまり、デコード能力が仮に実質４命令/Cycleだったとしても、Core 2 Duo トータルでの処理能力としては３命令/Cycleしか出せないことになる。２） (ブロックダイアグラムについては ここをご参照ください。)

これが何を意味するかというと、実は当サイトの以前の指摘事項である「デコード能力を３命令/Cycleから ４命令/Cycleに強化するのなら、並列性の抽出能力や実行ユニットの数もそれに合わせて強化しなければならない。」 という主張でベンチマーク結果を解釈することもできるという点だ。

命令のデコード能力を３命令/Cycleから４命令/Cycleに強化したにもかかわらず、 実行能力がそれに見合わないために、RightMark Memory Analyzerのテストでは ３命令/Cycleの結果しか得られないというのが当サイト流の解釈である。

実際のアプリではLOAD、STORE系の命令が混じるわけで、特にx86系命令セットではRISC系のCPU命令セットよりその傾向が強い。 従って、４命令デコードはそのような状況を想定して設計されているわけである。 単純に同一の命令がひたすら続くという状況は実アプリからはかけ離れており、 LOAD、STOREユニットがガラ空きであること、およびCore 2 Duoの売りであるFusion系の機能が全く働かないベンチであることの２点が、 ４命令デコードがこのベンチマークで生かされない原因ではないだろうか？

当サイトの解釈で言うと、Core 2 Duoの内部では３命令/CycleのALU処理能力に対しデコード能力が４命令/Cycleであるため、 RightMark Memory Analyzerのテストでは命令キューが溢れかえっていると想像(妄想？)している。

☆ベンチマークでアーキテクチャの特定部分の能力を探るのは結構難しい。 　　
実際の所、x86ではレジスタ数が少ないため純粋なRISCプロセッサと比べると LOAD、STORE命令やレジスタ−メモリ間演算の量が多くなるという傾向がある。 ちなみに、RISCでは原則としてはレジスタ間演算しなかく LOADやSTOREは演算とは無関係にメモリ−レジスタ間のデータ移動を行うだけである。 (LOAD/STOREアーキテクチャ) 従ってx86ではLOAD、STORE系の命令が頻繁に使用されると考えるのが妥当だろう。

もちろん、メモリーレジスタ間演算ではx86命令がμOPs-Fusionによって１命令として処理され、 実行の直前でLOAD命令とレジスタ間演算命令に分解されるため、実行時のμOPsの数は増えても x86命令の処理命令数としては増えない。 しかし、LOAD命令、STORE命令であればx86ベースでも依存関係さえなければ並列実行の機会が増えることになる。

そんな状況下でNOP、SUB、XOR、TEST、XOR & ADDという命令だけが連続して実行されれば、 LOAD、STOREユニットがガラ空き状態となり、 たとえデコード能力が十分だったとしてもALUの処理能力で全体の能力が決まる可能性が高い。 (SUB等でメモリ−レジスタ間演算を含む場合があるが、その場合はLOADユニットの数が１個しかないので 原理上は１命令/Cycleが処理能力の限界となる。したがって、RightMark Memory Analyzerで使われれているSUB等の命令は レジスタ間演算等のLOADユニットを使用しない命令であろう。)

処理全体のスループットを決めるのはシステム内部のボトルネック部分なのであって、 CPU全体の処理量から性能を計測するベンチマークでは特定のユニットの性能に限定して 性能を測定する事は難しい。 断定するにはたくさんの状況証拠を積み重ねて、慎重に考察を進める必要があると思う。

当サイトの解釈と上記のプロの記事の解釈とどちらが正しいかであるが、 これは先に述べたとおりこのようなベンチマークではCPU内部の特定のユニットの処理能力だけを特定して検証する事が難しいため よくわからないのが実情だ。 見えているのは実行した命令に関わるユニットのうちCPU内部で最も処理能力が低い部分の能力である。

しかし、少なくともデコード能力が４命令/Cycleであったとしても、 NOP、SUB、XOR、TEST、XOR & ADDという命令だけが連続して実行されればALUのリソース数から言って ４命令/Cycleは達成できない事は明白で、このベンチマーク結果をもってデコード能力の限界と断定するには今一歩証拠不十分であろう。 (もちろん、これは当サイトの見解に対しても同様で、これだけでは断定することはできない。)

つまり、このテスト結果からは「性能のボトルネックになっている部分の処理能力が３命令/Cycleである。」 とは言えても、「デコード能力の限界から３命令/Cycleである。」と断定するのは難しい。 それはいくつかある可能性の一つであり、当サイトのように「ALUユニット数の限界から３命令/Cycleである。」 と、別の視点から解釈しても一応説明できるのである。

事実、RightMark Memory AnalyzerではDecode Bandwithテストと言いながら、実際にはDecode Bandwithテストの説明が 「Let's estimate key parameters of the I-cache, decoder and execution resources of the processors. 」 となっていて、命令キャッシュとデコード能力だけではなく「execution resources」の寄与がベンチマーク結果に含まれている事を認めている。 このベンチマークはデコーダーの処理能力だけで結果が決まるわけではない点には注意が必要だと思う。

と言うわけで、このベンチマーク結果からは確かに「実質３命令/Cycleの動作」 という結論が導き出されるものの、「どこがボトルネックになっているか？」 については残念ながらこのデータだけでは明らかにはならない。

☆どちらの仮説にも決定的証拠は無いので、状況証拠を探してみる。 　　
このベンチマーク結果だけではCPUの内部動作までは明らかにはできないため、 どちらの解釈が正しいかは今のところ不明である。

しかし、当サイトの新説は先に述べたとおり、命令デコードが「実質３命令/Cycle動作」 というよりはむしろ実行ユニット(ALU)が「実質３命令/Cycle動作」だからだというものだ。

これは単なる我田引水ではないつもりである。 確証こそつかめてはいないが、その状況証拠として下記の例を挙げておきたい。

Platform Benchmarking with RightMark Memory Analyzer Part 3: Intel Pentium III & Pentium M (Banias) Platforms
Detailed Platform Analysis in RightMark Memory Analyzer. Part 7: Intel Sonoma, New Revision of Dothan Core, Pentium M Processor

上記ベンチマーク結果ではCore 2 Duo以外にPentiumIIIやBanias、Dothanのデータが掲載されている。 このデータをご参照していただきたい。

Core 2 Duoでは、NOP、SUB、XOR、TEST、XOR & ADDのいずれでも実質３命令/Cycle動作となっている。 しかし、PentiumIIIやBanias、Dothanでは、この中のいくつかの２Byteコードで１命令/Cycle相当となっている。

ここでPentiumIIIやBanias、Dothanの命令デコーダーと実行ユニットについて考えてみよう。

PentiumIIIやBanias、Dothanでは命令デコーダーはいずれも３つである。 その構成はシンプルデコーダーが２つとコンプレクッスデコーダーが１つ。 Core 2 Duoと異なり、シンプルデコーダーはx86命令１つがμOPs１つになる命令しかデコードできない。

従って上記コードではデコードは３命令/Cycle相当のハズである。 しかし、PentiumIIIやBanias、Dothanでは命令の種類によって１サイクルに実行できる命令数が異なっている。

もしこれが、デコーダーの処理能力に起因するものだとすると、 これはx86命令１つが１μOPsに変換される命令であっても命令の種類によってデコード能力が異なる事になる。 しかし、これは実行している命令がおそらくはすべて１個のμOPsに変換される命令である事を考えれば、intelの公表データとは矛盾する。

もちろん、これをPentiumIIIやBanias、Dothanでも命令の種類によってはデコード能力が実質１命令/Cycleになってしまう．．． という考え方で説明することも一応はできる。 しかし、３命令/Cycleの公称デコード能力で実質１命令/Cycleとすると公称値と実効値の乖離が激しすぎると思う。 (だって、ここを見ればわかるとおり、 単なるスカラCPUであるVIA-C3ですら実質１命令/Cycleなら達成されているんだから．．．) つまり、少なくともPentiumIIIやBanias、Dothanでは命令デコーダーの処理能力に起因するものとは考えにくい。

では、ここで実行ユニットの数について考えてみよう。

PentiumIIIやBanias、DothanではALUは2個である。 しかも、それぞれのALUで実行可能な命令の種類に差がある非対称ALUユニットとなっている。 (非対称になっているのは実際のアプリでは命令の出現頻度に差があるからで、 出現頻度の低い命令は一方のALUで省いてもシステム全体での性能低下は少ないからだ。 もちろん、両方省くと省いた命令は実行出来なくなるので、 少なくとも１つは全整数演算命令を実行できる必要があるわけだが。)

このことを考えると、ALUの非対称性により命令の種類によって実行可能なALUの数が２つになったり １つになったりする事が原因と考えたほうが、 ベンチマーク結果を合理的に説明できるような気がする。 (公称３命令/Cycleのデコード能力で、最大約２命令/Cycle、命令の種類によっては約１命令/Cycleという事実を 現実的に説明しやすい。)

この話はPentiumIIIやBanias、Dothanの場合だから、 Core 2 Duoでは決定的な証拠にはならない。 だが、ちょっと類推を働かせればCore 2 Duoにも当てはめる事が出来る。

また、このデータからはALUの非対称性はPentiumIII→Banias→Dothan という進化の中ではほとんど解消されてこなかったことが推測される。

ちなみに、Core 2 Duoではテストされたすべての命令で実質３命令/Cycle動作となっている。 これをDothan等の結果と比較してみると、 K8コアのように完全対称になっているかどうかは不明だが、 実行ユニットの非対称性は少なくともPentiumIIIやBanias、Dothanよりはかなり解消されていると考えるのが妥当だと思う。

☆別件でぼやく。 　　
ここで当サイトの結論をまとめてみよう。
  1. ４命令並列を謳うWide Dynamic Executionには実は制約が多く、その実質の並列性は３並列＋α程度と考えた方が良さそうだ。 「Core 2 Duoは実質３命令/Cycleを狙ったアーキテクチャである。」という同記事の指摘はその通りだと思う。
  2. だが、その原因は今のところ一つには確定できない。
  3. その原因は命令デコーダーが実質３並列だからと解釈する事も確かに可能ではあるが、当サイトは 実行ユニット(ALU)の少なさが原因とも考えられるという点を指摘しておきたい。
  4. おそらくはK8のような完全対称ALUではないだろうが、ALUの非対称性はPentiumIIIやBanias、Dothanのそれと比べるとかなり解消されおり、 努力の跡が認められる。
  5. ４命令デコーダーはおそらく機能しているがALUの質的改善だけではデコード能力に対応し切れていないというのが Core 2 Duoが実質３命令/Cycleである理由とも解釈できる。(当サイトはこちらの説。)
当サイトはしかし謎は解けない。(趣味のCore Microarchitecture考) においてCore 2 Duoは命令の並列数に対して実行ユニットの数が少なすぎると指摘した。 しかし結局のところ、我田引水になってしまうが、その指摘は正しかったのではないか？というのが RightMark Memory AnalyzerのDecode Bandwithテストの結果で示されているのではないかと考えている。 ぼやく必要があるかどうかは、現段階ではわからないわけだ。

Core 2 Duoのこれ以外のベンチマーク結果が悪くないことから実行ユニット数の少なさをカバーする何らかの方策 が隠されていると当サイトは以前指摘したわけだが、 では、その秘密は何だったかというと一つは同記事で明らかにしてくれた通り キャッシュのバンド幅の改善効果によるものという説には賛成だ。

当サイトは以前からベクトル機などを例に出してメモリバンド幅改善の重要性を訴えてきた立場なので、この主張は納得できる。 また、intelはオンダイキャッシュ系の技術は歴史的に見てAMDより得意であり、この点でも妥当性があると思う。 ただし、賛成ではあるが地味な仕事で、確かにこれはこれで大変な技術ではあるわけだがテクノロジ的な驚きが無いのでちょっとつまらない。 (intelにしてみれば派手だろうが地味だろうが性能が上がれば良いわけではあるが．．．)

そして、もう一つ明らかになったのはALUの非対称性の改善である。

K8並に完全対称ALUかどうかはともかく、DothanまでのプロセッサよりはALUの非対称性が改善されており、 4命令並列というデコード能力の強化に対して、実行ユニット側の数的増強は最小限に止め、 実行ユニットの質的改善でデコード能力強化に対応しようとしたのだと考えられる。３） (ちなみに、この改良がCore Duo→Core 2 Duo段階で行われたのか、Dothan→Core Duo段階で行われたのかは Core Duoでのベンチマーク結果が無いのでわからない。)

しかし、データ供給能力の改善やALUの非対称性の改善といった質的改善だけではやはり実力不足であり、 それが今のCore 2 Duoでのボトルネックであると解釈してもベンチマーク結果とは矛盾しないのではないかと思える。 ４命令同時実行を謳うCore 2 DuoのWide Dynamic ExecutionとはFusion系の技術が生きる状況での話であると思われる。 そうだとすると、それはおそらく消費電力問題の関係で実行リソースの物量的増強を最小限に止めようとしたため生じた制約ではないだろうか？

しかし、こうして考えるとK8コアの完全対称３並列という演算能力はなかなかのものである。 とりあえずベンチマーク結果ではCore 2 Duoが辛勝しているとは言え、 基本設計の年代がK8の方がずっと古い事まで考えれば、Core 2 Duoの性能優位はかなり危ういものであると考えざるを得ない。 基本設計の新しいプロセッサの方が優位なのは当然であり、問題はアドバンテージが開発時期の差に見合うものであるかどうかであろう。

と言うわけで、Core 2 Duoに対するPC雑誌等の評価は高すぎのような気がする。 今、秋葉原ではintelとAMDのベンチマークバトルが行われているが、 intelはＥ系列の性能面でAMDとバトルするよりは、 Ｔ系列でのパフォーマンス/ワット面での優位性をもっと強調するべきであると思うのであるが．．．

当サイトは、今までAMD製CPUをあまり取り上げたことがなかった。 これは、AMDのCPUはメモリコントローラ内蔵のチャレンジを除けば、地味な改良の積み重ねで派手さに欠けるためだ。 Crusoeのような大胆な構想や、Hyper-Threadingのような技術的面白味に欠けるのでネタになりにくいのだ。 (ただし、昔気質の頑固職人のような仕事ぶりであり、地味ではあっても効果的だ。)

だが、ATI買収の件といい、クライアント用途でマルチコアに否定的な考え方といい、 技術的見解は当サイトとよく意見が一致する。 というわけで、Core 2 Duoの世間の評価とは逆に今までAMD製CPUネタを邪険にしていた事をぼやきたい。

Core 2 Duoのデコード能力については当サイトの見解の誤りとは断定できず、今のところぼやく必要は無いようだ。 だが、(大原氏の記事でのメモリバンド幅に対する指摘を別とすれば) では本当はなにが原因かを確定的に指摘できない点では胸の中がモヤモヤしている。 結局よくわからないと言う点では自分の能力不足を認めざるを得ず、こちらの方で大いにぼやいている今日この頃だ。

トリ頭ではやはり深い考察は無理っぽい。 プロの方面に住まう方々で、誰か検討していただけませんでしょうか？　 えっ、自分でやりなはれ．．．ですか。

●補足追加(2006/9/6)

著者ご本人からメールを頂きました。
今回の内容であるが、なんと著者ご本人からメールを頂きました。 ご本人のblogに本件に関する回答が書かれております。

内容の詳細についてはリンク先に書いてある通りだが、当サイトのアイディアにもまだまだ落とし穴があるようだ。 仕事が一段落したらもう少しアイディアを練ってみたいと思う。

驚いたのは掲載当日に早速のメールがあったこと。 さすがにプロは対応が早い。そして、 こんな場末のサイトまで見ているとはプロのライターは情報の把握範囲が広い。

当サイトのコラムについてはともすれば「揚げ足取り」とも受け取られかねない事を心配していたが、 とてもご丁寧な応接で恐縮いたしました。 今後とも良質の記事をお願いいたします。


１）
今回の結論は、「こう解釈する事も出来る。」というものであり、 大原氏の記事が間違っていると主張している訳ではない事には特に注意して欲しい。 今の段階では可能性としてはどちらもあり得ると思う。どちらが正しいかは今後の検討を待たなければならない。

こういうベンチマークは多くのテクニカルライターでは単純にベンチマーク結果を垂れ流して終わるわけだが、 それなら我々アマチュアでも十分出来るわけであり、それじゃプロがお金を取ってやる仕事じゃないと思う。 その点で、この記事はかなりオリジナリティーのある内部構造に関する考察が加えられており、 結論こそ当サイトとは異なるがこのCore 2 Duoの記事は数あるベンチマーク記事の中でもかなり好感が持てるものである。

と言うわけで、本当は同記事をこのように引用するのは避けたかったのだが．．． 今回は他にデコード能力について情報ソースが無く、やむを得ずこのような書き方となった。 もしご本人が当サイトを読んでいたとしたら、決して悪意はないのでその点は平にご容赦いただきたい。

２）
ただしNOPに関しては今時のCPUが本当に実行ユニット経由かどうかは疑問で、 スケジュール段階でNOPが消尽するように工夫されている可能性もあると思う。 NOPのような命令で実行ユニットのリソースを喰ってしまうのは無駄だからだ。

可能性としてはx87におけるfxch命令(スタックトップの入れ替え命令)みたいな状況だ。 この場合は(よほど古いCPUで無い限り)本当にスタックトップを入れ替える必要は無く、単なるレジスタリネームで済むからだ。 このため現代CPUにおけるfxch命令では実行ユニットの内部リソースを消費しない。 と言うわけで、テスト結果はそれでもNOPで３命令/Cycleなので、デコードが実質３命令/Cycleであるという可能性も確かに残されていると思う。

．．．っと、ここまで書いて思いついたのだが、 デコード能力を見たいのだったらfxch命令を４命令に１命令混ぜて実行したらどうだろうか？

この命令は１命令で１μOPsであることはほぼ間違いない上に、デコードリソースは消費するが実行リソースは消費しない。 つまり、これで４命令/Cycle出ればデコードは能書き通り４命令/Cycleでありボトルネックは実行リソースにあるし、 これでも３命令/Cycle止まりならデコードは実質３命令/Cycleであろう。

３）
しつこくなって恐縮だが、この点でも引用元記事の内容を間違いと指摘している訳ではない事にはご注意いただきたい。 同記事でCore 2 DuoのALUを非対称と言っているのはK8と比べてのことであり、 当サイトで対称に近いといっているのはPentiumIIIやBanias、Dothanと比べた場合の話であるからだ。 あくまで異なるベースが基準の相対比較の話である。 要するに、非対称性を良好な方から大雑把に並べれば、K8＞Core 2 Duo＞PentiumIII・Banias・Dothan、ということであろう。