【特集】Intel Core 2 全方位ベンチマーク - 新アーキテクチャの真実を見極める (5) Core 2のアーキテクチャを追求する・その4 | パソコン

注目情報

特設サイトの必見情報

【特集】

Intel Core 2 全方位ベンチマーク - 新アーキテクチャの真実を見極める

5 Core 2のアーキテクチャを追求する・その4

2006/08/02

大原雄介

さて、次はDecode段である。先に4命令/Cycleのデコードと紹介したが、実際には全ての命令をデコードできるのはDecoder 0のみ(Photo06)。Decoder 1～3はSingle μOpのみがハンドリングできるとしている。つまり1つのμOpsに変換できるx86/x64命令ならば4命令/Cycleが維持できるが、2つのμOpsに変換される命令では1命令/Cycleに落ちてしまうことになる。このあたりはプレゼンテーションでも多少説明があった(Photo07)が、要するにデコード段そのものというよりも、renaming / allocationの制約ということらしい。

Photo06:P6アーキテクチャの"Simple Decoder / Complex Decoder"を連想させる作りになっている。

Photo07:このプレゼンテーションも多少変更があり、まず見出しは"Decode issues a maximum of 4 uOps per clock"から"Decode issues a maximum of 4 uOps for renaming/allocation per clock"。また2行目も"- For example, a single four uOp instruction is all that can be decoded in a single clock"から"- For example, a single four uOp instruction is all that can be renamed/allocated in a single clock"になっている。また最後に"- For example, 4-1-1-1 can be decoded in one clock - However, 2-2-2-1 takes three clocks to decode"といった追加が。

次いでExecutionである。完全OOO(Out of Order)らしく、ROB(Reorder Buffer)が装備されているのは当然であるが(Photo08)、このスピードはどんなものか? をちょっと確認してみた。

Photo08:Reservation Stationがスケジューラと別に用意されたのは、Execution Unitを効果的に利用しようという工夫だろう。主要な命令は1cycleで処理できるとしているが、これは各命令毎のスループットとレイテンシが出てこないとなんとも評価しにくいところ。

グラフ16～18は、RMMAのMicroArchitecture→I-ROBを使い、ROBを使う場合のレイテンシを測定してみたものだ。

K8はForward / Backwardで、概ね50Cycle前後。もっとも160命令を超えたあたりから次第にレイテンシは増えて行くが、それでも100Cycle未満。これがNetBurstになると、最低でも100cycleといったところ。Random Accessの場合も加味すると、概ねK8の倍というところか。

Coreはというと、丁度K8とNetBuestの中間という感じだ。最小で100cycleといったあたりだが、Randomでも280cycke程度だから、NetBurstよりはやや速い(なぜかPseudo-Randomが遅めなのが気になるが)程度。ただそこからNOP Countが増えてもあまりレイテンシが増えないのが判る。とはいえ、最後までK8と比べて50Cycleほど大目のLatencyが掛かってる、ということには違いがないようで、あまり高速という感じはしないのが正直なところだ。

さて話を戻す。実行ユニットは最大6μOpsのDispatchが可能としている(Photo09)。もっともDispatch≠Executeであって、実際はそこまでの性能は出ない。Load / Storeは相変わらずまとめて1つづつで、このあたりはNetBurstの流れを汲んでいる感じである。ただ、通常のALU命令に関してはともかく、SSE系命令に関しては色々指摘されているあたり(Photo10)、XMMレジスタへの操作には注意が必要なようだ。


Photo09:ここで言われている内容はそれほど珍しくない。しいて言えばLCPに絡むあたりを多少考慮する必要がある、という程度。	Photo10:"XMM subject to partial stall, too"は"Partial XMM updates subject to dependency delays"と明確にされていた。

ただこれも冷静に考えるとちょっと変な感じではある。というのは、SSEに関してはわざわざ処理ユニットを分割することで、最大4つのSSE命令をMacro-Fusionとは別に処理できる構造にしているからで、ここに示された問題が起き易いことは先刻承知の筈だ。にも関わらずこうした制限が付くというあたりで、Core Microarchitectureの内部がちょっと窺い知れる。