I-Cache/RAM Latency(グラフ13～20)
Trinityにおける結果はこちら(http://news.mynavi.jp/special/2012/trinity/008.html)である。グラフ13～16がNear Jump、17～20がFar Jumpの結果となっている。
まずはNear Jump、特にL2におけるLatencyの低さが明確になっている。ただ、面白いのは、特にNear JumpのForwardのケース(グラフ13)であるが、FX-8350では、
- 0～32KB
- 32KB～64KB
- 64KB～320KB
- 320KB～2MB
- 2MB～8MBv
- 8MB～
と細かくLatencyが変わるところ。0～32KBはL1 Hitである。32KB～64KBは2coreで共通のInst L1を1コアで使い切ろうとすると、多少Latencyが増えるということだろう。64KB～320KBはL1 Miss/L2 Hitのケースだが、これはL1全部(64KB)+L2の256KB分に相当する。FX-8350ではModuleあたり2MBのL2キャッシュを16way Set Assosiativityで構成しており、1wayあたりだと128KBだから、これが2つ分という計算だ。どうもFX-8350ではL2の内部構成がちょっと面白いことになっており、複数wayを検索するときの戻りの時間が変わるようだ。
もっとも、グラフ14～20を見ると、Latencyの絶対値そのものはともかくとして傾きはFX-8150もFX-8350同様320KBまでとそれ以降で差が出ているあたり、本来Bulldozerのアーキテクチャではこんな風に最初もしくは2番目の検索でHitする場合と、3番目以降を検索するときでは所要時間に差があり、ところがZambeziでNear Jumpを掛けた場合にはこれが上手く動かず、大きめのLatencyになってしまっており、これをVisheraで修正した、ということかもしれない。いずれにせよ、L2でのLatencyが多少減る方向の改善がなされているのは、グラフ16までで明らかである。またグラフ15を見ると、L3の領域でも明確にLatencyの差があり、ここでも何かしらの改善があったことが見て取れる。
Far Jump(グラフ17～20)も似た様な傾向ではあるが、グラフの変化は細かく異なる。例えばRandom(グラフ19)で見ると、FX-8350はL1 Hitの領域でもFX-8150に比べ、ちょっとLatencyが多目になっている。その一方で、FX-8150に見られるL2領域におけるバタつきが見られない。Pseudo-Random(グラフ20)ではこの傾向が非常に顕著で、やはり細かいインプリメントに多少手が入っていることが推察される。
次ページ：RMMA - D-Cache/RAM Latency
