六月の日記/メモ |
▼
2005.06.05(日) 00:40:41
X-bit Labs の
プレスコット: モヒカン族の最期? (Pentium 4: ウィラメットからプレスコットまで。)
という記事がおもしろかった。
今まで話されることのなかったNetBurstアーキテクチャの真の姿(と思われるもの)について納得のいく解説をしている。
英語だし長いので最初の方をページ毎に適当に要約。
10ページ目あたりからは詳しく自分で読んでほしいので14以降省略。
- Northwoodを対象とした実験でL2キャシュの遅延がどうしてもドキュメントの値より大きくなる。それも数十クロックも。
- キーワードは、"replay"。Intelの特許の中で、「マイクロオペレーションの繰り返し処理のための特殊装置」に関する抽象的な記述を発見。
- Appendix 3 プロセッサイベントカウンターについて。 イベントの種類は数百もある!
- VTuneのカウンタで公開されているのは一部のみ。
どう考えても多すぎる数のカウンタがundocumented。これはなにかある!
以降の章ではその何かについて、我々が突き止めた答えを解説する。
- その前に、重要なところを少し押さえておく必要がある。
スケジューラは実行ユニットの待機状態を最小にするよう最大の努力をしないといけない。←ここポイントなので覚えておくように。
CPU命令は、前の命令の結果が得られる前にパイプラインに投入される。
- 命令間に依存関係があるとき、スケジューラに出来ることとはなにか？
(最初の命令がロード命令だったとして)
選択肢その１ L2キャッシュの遅延にあわせて次の命令を送る。
→ぜんぜんだめ
- その２ L1キャッシュにヒットした事が分かったら即座に次の命令を送る。
→やっぱりだめ。実行ユニットに命令が到達するのに時間がかかりすぎる。
- その３ L1キャッシュの遅延にあわせて次の命令を送る。つまり
前の命令の結果が得られる前でも、前の命令を送った2クロック後に次の命令を送る。
結局これしかない。
- 最初のロード命令がL1キャッシュにヒットしなかったらどうなるのか？
L2キャッシュは7クロックの遅延なので、正しいデータが届く頃には、
命令は間違ったオペランドで計算を終えてしまっている。
- もちろんそんなことは許されない。
そのためにPentium4には特別な仕掛けが用意されていて、
正しく実行するためのお膳立てが出来なかった命令はパイプラインから追い出され、
replayという横道に送られた後、もう一度パイプラインに入るようになっている。
- replayに送られた命令は、輪を描くようにしてパイプライ の入り口に戻るが
その輪の長さがちょうどL2キャッシュのレイテンシに合っている。
replayからの命令が来た時にはスケジューラからの命令は送られない。
- 特筆すべきは、長いパイプラインのための、このreplayという対策は、
一見とても論理的に見えながら、実は劇的なパフォーマンス低下の原因になるという事である。
しかしながら、だからと言ってreplay抜きにパイプラインを長くすることは出来ない事なのだ。
- まだ疲れたなんて言わないよね？ ここからが大事だし面白いんだから。
命令が一つreplayに入ると実行ユニットに１サイクルの待機状態が発生する。
それだけでなく、一つの命令がreplayに入るとたいていの場合いくつかの命令を 道連れにする。
極めつけとしては、たった一回のキャッシュミスで長さ数千の命令列が数百回もreplayを回る例さえ作ることが出来た。
命令列が何回もreplayループを回るという状況について詳しく見てみよう。
不思議に思うかも知れないが、これが起きるのは仕事熱心なスケジューラのおかげなのだ。
...- (以下省略)
17ページ目に、「FPU,MMX,SSE命令は基本的にreplayを使わない」とある。
replayを使わないから、Pentium4は、SSEを多用するような場合にはちゃんと速いのだろうか？
20ページ目には、「Intelがreplayの存在をひた隠しにしているのは、
否定的印象を与えずにこれを説明するのが難しいからだということは分かる。... マーケティングと詐欺とは紙一重であるが、この場合マーケティングは一線を越えてしまっているように思う。」ともある。
replayの解説を聞いた後なら、Intelの言うところの「投機的実行」が何を指していたのかよく分かる。
そして、よく言えば投機的で、悪く言えば単に無駄の多い作りなんだと納得した。全くその通り。
▼
2005.06.23(木) 15:28:54
アンナミラーズで初の食べ放題企画があるというので食べてきた。
キャンペーンの内容は以下の通り。