問題タブ [cpu-cache]

先週、スレッド間の通信を可能にするための小さなスレッド クラスと一方向メッセージ パイプを作成しました (明らかに、双方向通信のためにスレッドごとに 2 つのパイプが必要です)。Athlon 64 X2 ではすべて問題なく動作しましたが、両方のスレッドが同じ変数を参照していて、各コアでこの変数のローカルにキャッシュされた値が同期していない場合、問題が発生するのではないかと考えていました。

volatileキーワードが変数をメモリから強制的に更新することは知っていますが、マルチコア x86 プロセッサですべてのコアのキャッシュを強制的に同期させる方法はありますか? これは私が心配する必要があることですか、それとも軽量ロックメカニズム (私は揮発性パイプ変数を設定するために _InterlockedExchange を使用していました) の揮発性および適切な使用は、マルチコア x86 CPU 用の「ロックフリー」コードを記述したいすべてのケースを処理しますか?

クリティカル セクション、ミューテックス、イベントなどについては既に認識しており、使用したことがあります。どの力を認識していないか、キャッシュの一貫性を強制するために使用できるx86組み込み関数があるかどうか、私は主に疑問に思っています。

2*512 KB の L2 キャッシュと 1 MB の L2 キャッシュの違いは何ですか?

250 MB のデータをストリーミングするアプリケーションがあり、データ チャンク (それぞれ 2 つの 32 ビット ワード) にシンプルで高速なニューラル ネットしきい値関数を適用します。(非常に単純な) 計算の結果に基づいて、チャンクは予想外に 64 個のビンの 1 つにプッシュされます。つまり、1 つの大きなストリームが入って、64 の短い (可変長) ストリームが出てきます。

これは、さまざまな検出関数で何度も繰り返されます。

コンピューティングは、メモリ帯域幅が制限されています。これは、はるかに計算量の多い判別関数を使用しても速度の変化がないためです。

メモリ帯域幅を最適化するために新しいストリームの書き込みを構造化する最良の方法は何ですか? 特に、キャッシュの使用とキャッシュ ラインのサイズを理解することが、これに大きな役割を果たしているのではないかと考えています。64 個の出力ストリームがあり、運が悪かったために多くが同じキャッシュ ラインにマップされたという最悪のケースを想像してみてください。次に、次の 64 ビットのデータをストリームに書き込むときに、CPU は古いキャッシュ ラインをメイン メモリにフラッシュし、適切なキャッシュ ラインにロードする必要があります。これらはそれぞれ 64 バイトの帯域幅を使用します... したがって、帯域幅が制限されたアプリケーションは、メモリ帯域幅の 95% を浪費している可能性があります (ただし、この仮想的な最悪のケースでは)。

効果を測定しようとすることさえ難しいため、それを回避する方法を設計することはさらにあいまいです. それとも、ハードウェアが私よりもうまく最適化するゴーストボトルネックを追いかけているのでしょうか?

違いがある場合は、Core II x86 プロセッサを使用しています。

編集：これはいくつかのサンプルコードです。配列を介してストリーミングし、その要素を疑似ランダムに選択されたさまざまな出力配列にコピーします。同じプログラムを異なる数のデスティネーション ビンで実行すると、同じ量の計算とメモリの読み取りと書き込みが行われたとしても、異なるランタイムが得られます。

2 出力ストリーム: 13 秒
8 出力ストリーム: 13 秒
32 出力ストリーム: 19 秒
128 出力ストリーム: 29 秒
512 出力ストリーム: 47 秒

512 を使用する場合と 2 つの出力ストリームを使用する場合の違いは 4 倍です (おそらく??) は、キャッシュ ラインの削除のオーバーヘッドが原因です。

アルゴリズムのプロファイリングと最適化を試みていますが、さまざまなプロセッサに対するキャッシュの具体的な影響を理解したいと考えています。最近の Intel x86 プロセッサ (Q9300 など) では、キャッシュ構造に関する詳細情報を見つけるのは非常に困難です。特に、プロセッサの仕様を掲載しているほとんどの Web サイト ( Intel.comを含む) には、L1 キャッシュへの言及が含まれていません。これは、L1 キャッシュが存在しないためですか、それとも何らかの理由でこの情報が重要ではないと見なされているためですか? L1 キャッシュの廃止に関する記事や議論はありますか?

[編集] さまざまなテストと診断プログラム (主に以下の回答で説明されているもの) を実行した後、私の Q9300 には 32K L1 データ キャッシュがあるように見えるという結論に達しました。この情報を入手するのが非常に難しい理由について、私はまだ明確な説明を見つけていません。私の現在の作業理論では、L1 キャッシングの詳細は現在 Intel によって企業秘密として扱われています。

これは主観的な質問のように聞こえるかもしれませんが、私が探しているのは、これに関連して遭遇した可能性のある具体的な事例です。

1. コード、キャッシュを効果的/キャッシュフレンドリーにする方法 (キャッシュヒットを増やし、キャッシュミスをできるだけ少なくする)? 両方の観点から、データ キャッシュとプログラム キャッシュ (命令キャッシュ)、つまり、データ構造とコード構造に関連するコード内の事柄は、キャッシュを有効にするために注意する必要があります。

2. コードキャッシュを有効にするために、使用/回避する必要がある特定のデータ構造はありますか、またはその構造のメンバーにアクセスする特定の方法などはありますか?

3. プログラム構造 (if、for、switch、break、goto、...)、コード フロー (if 内の場合、for 内の場合など) はありますか?

一般的にキャッシュ効率の高いコードを作成することに関連する個々の経験を聞くことを楽しみにしています。任意のプログラミング言語 (C、C++、アセンブリなど)、任意のハードウェア ターゲット (ARM、Intel、PowerPC など)、任意の OS (Windows、Linux、Symbian など) などを使用できます。 .

多様性は、それをより深く理解するのに役立ちます。

マルチコア CPU またはマルチプロセッサ システムで使用されるキャッシュ メモリに関していくつか質問があります。（プログラミングとは直接関係ありませんが、マルチコアプロセッサ/マルチプロセッサシステム用のソフトウェアを作成する際に多くの影響があるため、ここで質問します！）

1. マルチプロセッサ システムまたはマルチコア プロセッサ (Intel Quad Core、Core two Duo など) では、各 CPU コア/プロセッサに独自のキャッシュ メモリ (データおよびプログラム キャッシュ) がありますか?

2. 1 つのプロセッサ/コアが互いのキャッシュ メモリにアクセスできますか? 互いのキャッシュへのアクセスが許可されている場合、その特定のプロセッサのキャッシュにデータがなく、他の 2 番目のデータが含まれているシナリオでは、キャッシュ ミスが少なくなる可能性があるためです。プロセッサのキャッシュにある可能性があるため、メモリから最初のプロセッサのキャッシュへの読み取りを回避できますか? この仮定は有効で真実ですか?

3. 任意のプロセッサが他のプロセッサのキャッシュ メモリにアクセスできるようにすることに問題はありますか?

Shark を使用して L2 キャッシュ ミスをチェックしようとしていますが、うまくいきません。他のすべての Shark サンプリング モードは問題なく動作します。

CPUキャッシュの内容を読み取る方法はありますか? アーキテクチャは ARM 用です。

アドレスの範囲を無効にしていますが、それが無効になっているかどうかを確認したいと考えています。アドレス範囲の読み書きは無効化の有無と無効化チェックなしでできるが、キャッシュの中身を読めるか知りたい

ありがとう！！

問題があります.... while ループで配列にデータを書き込んでいます。そしてポイントは、私がそれを本当に頻繁にやっているということです。この書き込みがコードのボトルネックになっているようです。したがって、メモリへの書き込みが原因であると推測されます。この配列はそれほど大きくありません (300 要素程度)。問題は、キャッシュに保存し、while ループが終了した後にのみメモリに更新するという方法で実行できるかどうかです。

[編集 - アレックスが追加した回答からコピー]

まず、回答をくださった皆様に感謝いたします。確かに、コードを配置しないのは少しばかげていました。だから私は今それをすることにしました。

それだけでした。どなたかアイデアいただけると助かります。重ねてお礼申し上げます。

敬具 アレックス

WindowsでCPUキャッシュフラッシュを強制することに興味があります（ベンチマークの理由から、CPUキャッシュにデータがない状態でエミュレートしたい）、できれば基本的なC実装またはWin32呼び出し。

システムコールでこれを行う既知の方法はありmemcpyますか？

Intel i686 プラットフォーム (P4 以降でも問題ありません)。