現在またはすべてのプロセスについて、CPUキャッシュ（L1、L2など）に現在存在する値、メモリアドレス、および/またはその他の情報を正確に判断する方法はありますか？
私は、CPUキャッシュをより効果的に利用するためにプログラムを最適化する方法を示すかなりの読書をしてきました。ただし、特定のアプローチが効果的かどうかを真に判断する方法を探しています。
結論： CPUキャッシュに何が入り、何が入らないかを100％確実にすることは可能ですか。
このトピックを検索すると、キャッシュサイズを決定する方法に関するいくつかの結果が返されますが、内容は返されません。
編集：以下のコメントのいくつかを明確にするために：ソフトウェアは間違いなくキャッシュを変更するので、CPUメーカーはこの機能を提供するツール/ハードウェア診断システム（組み込み）を持っていますか？
専用のハードウェアを使用しないと、CPUキャッシュにあるものを直接検査することはできません。ソフトウェアを実行してCPUキャッシュを検査するという行為は、キャッシュの状態を変更します。
私が見つけた最善のアプローチは、アプリケーションの実際のホットスポットを特定し、コードが本番環境で実行されるハードウェア（または、本番環境を制御できない場合はさまざまなハードウェア）で代替アルゴリズムのベンチマークを行うことです。
Eric J.の回答に加えて、大手チップメーカーがそのようなツールを持っていることは確かですが、そのような「デバッグ」機能があなたや私のような一般の人間に利用可能になる可能性は低いと付け加えます。たとえそうだったとしても、それはあまり役に立たないでしょう。
なんで？キャッシュにトレースしたパフォーマンスの問題が発生している可能性は低く、キャッシュヒット率を高く維持するためのよく知られた「常識的な」手法では解決できません。
コード内の他のすべてのホットスポットを本当に最適化しましたか？CPUによるキャッシュの動作が悪いことが問題ですか？私はそれを非常に疑っています。
さらに、思考の糧として：プログラムの動作を1つまたは2つの特定のCPUのみに最適化したいですか？結局のところ、キャッシュアルゴリズムは、キャッシュのパラメータと同様に、常に劇的に変化します。
Windowsを実行している比較的最新のプロセッサを使用している場合は、 http：//software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-を参照してください。使用率 とそれがあなたが探しているもののいくつかを提供するかもしれないかどうか見てください。
別のCPUで実行するときに、CPUキャッシュサイズに関する仮定が間違っていると、この最適化が機能しなくなるため、特定のCPUキャッシュサイズを最適化することは通常無駄です。
しかし、そこには方法があります。特定のアクセスパターンを最適化して、CPUが次に読み取る必要のあるメモリ位置を簡単に予測できるようにする必要があります（最も明白なものは、線形に増加する読み取りです）。CPUを完全に利用できるようにするには、すべてのメモリアクセスがCPUキャッシュに完全に収まるまで、問題がある程度サブパートに分割される分割統治戦略に従うキャッシュ忘却アルゴリズムについて読む必要があります。
別々のコードとデータキャッシュがあることにも注意してください。Herb Sutterは、CPUの内部について詳しく説明している、すばらしいビデオをオンラインで公開しています。
Visual Studio Profilerは、メモリおよびL2カウンターを処理するCPUカウンターを収集できます。これらのオプションは、インストルメンテーションプロファイリングを選択するときに使用できます。
Intelはまた、これらのCPUカウンターについて、WindowsとLinuxのタスクマネージャーが何を示しているか、そして多くの異なるレベルで内部的に非同期で並列に動作する今日のCPUにとってどれほど間違っているかについて詳しく説明しているオンラインペーパーも持っています。残念ながら、このようなものを直接表示するためのIntelのツールはありません。私が知っている唯一のツールはVSプロファイラーです。おそらくVTuneにも同様の機能があります。
コードを最適化するためにここまで進んだ場合は、GPUプログラミングも検討する必要があります。SIMD命令に頭を悩ませたり、局所性をキャッシュしたりするには、少なくともPHDが必要です。おそらく、元の設計の5倍になります。しかし、アルゴリズムをGPUに移植することで、まともなグラフィックカードではるかに少ない労力で100倍になります。CUDAをサポートするNVidiaGPU （現在販売されているすべてのカードはCUDAをサポートしています）は、Cダイアレクトで非常にうまくプログラムできます。GPUのフルパワーを活用するためのマネージコード（.NET）のラッパーもあります。
OpenCLを使用することでプラットフォームにとらわれないままにすることができますが、NVidiaOpenCLのサポートは非常に悪いです。OpenCLドライバーは、対応するCUDAドライバーよりも少なくとも8倍低速です。
「キャッシュ不可」として構成されたメモリ（通常はグラフィックカードのフレームバッファメモリ）を読み取っていない限り、使用するほとんどすべての操作がキャッシュに保存されます。「キャッシュにヒットしない」もう1つの方法は、「非一時的」な特定のロードおよびストア命令を使用することです。それ以外はすべて、CPU自体の内部のターゲットレジスタに到達する前にL1キャッシュに読み込まれます。
ほとんどすべての場合、CPUには、キャッシュに何を保持し、何を破棄するかを知るためのかなり優れたシステムがあり、キャッシュはほぼ常に「満杯」です。たとえば、作業している場合、必ずしも有用なものである必要はありません。巨大な配列を経由すると、多くの「古い配列」が含まれます[これは、保存されないデータの読み取りや書き込みを可能にするため、「非一時的な」メモリ操作が役立つ場所です。キャッシュ内では、次に同じポイントに戻ったときに、キャッシュ内にはありません]。
そして、はい、プロセッサには通常、キャッシュの内容を検査できる[カーネルドライバでアクセスできる]特殊レジスタがあります。ただし、キャッシュの内容を失うことなく使用するには、かなり注意が必要です。また、「キャッシュ内の配列Aの量」タイプのチェックとしては、明らかに役に立ちません。これらは特に、プロセッサが正常に動作していない場合に、「うーん、キャッシュライン1234が壊れているようです。キャッシュされたデータを読み取って、実際に本来あるべき値であるかどうかを確認したほうがよい」ためのものです。
DanSが言うように、適切なソフトウェアから読み取ることができるパフォーマンスカウンターがあります[これらのレジスターを使用するにはカーネル内にある必要があるため、そのための何らかの「ドライバー」ソフトウェアが必要です]。Linuxには「perf」があります。また、AMDには同様のパフォーマンスカウンターのセットがあり、たとえば、「この期間に発生したキャッシュミスの数」や「Lでのキャッシュヒットの数」などを確認できます。