私のアプリケーションでは、ある時点で大きな連続ブロックのメモリデータ（100sのMB）で計算を実行する必要があります。私が考えていたのは、私のプログラムが将来触れるブロックの部分を先読みしておくことでした。その部分の計算を実行すると、そのデータはすでにキャッシュに入っています。x86-64のキャッシュにデータをプリフェッチする
gccでこれを達成する方法の簡単な例を教えてもらえますか？どこかで_mm_prefetchを読んでいますが、正しく使用する方法はわかりません。また、私はマルチコアシステムを持っていますが、各コアは異なるメモリ領域で並行して作業することに注意してください。
gccは、低レベル命令のインタフェースとして組み込み関数を使用します。特にあなたの場合__builtin_prefetch。しかし、アクセスパターンが自動的に予測するのが容易でない場合に、これを使用すると、測定可能な差異が見られるだけです。
現代のCPUは自動プリフェッチが非常に優れており、ソフトウェアプリフェッチを開始しようとすると、あなたがうまくいくよりも害が大きいことが分かります。パフォーマンスの問題が実際に発生している場合、最適化のために集中することができる「ぶら下がっている果物」がもっと多い可能性があります。プリフェッチは、数パーセントのスループットが必要なときに最後に試してみる傾向があります。
+1少なくとも10回は先読みを試みました。私は一度だけ目立つスピードアップを得ることさえできました。 （私がコメントにリンクしたもの） – Mysticial
合意 - それほど洗練されていない自動プリフェッチの古いCPUであっても、ソフトウェアプリフェッチの利点を得るのはいつも難しかった。主な問題は、プリフェッチを通常数百クロックサイクル事前に十分なメモリ帯域幅を確保しておく必要があります。これは高性能コードの場合には当てはまりません。 –
プリフェッチは必要でなくてもかまいません。私の現在のアプリケーションでは、メモリアクセスパターンはハードウェアプリフェッチャによって検出されませんでした。残念なことに、これらのアクセスパターンをより先験的なものに変更することは選択肢ではありませんでした。従って - _mm_prefetch。スループットは〜10％低下しましたが、私たちが望むレイテンシ数を達成しました。それは、perfとvtuneを介した多くのプロファイリングの後に行われた、非常に意識的なトレードオフでした。 – quixver
メモリアクセスがシーケンシャルである場合、ハードウェアプリフェッチャはすでにそれを行います。したがって、手動プリフェッチではあまり改善されないでしょう。 – Mysticial
プリフェッチが実際に役立つ場所の例については、この質問を参照してください。http://stackoverflow.com/questions/7327994/prefetching-examples – Mysticial
ハードウェアのプリフェッチャは、何らかの形で私がメモリ内の連続領域を利用していることを認識し、 ？ – pythonic