サンディーちゃんマジBridge

詳細きた
https://intel.wingateweb.com/us10/scheduler/catalog/catalog.jsp
(ブラウザの言語設定をen-usにしないと見れないらしい via http://hibari.2ch.net/test/read.cgi/jisaku/1270976684/857)

128bit SSEがふたつになって、256bit AVXになってる(256bitx1ではないので、あいかわらずシャッフルとか水平演算とかが128bit境界越えれなくてキモい)
LLCはリングバスで共有されてる。コアが増えるに従ってスループット最大値が増える。ただし別のコアの近くにデータがある場合はレイテンシが大きくなる…かな？
→ アクセスが特定のキャッシュに集中したらどうなんの？どうやってキャッシュ選択するんだろうか？
→ http://www.anandtech.com/show/3922/intels-sandy-bridge-architecture-exposed/4 レイテンシ最悪値でもNehalemより縮んでるみたい(36->31)。
GPUとCPUでキャッシュを共有してる…のはいいんだが、GPUって結構ストリーム的な挙動をすると思うのだけど、それがキャッシュ汚したりしないのかね？
TurboBoost強化。アイドルから復帰した直後はCPUが冷たくなってるはずなので、その間だけ本気出す、みたいな感じ？ユーザーインターフェースみたいに、殆どアイドル、時々すごくレスポンスが要求されるみたいな状態を想定してる。
デコード後の命令をキャッシュするUop Cache。Pen4のトレースキャッシュとどう違うの？技術的には似たようなものだけど、Pen4→RISCを目指した。Uop Cache→デコーダを休ませたい。と、いったように目的が違うのだと思う。
Uops Cacheは、パフォーマンス、消費電力両方の観点から見てよい。
まずパフォーマンス。Uop Cacheにヒットすると32[bytes/cycle]で命令デコードできる。命令デコード数のピークが4[uops/cycle] である点はCore2と一緒だけど、SSE使ってると、これまでの16[bytes/cycle]では足りない。あとLCPストールが減る(多分)。
次に消費電力。悪名高い可変長命令デコーダを休ませられる。
Uop Cacheは最大80%ぐらいヒットすんじゃね？と、資料には書いてある。

AVX以外はユーザープログラムからは隠蔽されてるところなので、「へぇ、素晴らしいデスネ…」以上のものでは無いね…

GPUがキャッシュ共有ということは、多分かなりレイテンシ縮んでるので、何かに使えそうとは思うが、「キャッシュに乗る大きさでかつドライバのレイテンシを隠蔽できるぐらいの処理だと効果あるよ」というのが条件厳しすぎるので微妙。
PCIがメモリマップでユーザ空間からも見えて、レジスタ直接叩くぐらいのオーバーヘッドだったら、なんかできる気がするが、GPUはコンテキストが大きすぎるので、妄想の世界でも簡単なインターフェースにするのは難しいかと思った…

ところで既に細長いけど、コア数増やす時って、どんどん細長くしていくんだろうか…