さて、脱線したので話を元に戻す。先にグラフ8～15あたりで、デコードの最大性能が17Bytes/cycle前後であったが、グラフ42・43でこれがもう少し上、17.3Bytes/cycle程度であることが示された。ここから考えると、やはりL1のスループットは最大18Bytes/cycleで、ただアプリケーションがそこまで使いきれないというあたりな気がする。これはL1だけではない。例えばグラフ42で、L2にあたる32KB～256KBの範囲は最大11.4Bytes/cycle、L3にあたる8MB付近までは最大8.9Bytes/cycleを確保している。普通に考えれば、こんな半端な帯域を構成できるわけが無い。

先ほどデコード段の説明で、ECCをDisableにしてその分を帯域増強に振るという案を一旦引っ込めたが、この結果を見るとやはりECCの分を振り替えている、という気がしてならない。つまり、

  • L1/L2/L3は全てECC付きで構成されている。
  • フェッチ/L1間は144bit、L1/L2間は90bit、L2/L3間は72bitで接続されている。
  • ECCを有効にするとフェッチ/L1間は128bit(=16Bytes/cycle)、L1/L2間は80bit(=10Bytes/cycle)、L2/L3間は64bit(=8Bytes/cycle)で接続され、更に内容がECCで保護される。
  • ECCを無効にすると、このECCの分がそのまま帯域に振り分けられる。

という「仮説」だ。キャッシュ内のECC bitはそのまま維持される(から、データ格納中のエラーは保護される)が、転送中のエラーは検出しない代りに10%内外の転送性能向上を実現した、という理屈だ。

なんでこんな事をしたか、といえばおそらくXeon向けとの差別化ではないか、と思われる。高信頼性が必要なXeonは、データ保存中のみならず転送時のエラー検出が必須になるだろうし、こうした場合は転送もECCつきで行えばよい。その場合、若干の性能面でのデメリットが発生するが、それでもCore MAと同等以上の性能にはなる。一方、Xeonほどの信頼性が不要なデスクトップ向けには、性能側に振ったのではないかというのが筆者の推測である。この推測が本当かどうか、はNehalem-EPで同じ事をしてみれば判るのだが、現時点では確認のしようがないので、これは今後の宿題ということにさせていただきたい。

ところでグラフ39あるいは43で、L3の領域への書き込みで激しくスループットが変動しているが、これはL3キャッシュがUncoreに属することに関係するのではないか、と思われる。Core MAの場合も1MBを過ぎたあたりから多少結果ががたつくが、Nehalem MAはその比ではない。このあたりは後述するLatencyのグラフでは逆に一定であり、そこから考えるにL2→L3コントローラへのアクセスは一定ながら、そこで他のコアからのアクセスがあったりした場合に帯域が減るか、もしくはL3キャッシュ自体がWriteに関してはスループットが安定しないのか、どちらかではないかと想像される。どちらなのか、あるいはそれが何故なのか、といった事までは今回窺い様はないが、特性としてこうした傾向があることは理解しておく必要があるだろう。