>>18
> そもそもRISCやショートベクトル機のプリフェッチ命令わメモリのレイテンシを隠ぺい
> する程度のもので，ロングベクトル機のようにパイプラインそのものの一部でわ無いす。
> ハードウェアの複雑さわ，AltiVecユニット全体でせいぜい4百万トランジスタ，面積に
> して10mm.sq@180nmくらいすから現在の半導体プロセスでわ，もはや問題にならないす。
プロセスルールやトランジスタ数だけで決まる問題ではないです。
でも、MACオタさんがそう考えているというのなら、現在の参照資料だけで このまま議論しても平行線をたどるだけですね。
もう少しちゃんとした資料をもってきます。キャッシュの way 数に関するものも含めて。

> プリフェッチわメモリ-プロセッサ間とプロセッサ内部の速度差を埋めるものす。
> プロセッサ内部が十分高速な現在，プリロードでレジスタ迄送る必要わ無いし，
> マルチプロセス環境でわむしろ有害す。
私の立場の確認ですが、
2,4,8ライン数で連続したキャッシュラインを読みこんで来るようなプリフェッチ命令を問題にしているのではないです。
ストライドを付けて複数ブロックを読みこむマイクロアーテキクチャの立場に立てば「優秀なプリフェッチ命令の例(元スレの690)」とは言えないだろうという立場です。

プリロード命令に関しては説明不足だったかも知れません。
私が意図していたのは従来型のレジスタに転送するタイプのものではなく、
元スレの 707 で挙げたような scrratch pad に対するプリロードや、
あるいは IA-64 のスタック汎用レジスタのバッキングストア動作のようなものを想定しています。

あと、マルチプロセス環境の問題は当然考えています。
ですから、私は数値計算アプリと条件を付けています。
分かってもらえると思うのですが HPC アプリのことです。

> プリフェッチの有効性わ，むしろコアとBIU (Bus Interface Unit)の並列動作にあると
> 見るべきすね。
プリフェッチ一般に関してはそうです。