この傾向は、CMP命令においても継承される。グラフ6が2Bytes(cmp eax,eax)、グラフ7が4Bytes(cmp ax, 0x00)、グラフ8～11が6Bytes(cmp eax, 0x00000000 / cmp eax, 0x0000007f / cmp eax, 0x00007fff / cmp eax, 0x7fffffff)の命令デコードだ。
グラフ6で6.5Byte/cycle、グラフ7で13Bytes/cycleだからどちらも3.25命令/cycleであるが、問題はグラフ8以降で、ピークが17Bytes/cycleとなっており、これだと2.83命令/cycleという計算になる。
Core MAは16Bytes/cycleというキャッシュからの転送がボトルネックになるわけだが、Nehalem MAの17Bytes/cycleという数字はやや理解に苦しむものがある。まさかL1→デコードの帯域が17Bytes/cycleに増量されたとも思いがたい訳で(バス幅を136bitとかにすれば可能だろうが、それも考えにくい。ECCを無効にしてその分帯域を増やすのであれば、17Bytes/cycleではなく18Bytes/cycleになるだろう)、この余分な1Bytes/cycleがどこからひねり出されたかはちょっと謎である(当初はLSDか? とも思ったが、筋の通った説明が出来ないので、この案も放棄することにした)。
この17Bytes/cycleという数字は一定のようで、Prefixed CMPのテスト(グラフ12～15)でも一定であった。こちらは命令長が8Bytesになるから、Core MAだと2命令/cycleになるのが、Nehalem MAでは2.125命令/cycleになる計算だ。総じて、デコード段に関してはComplex Decoderの機能追加、及びほんのわずかながらL1→デコーダへの帯域強化によって、微妙にパフォーマンスアップが図られたと考えてよさそうだ。
