問題タブ [cpu-cache]

シミュレーションを書くとき、私の相棒は、キャッシュに収まるほど小さいプログラムを書こうとするのが好きだと言います。これには本当の意味がありますか？キャッシュはRAMやメインメモリよりも高速であることを理解しています。プログラムをキャッシュから実行するか、少なくとも変数をキャッシュにロードするかを指定することはできますか？私たちはシミュレーションを書いているので、パフォーマンス/最適化の向上は大きなメリットです。

CPUキャッシングを説明する良いリンクを知っているなら、その方向に私を向けてください。

C++ で CPU のキャッシュ サイズを決定する方法はありますか? 大量のデータを処理するアルゴリズムがあり、キャッシュに収まるようにこのデータをチャンクに分割したいと考えています。これは可能ですか？キャッシュサイズを念頭に置いたプログラミングに関するその他のヒントを教えてください (特にマルチスレッド/マルチコア データ処理に関して)。

ありがとう！

MESI などのキャッシュ コヒーレンス プロトコルに関して、CPU レジスタと CPU キャッシュの関係はどのようなものですか? 特定の値が CPU のキャッシュに格納され、レジスタにも格納されている場合、キャッシュ ラインが「ダーティ」としてマークされるとどうなりますか? 私の理解では、キャッシュが更新されたとしても (MESI により)、レジスタがその値を更新するという保証はありません。

このコードをヘンチします。

（コンパイラがループ外で「完全」の負荷を最適化していないと仮定しましょう）
私の理解では、値がレジスタ内に保持されているため、「完全」への更新は2番目のスレッドには表示されません（CPU 2のキャッシュはただし、更新します）。

メモリバリアを配置すると、すべてのレジスタが強制的に「フラッシュ」されますか? レジスタとキャッシュの関係は？レジスタとメモリバリアはどうですか？

私はそれらがたくさんあるのを見てきました。NCache、Velocity などですが、それらを比較した表は見つかりませんでした。

次の基準を考慮すると、何が最適ですか。

1. わかりやすい。
2. 最近メンテ中。
3. 無料であるか、十分な無料バージョンがあります。
4. 動作します。

プログラムが取得セマンティクスを使用したロード操作/リリース セマンティクスまたはおそらくフル フェンスを使用したスト​​ア操作を実行すると、CPU のキャッシュが無効になります。
私の質問はこれです: キャッシュのどの部分が実際に無効化されていますか? 取得/解放を使用した変数を保持していたキャッシュラインのみですか? または、キャッシュ全体が無効になっている可能性がありますか? (L1 + L2 + L3 .. など?)。取得/解放セマンティクスを使用する場合、またはフルフェンスを使用する場合、この主題に違いはありますか?

最新の CPU のキャッシュ アクセス速度は? Intel P4、Core2、Corei7、AMD では、プロセッサ クロック ティックごとにメモリから読み書きできるバイト数は?

もしあれば、理論的な数値 (uOPs/tick でのスループットを伴う ld/sd ユニットの幅) と実際の数値 (memcpy 速度テスト、または STREAM ベンチマーク) の両方で回答してください。

PSアセンブラのロード/ストア命令の最大レートに関連する質問です。ロードには理論上のレートが存在する可能性があります (ティックごとのすべての命令が最も広いロードです) が、プロセッサはその一部しか提供できず、ロードの実際的な制限があります。

小さなコードを ARM Cortex A8 プロセッサに移植したいと考えています。L1 キャッシュと L2 キャッシュはどちらも非常に制限されています。私のプログラムには 3 つの配列があります。そのうちの 2 つはシーケンシャル アクセス (サイズ > 配列 A: 6MB、配列 B: 3MB) であり、3 つ目の配列 (サイズ > 配列 C: 3MB) のアクセス パターンは予測できません。計算はそれほど厳密ではありませんが、配列 C にアクセスするための巨大なキャッシュ ミスがあります。私が考えた 1 つの解決策は、配列 C により多くのキャッシュ (L2) スペースを割り当て、配列 A と B には少ないスペースを割り当てることです。しかし、私はできませんこれを達成する方法を見つけるために。ARM のプリロード エンジンを調べましたが、有用なものは見つかりませんでした。

L1 および L2 キャッシュ (データ キャッシュ) のサイズと連想性の順序を (OS にクエリするのではなく) プログラムで測定するにはどうすればよいですか?

システムに関する前提:

• L1 と L2 キャッシュ (L3 の場合もあれば、キャッシュ共有の場合もあります) を持ち、
• ハードウェア プリフェッチ ユニットがある場合があります (P4+ と同様)。
• 安定したクロックソース (tickcounter または gettimeofday 用の優れた HPET) があります。

OS に関する仮定はなく (Linux、Windows、またはその他のものである可能性があります)、POSIX クエリを使用することはできません。

言語は C であり、コンパイラの最適化は無効になっている可能性があります。

Javaメモリモデルで私を悩ませているものがあります（すべてを正しく理解していても）。2 つのスレッド A と B がある場合、A と B の両方が同じモニターで同期しない限り、B が A によって書き込まれた値を参照できるという保証はありません。

スレッド間のキャッシュの一貫性を保証するシステム アーキテクチャでは、問題はありません。ただし、アーキテクチャがハードウェアのキャッシュ コヒーレンシをサポートしていない場合、これは基本的に、スレッドがモニターに入るたびに、以前に行われたすべてのメモリ変更をメイン メモリにコミットし、キャッシュを無効にする必要があることを意味します。そして、それは全体である必要がありますこれは、モニターが保護するメモリ内の変数に関する情報を持っていないためです。しかし、それは、頻繁に同期する必要があるアプリケーションのパフォーマンスに確実に影響を与えます (特に、実行時間の短いジョブを含むジョブ キューなど)。では、Java は、ハードウェア キャッシュ コヒーレンシのないアーキテクチャでも十分に機能するのでしょうか? そうでない場合、メモリ モデルが可視性についてより強力な保証をしないのはなぜですか? 言語がモニターによって保護されている情報を必要とする場合、より効率的ではないでしょうか?

ハードウェアでキャッシュの一貫性が保証されている場合でも、メモリ モデルは両方の世界で最悪の事態をもたらします。同期が絶対に必要であり、一方で、一貫性のないアーキテクチャ (フル キャッシュ フラッシュ) ではパフォーマンスが低下します。では、より厳密にする (モニターによって保護されている情報を要求する) べきではないか、潜在的なプラットフォームをキャッシュ コヒーレント アーキテクチャに制限するべきではないでしょうか?

今のままでは、あまり意味がありません。この特定のメモリ モデルが選択された理由を説明できる人はいますか?

編集：振り返ってみると、strictとloseの使用は悪い選択でした。保証が少ない場合に「厳密」を使用し、反対の場合に「失う」を使用しました。混乱を避けるために、より強いまたはより弱い保証の観点から話す方がおそらく良いでしょう.

同じ機能をプログラムするには 2 つの方法があります。

方法 1:

方法 2:

doAction(int action)関数と関数template<int Action> doAction()が、コンパイル時にインライン化される約 10 行のコードで構成されていると仮定しましょう。呼び出しdoAction(#)はdoAction<#>()in の機能と同等ですが、テンプレート化されていないものは、コンパイル時に引数の値がわかっている場合にコードで適切な最適化を行うことができるため、 doAction(int value)よりもやや遅くなります。template<int Value> doAction()

したがって、私の質問は、テンプレート化された関数の場合、数百万行のコードすべてが CPU L1 キャッシュ (およびそれ以上) を埋めるか (したがって、パフォーマンスが大幅に低下するか)、またはdoAction<#>()現在実行されているループ内の行のみが取得されるかどうかです。キャッシュされた？