0

VsPerfCmd.exe を使用して、インストルメント化されたネイティブ アプリケーションで分岐の予測ミスと最終レベルのキャッシュ ミスをプロファイリングしようとしています。

設定はTinに記載されているとおりに機能しますが、得られる結果は賢明ではないようです。たとえば、常に 24MB のデータ セットにアクセスする関数は、約 2000 回呼び出されたときに、約 700 のキャッシュ ミスしか発生しないと報告されています。これを概観してみましょう - 関数は、12 バイト要素の 1024*1024 要素の 2 つの配列を直線的にトラバースします。すべての要素について、その前または後の要素 1024 インデックスの情報が必要かどうかをランダムに決定します。つまり、キャッシュ ミスを発生させないためには、CPU は常に、キャッシュ内にこれら両方の配列のそれぞれに 1024*12 バイトの少なくとも 3 つのセクションを持たなければなりません。さらに、各反復の後、プロセスは約 8 ミリ秒間 sleep() を使用して CPU を解放します。ハードウェア プリフェッチャーがこれほど優れた仕事をしているとは想像できません。

このばかげた量のデータが、VsPerfCmd が言うよりも多くの最終レベルのキャッシュ ミスを生成しないのはどうしてでしょうか? 私の i7 には 8MB の共有 L3 キャッシュがありますが、これはほとんどありそうにありません。ここで何が起こっているのかについて、誰か意見を共有できますか? もちろん、「VsPerfCmd.exe はひどい」というのは有効な答えですが、誰かがそう言うなら、少なくとも、この主張の根拠として誰かが経験した同様の経験を聞きたいです。

4

2 に答える 2

2

最初に-ハードウェアLLCミスカウンター（それをそれと呼びましょう）は、実際には、特定のアプリケーションでのLLCミスをカウントしません。それが行うことは、すべてのLLCミスをカウントし、その数を事前設定されたしきい値と比較することです（SAVと呼ばれます-値の後のサンプル、通常は数千または数百万のオーダーです）。現在のカウントがSAVと等しい場合、割り込みが発生し、この時点でポイントされているIPはすべて、カウンターとタイムスタンプとともにトレースに保存されます（たとえば、トレースを合理的にするため）。このIPがモジュール内の命令を指している場合、これらのキャッシュミスはすべて、モジュール/関数/命令に起因します。したがって、表示される結果の画像は実際のものではなく、統計的に正しいものです。私はVsPerfCmdを使用していませんが、LLCミスに対して設定されたSAVを確認するのに役立つ可能性があります。それであれば'

次に、アプリケーションのワークロードとワーキングセットの主題。3 x 1024 x 12Bはわずか36KBであり、8MBLLCには何もありません。アルゴリズムが常に前後にジャンプするのではなく、均一に前後にジャンプする場合、頻繁に使用されるのは24 MBのごく一部にすぎません。つまり、最もホットなデータがLLCにも適合する可能性が高いということです。さらに、CPUは、64バイト長のキャッシュラインと呼ばれるチャンクのメモリのみを認識します。したがって、アルゴリズムが次の12バイトにアクセスするために前方またはバックワードにジャンプするたびに、52個の隣接するバイトがL1にロードされるため、ジャンプ後の次のステップが*（ptr ++）の場合、キャッシュミスは発生しません。この次のクォンタムにスケジュールされたスレッドがメモリを大量に消費する他の処理を実行していると思われる場合を除いて、CPUを8ミリ秒使用しても、キャッシュのパフォーマンスに影響はありません。これにより、データキャッシュラインが削除されます。それ以外の場合、バックグラウンドで進行しているOSスレッドが数バイトに触れているだけであれば、大規模なキャッシュの削除は発生しないはずです。

于 2012-04-26T09:44:13.733 に答える
2
于 2012-04-14T09:32:17.080 に答える