http://d.hatena.ne.jp/issei_y/comment?date=20100501§ion=1272668964#c
によると、なんか最近のチェスソフトは手動プリフェッチで高速化とかしてるらしい。へー
面白いのはprefetch乱用ソフトの最右翼だったLinuxはprefetchを削除する方向に話を進めていることである。
最近はIntelがプリフェッチを推奨してないのよ。CPU内蔵の自動プリフェッチのほうが石の内部事情に
詳しいので。
なのでインテルコンパイラがプリフェッチ命令を削除してしまうケースがあるというのはおそらく意図的な
ものじゃないかな。
昔のCPUは自動プリフェッチとか弱かったから意味あったんだろうけど・・・
によると、なんか最近のチェスソフトは手動プリフェッチで高速化とかしてるらしい。へー
面白いのはprefetch乱用ソフトの最右翼だったLinuxはprefetchを削除する方向に話を進めていることである。
最近はIntelがプリフェッチを推奨してないのよ。CPU内蔵の自動プリフェッチのほうが石の内部事情に
詳しいので。
なのでインテルコンパイラがプリフェッチ命令を削除してしまうケースがあるというのはおそらく意図的な
ものじゃないかな。
昔のCPUは自動プリフェッチとか弱かったから意味あったんだろうけど・・・
- 関連記事
-
- [Linus先生のgit講座] このバグはいつ入ったの? (2010/05/17)
- prefetch (2010/05/15)
- OpenSSL 1.0.0 released (2010/03/30)
Intel CPU の hardware prefetch はストライド付きメモリアクセスをストリームと認識できるだけのはずなので、RDBMS やガベコレのようにメモリアクセスがほとんど予測不能なものや、「フィボナッチ数列でインデックスアクセス」のようなロジックはあるものの CPU に判定不能なものは、software pfetch が利き続けると思います。
ただ昨今は hardware pfetch がストリームとして認識できる本数がどんどん増えています(Core 系はメモリ→キャッシュで12ストリーム)ので、メモリアクセスパターンが異なる複数のスレッドで hardware pfetch が混乱するから software prefetch を書くというのはなくなっていくのかも知れません。
それに Intel x86-64 CPU の Out-Of-Order 実行機能はデタラメに強化され続けています。Core i7 は re-order buffer が 128 μOPで、48 load buffer を持っているので、分岐予測が当たる限り μOP換算で 128 命令の範囲に(依存のない)ロードアクセスは投機的にメモリリードしてしまいます。Software prefetch を書くならこの効果分よりも離して書かないと意味がないので、どんどん software prefetch を書くのは難しくなって行きますな。
ただ昨今は hardware pfetch がストリームとして認識できる本数がどんどん増えています(Core 系はメモリ→キャッシュで12ストリーム)ので、メモリアクセスパターンが異なる複数のスレッドで hardware pfetch が混乱するから software prefetch を書くというのはなくなっていくのかも知れません。
それに Intel x86-64 CPU の Out-Of-Order 実行機能はデタラメに強化され続けています。Core i7 は re-order buffer が 128 μOPで、48 load buffer を持っているので、分岐予測が当たる限り μOP換算で 128 命令の範囲に(依存のない)ロードアクセスは投機的にメモリリードしてしまいます。Software prefetch を書くならこの効果分よりも離して書かないと意味がないので、どんどん software prefetch を書くのは難しくなって行きますな。
問題は、CPUのモデル非依存で効果のあるprefetchって書きようがないって事なんだと思います。
CPU世代変わるたびにOSの書き直しとかやってられんし。
CPU世代変わるたびにOSの書き直しとかやってられんし。
2010-05-15 土 12:38:25 |
URL |
kosaki #- [ 編集]