RightMark Memory Analyzer 3.8(グラフ25～52)
cpu.rightmark.org
http://cpu.rightmark.org/
ということで、久々のRMMAである。このテストはCore i7-975とCore i7-2600Kに項目を限っている。またこのテストに当たってはIntel Turbo BoostをDisableにして実施している。まずグラフ25～32がDecode Bandwidthである。
あまりに変わりすぎなのでまとめて説明すれば、
- Decoderの構成そのものは、相変わらずSimple Decode×3＋Complex Decode×1という構成は変わらない。これは、XOR命令(グラフ27)やTEST命令(グラフ28)で、Core i7-2600Kのグラフが0～32KBの範囲でなだらかにカーブを描きながら、最終的に3命令/Cycleで収束していることで確認できる。
- Zeroing Idiomsの威力はすごい。これはNOP命令(グラフ25)とかXOR/ADD命令(グラフ29)が、ほぼL1の範囲では4命令/Cycleを維持できていることからも明白である。μOp Cacheは最大でも1.5KOpsだから、こんなに大量の命令は保持できない。[Zeroinf Idiomsの説明は塩田氏の記事](http://journal.mycom.co.jp/articles/2010/09/25/idf09/index.html)を参照していただくとして、このZeroing IdiomsはComplex/Simple両方のデコーダに実装されており、これに該当する命令はComplex Decodeでもスループット1で処理されることが確認できる。
- 命令L1→Fetchの帯域幅も32Bytes/cycleに増量された。データ側に関してはLoad Unitを二重に装備したことで32Bytes/cycleの帯域を持つようになっている。これはAVX命令を処理するためには必要な対応であるが、これに併せてFetch(というか、命令L1)の帯域も拡張されたようだ。これは命令長の長いCMP命令 #5(グラフ31)とかPrefixed CMP命令 #1(グラフ32)から明らかである。従来は命令L1→Fetchの帯域が16Bytes/cycleで、Fetchの速度もこれでクランプされていたのが、これで解消されているのが判る。
- 1.5KμOpのTraceCacheも明確に効果を出していることが判る。XOR命令(グラフ27)やTEST命令(グラフ28)などで、先頭1.5KB強(実質2KB程度)の範囲でほぼ4命令/Cycleを維持し、その後なだらかに数字が下がってL1の32KBまでの範囲でほぼ3命令/Cycleに接近するというのは、最初の1.5K分をうまくTrace Cacheで賄えていることを意味している。
といった感じになる。意外にZeroing Idiomsの威力が大きい事を実感したが、それ以外にも有力な併せ技を多数用意しているというのが印象的であった。また、これは直接Decodeには関係ない話であるが、L2以降のスループットもやや高めとなっており、こうした部分も処理性能に影響してきそうだという感じがする。
次いで、ROB(Re-Order Buffer)周りのテストをグラフ33～34に示す。グラフ33はForward/Backward、グラフ34はRandom/Pseudo-Randomの結果である。まずグラフ33から判るとおり、ROBの持ち方そのものは大差ないが、Latencyは5cycle程度削減されており、またNOP Countが増えていった際のLatencyの増え方もゆるやかになっている事が判り、このあたりでLatency削減の仕組みが何かしら入ったものと思われる。一方グラフ34だが、まずRandom Accessに関しては、Sandy BridgeではROBのエントリ数を増やしたことが既に報じられており、これがそのまま反映されているように見える。Pseudo-Randomに関しては、NOP Countが少ない範囲ではほぼ同一だが、そこから段々差が出てくるという傾向はグラフ33と同じで、このあたりはLatency削減の仕組みがそのまま効果を及ぼした、と考えていいだろう。
グラフ35～39はD-Cache/RAM Bandwidthである。グラフ35～37がRead/Write/Copyの結果であるが、ことReadに関する限りSandy Bridgeの帯域は、
| L1 |
32Bytes/cycle |
| L2 |
18Bytes/cycle |
| L3 |
9Bytes/cycle |
といったところで、Nehalemの、
| L1 |
16Bytes/cycle |
| L2 |
10Bytes/cycle |
| L3 |
8Bytes/cycle |
を大幅に上回るものになっている。またWriteについては、L2までは同じだがL3では7Bytes/cycle程度を維持しており、このあたりも増強されていることが判る。結果としてグラフ37のCopyの結果もそれなりにCore i7-2600Kが上回るものになるのは当然だろう。特徴的なのはL2の範囲の結果で、Core i7-975もRead/Writeだけだと9Bytes/cycleが維持できるが、Read/Writeを交互に行うと6Bytes/cycle程度に収まっている。ところがCore i7-2600はここでも8Bytes/cycle弱を維持しており、こうした細かいところでの改善が行われているようだ。グラフ38～39はMemory Read/Writeの速度で、Core i7-2600Kが、
| Read |
5.0Bytes/cycle強 |
| Write |
3.2Bytes/cycle弱 |
なのに対し、Core i7-975は、
| Read |
4.3Bytes/cycle強 |
| Write |
2.7Bytes/cycle弱 |
でしかない。なるほど先ほどのRMMTの結果も納得である。
グラフ40～43はD-Cache/RAM Latencyを個別に示している。先ほどグラフ9～11でも示した話だが、Latencyそのもので言えば、L2/L3共にややCore i7-2600Kの方がCore i7-965より大きい事を示しているのがお判りいただけよう。もっともSequential AccessはともかくRandom/Pseudo-RandomになるとL3では逆にCore i7-2600Kの方が良い傾向を示しているのも明確に判る。このあたりはLLCを複数個に分割しており、理論上同時に複数のLLCの検索が同時に可能になっているあたりが効果的に作用しているのではないか、と思われる。
グラフ44～49はD-Cache Assosiativityのテストを実施したものだ。どのテストも128 Entryでテストを実施しており、一方先にPhoto45などで示した通りL1/L2は8way、L3は16wayの構成だから、128 Entryもデータを突っ込むと間違いなく飽和する。なので段々Latencyが上がってゆくのは問題ないのだが、面白いのはCore i7-975がどのグラフをみても鋭いスパイク状のカーブを描くのに、Core i7-2600Kでは比較的なだらかなグラフになっている事だ。L1/L2ともに共通なところを見ると、このあたりも改善が施されたのだろう。
最後がTLBのサイズ(グラフ50～52)である。元々NehalemではL1 TLBが64Entry、L2 TLBが512Entryある構成で、この仕組みはSandy Bridgeもそのまま継承しているように見える。異なるのはこのL2 TLBも溢れた場合で、本来ならばL2ないしL3 Cacheでカバーされるものだが、このケースでのLatencyがCore i7-2600Kの方が多いのは、やはりL2/L3のLatencyが多いためだろうと想像される。
