最近の話題 2010年10月2日
１．富士通が「京」スパコンの出荷開始を発表
2010年9月28日に富士通は「京」スパコンの出荷開始を発表しました。 全体では，超高性能CPUを搭載したラックが800台以上という規模です。
2GHzクロックのSPARC64 Ⅷｆｘプロセサは1チップで128GFlopsで，ラックに96チップ搭載なので，そのラックが800本とすると，128×96×800＝9.83PFlopsで10PFlopsには不足ですから，800本以上というのは，当然でしょう。
製造は石川県かほく市の富士通ITプロダクツが担当し，そこから神戸のセンターに出荷されるとのことです。
出荷は開始されたのですが，設置，調整を終わって供用開始は2012年の秋という目標で，出荷開始から供用まで2年掛かっています。米国のSequoiaの予定を見ると，納入の開始から供用開始までは1年以下です。そして，その中にはEarly Scienceと呼ぶ，科学研究に使わせる期間が半年近くはいっています。つまり科学ユーザーが使えるようになるのは，納入開始から半年以内です。
納入開始から供用開始までの期間で1.5年の差を付けられているということは，実際の使用開始時期を同じにするためには1世代前の半導体プロセスを使う必要があるということになり，競争力に大きな差がついて しまいます。仕分けで供用開始の前倒し予算が削られてしまったせいもあるのですが，この製造と調整期間のギャップを詰めないと，米国と互角に戦うことはできないと思います。
２．Sandy Bridgeの記述の訂正
9月18日の話題でSandy Bridgeの発表について書いたのですが， その後の情報を総合すると，かなり間違っていたようで，ここで訂正させて戴きます。
Sandy BridgeのCPU，メモリコントローラなどは４つの32Bリングバスで接続と書きましたが，４つのリングバスは，データ，リクエスト，グラント，スヌープのリングで，データリングは32B幅ですが，色々な報道を見ると，どうも1リングのようで す。
そして，「GPU，IMC，PCIe+DMIなどの接続も必要であり，4コアチップでも少なくとも11ストップはありそうです。」と書いたのですが，接続されているエージェントはCPU/LLCが4個とGPU，それにシステムエージェントの6個のようです。しかし，マイコミジャーナルの2010年9月25日の塩田氏の記事の図13を見ると，CPU/LLCとGPUには2個のリングストップがあるような絵が載っています。これを信じると，4コアのSandy Bridgeでは11ストップということになります。
また，メモリコントローラやDMI，PCIeやディスプレイコントローラはシステムエージェントの中に入っている形になっています。メモリからディスプレイコントローラというようなデータの流れはリングに載せる必要はないので，これは妥当です。
従来は逆方向の２つのリングを持ち，近い方を回るというやり方だったと思いますが，コマンドやレスポンスは1方向のリングでないと難しいと思われるので，データも1方向にしたというのは有りそうです。そうすると，コマンドを出してからデータを受け取るにはリングを1周する必要があるので，レーテンシはリングエージェントの位置に関係ないと思うのですが，どうなっているのでしょうね。
また，先週の補遺で，「Nehalemではレジスタからの２本の１２８ビットのオペランドの読み出しが，一方はSIMD FP演算ユニット，もう一方がSIMD INT演算ユニットに繋がっていたのを，Sandy Brideでは256ビットのAVXのHigh側とAVXのLow側に使うことによりハードを節約している」という後藤さんの記事の説明は変だと書いたのですが，変なのは，記事やSandy Bridgeの説明ではなく，元のNehalemの設計でした。FMULと整数のSSE演算器が同じPort-0に繋がっているのだから，本来，レジスタファイルからの読み出しも128ビット1本で良いのを，レジスタファイルのリードポートを 別々に持っていたとのことです。これを従来のFMUL側をAVXの上位側，整数のSSE用のポートをAVXの下位側に使うというのは当然です。NahalemではデータとしてはFMULと整数のSSEを並列に実行できるのですが，命令発行側が両方で一つのポートを共用しているので，こちらの制約で並行には動作できません。
ということで，Intelの説明も後藤さんの記事も正しく，私の読み違いでした。
３．Sandy BridgeのuOPキャッシュ
2010年9月25日にReal World TechnologiesにSandy Bridgeのマイクロアーキの記事が掲載されました。ここには，David Canter氏の詳しい解説が載っています。
それによると，命令は最大32BのWindow単位で扱われ，その単位でuOPキャッシュに記憶されます。uOPキャッシュは32set×8wayで，キャッシュラインの容量は6uOPです。従って，全体では約1.5K uOPということになります。そして，L1命令キャッシュに対してInclusionで，L1I$に入っている命令をuOPに変換したものだけが格納されます。
このキャッシュはトレースキャッシュではなく，Takenの分岐命令が出てくると32Bに達していなくてもキャッシュラインへの格納が切れます。このように使用量が可変なので，各キャッシュラインは何uOP入っているか，x86命令の長さは何Bかなどの情報を持っています。そして，分岐がなくて長いuOPの列が出てくる場合は，最大3wayを連続して使って18uOPのキャッシュラインを作ることができるようになっています。
uOPキャッシュへの書き込みは，まず，通常の実行を行い，コミットした命令列をuOPキャッシュに格納して行きます。そして，命令をフェッチするときは，通常のL1I$とこのuOP$を並列にアクセスしてuOPキャッシュがヒットしたらこちらを使います。
また，Intelのよると，この1.5K uOPのキャッシュは6KBの命令キャッシュ相当で，80%のヒット率とのことです。 トレースキャッシュよりは良いものの，通常のキャッシュと比べると2倍以上のビットを必要としています。しかし，uOPキャッシュにヒットすると，命令フェッチが速くなることに加えて，通常のx86命令のデコーダはクロックゲートされて電力消費が抑えられるので，両方を合わせるとペイするということでしょう。
そして，Canter氏の記事では，uOPキャッシュは32Bの中の最初のデコードされた命令のアドレスでアドレスされると書かれています。しかし，格納形式やタグがどのようになっていて，どのようにヒットを判定しているのかは良く分かりません。
32set×8wayですから，セットを選択する6ビットが必要で，これが最初のデコードされたx86命令のアドレスということでしょうか。例えば，これを最下位の6ビットとすると，残りの上位アドレスビットをすべてタグとすれば，このキャッシュラインを見つけることができます。しかし，この方法では2番目以降の命令をアクセスした場合には見つけることができません。
しかし，命令アドレスを32Bに固定的に区切って，タグの部分にその32Bの中のどの命令を格納しているかを判別できる情報，例えば32ビットのビットマップでuOP化された命令の位置を示す。あるいはライン内に格納されているuOPに対応するx86命令列の始まりと終わりの命令アドレスを格納して，大小比較器を使ってその範囲に入っていることを確認するというような方法を採れば，ヒットの判定は出来そうです。