RightMark Memory Analyzer 3.8その1「Instruction Decode」(グラフ42～56)

cpu.rightmark.org
http://cpu.rightmark.org/

ということでいよいよRMMAの結果を見てみたいと思う。まずはDecode(グラフ42～55)から。NOP(グラフ42)ではL2 Hitの範囲でどのCPUも4Bytes/cycleを実施している。HaswellにしてもRichland/Kaveriにしても、すでにNOPそのものは実行しない(スケジューラで空のEntryを突っ込むだけ)から純粋にデコード性能だけの話になるのだが、ここからKaveriでもDecodeがピークで4命令/cycleであることが確認できる。

もともとBulldozer/Steamrollerの世代まで、Fetch/Decodeは2つのCoreで共有構造であり、これがSteamrollerではコアごとにDecodeを分離する構造になった。(Photo04)4命令/cycleであったBulldozer/SteamrollerのDecode部が、Steamrollerでどうなるのかが注目のポイントであったのだが、結果から言えばSteamrollerでは2つの4命令/cycleのDecoderが動いていることになる。

Photo04:ただここまで行くと「Fetchも分けちゃえばいいのでは?」という疑問は当然湧く。通常、フロントエンドはIn-OrderのPipelineで動作することになるが、この仕組みだとフロントエンドがFetchとDecodeで非同期動作する形になるからだ。あるいは次はそうなるのだろうか?

もっとも、この4命令/cycleは本当にピーク値であって、実効性能はぐんと下がる。2バイト命令のSUB(グラフ43)以下、Kaveriのスループットは2命令/cycleを常に維持しており、基本的に「SteamrollerでDecoderは2つに分離はされたものの、DecoderそのもののスループットはPiledriverまでと大きくは変わらない」という感じがする。

実際、資料にもDecodeの命令数そのものが増えたとはどこにも書いてない(Photo05)。結果としてフロントエンドが30%のIPC改善ということになってはいるが、Decode段に手が入るとすると、次のExcaliburからという事になるのかもしれない。

Photo05:I-Cacheの大容量化、Dispatch Sizeの拡大、分岐ミスの削減が主な骨子。で、Dispatch Sizeの拡大はDecodeというよりもSchedulerだし、I-Cacheや分岐予測精度向上はFetchの項目だから、Decoderには殆ど手が入ってないのかもしれない

なおグラフ47(CMP #2)以降でKaveriとRichlandを比較した場合、最初のたち下がりのピークが異なっているが、これはSteamrollerコアでL1 I-Cacheを増量(64KB 2-way→96KB 3-way)した事による影響と思われる。

ただ、まるっきりDecoderに手が入ってないわけでもないようだ。グラフ56はPrefixed NOP Efficiencyで、無駄にPrefixを増やしていった場合のスループットを測定するものだが、Richlandは非常にこれが低く、Haswellは(途中でなぜか谷があるものの)大分マシといった感じ。

で、Kaveriは少なくともPrefix3つまではある程度高速に処理できるように内部を改善したようだ。ただ4つ以降はその最適化が効果を及ぼさないといった感じになっている。

こうしたものがどこまでIPCの改善に繋がるか、というとやや「?」マークではあるのだが、Steamroller世代ではDecoderはコアごとに分離するのが主なテーマで、改善は「取りあえず出来るところを若干」という程度な感じだ。