問題タブ [cachegrind]

これはcachegrind出力の一部です。コードのこの部分は1224回実行されました。elmg1は、サイズ16 x 20のunsignedlongの配列です。私のマシンのL1キャッシュサイズは32KB、64Bキャッシュラインサイズ、8ウェイセットアソシアティブです。

1. for（i = 0; i <20; i ++）78,336 2,448 2 50,184 0 0 1,224 0 0
2. {{
3. telm01 = elmg1 [i]; 146,880 0 0 73,440 0 0 24,480 0 0
4. telm31 =（telm01 << 3）^ val1; 97,920 0 0 48,960 0 0 24,480 0 0
5. telm21 =（telm01 << 2）^（val1 >> 1）; 146,880 1,224 1 48,960 0 0 24,480 0 0
6. telm11 =（telm01 << 1）^（val1 >> 2）; 146,880 0 0 48,960 0 0 24,480 0 0
7. }

A.ここに記載した理由は、forループ内の3行目に、I1ミスが多数見られるためです（L2ミスも1つ）。やや紛らわしく、理由がわかりませんでしたか？

B.コードの一部を最適化（時間）しようとしています。上記はほんの小さなスニペットです。私のプログラムのメモリアクセスでは、多くの費用がかかると思います。上記の例のように、elmg1は16x20サイズのunsignedlongの配列です。私がコードでそれを使おうとすると、常にいくつかのミスがあり、私のプログラムではこれらの変数が頻繁に発生します。助言がありますか？

C.これらの署名されていないlongを割り当てて（場合によっては初期化する）必要があります。calloc宣言と配列宣言のどちらを優先するかを提案してから、明示的に初期化してください。ちなみに、キャッシュがそれらを処理する方法に違いはありますか？

ありがとう。

私はいくつかのコードを分析し、cachegrindを使用して実行中のキャッシュミス（L2とL3）の数を取得しています。

私の質問は、キャッシュミスに基づいて、キャッシュが準備完了になるのを待つために費やす時間をどのように決定するかです。

「私のコードは90％のCPU使用率を取得します」のようなことを言いたいです

キャッシュグラインド出力に基づいてこれを行うことは可能ですか？

同じアルゴリズムの 2 つのバージョンでは、valgrind/cachegrind の下で異なる合計命令フェッチ カウントとサイクル推定値が得られます。その差は約25%。ただし、プロセスのタイミングは非常に似ています (実際には、cachegrind-slow バージョンの方が短くなっています)。

• バージョン 1:

  /li>

• バージョン 2:

  /li>

この動作は予期されたものですか? バージョン 1 が遅い理由について詳しく知るにはどうすればよいですか?

キャッシュに適した方法を使用して2つの行列を乗算する予定です（これにより、ミスの数が少なくなります）

これは、キャッシュに適した転置関数で実行できることがわかりました。

しかし、私はこのアルゴリズムを見つけることができません。これを達成する方法を知ることができますか?

perfイベントinstructions、LLC-load-misses、を選択したとしますLLC-store-misses。さらに、入力をprog 変化させてプログラムをテストするとします。valgrind同じ入力と同じカウンターに対して「同じ」機能結果が得られるはずですか? つまり、 の 1 つの値perfが上昇した場合、 の 1 つvalgrindは常に同じようにする必要がありますか? valgrindコードのプロファイリング中に注意すべきシミュレーションであることの影響はありますか?

編集：ところで、人々が私自身を実験していないことで私をグリルする前に、私は（ちょっと）持っていると言わなければなりperfません. パッチがありますが、カーネルを再コンパイルする気がしません...

cachegrind 用に Xdebug を構成しようとしていますが、実行された Web ページをダンプするためにプロファイラー機能を有効にすることができません。

公式ガイド(および同様の設定のいくつか) を使用していますが、機能していないようです。

両方の Linux マシン (Ubuntu と Fedora) で試しました。Xdebug はデバッグ用にvalgrind --tool=cachegrind正常に動作しており、アプリケーションを開始できるので、両方を適切にインストールする必要があります。

php.ini で profiler_enable および profiler_enable_trigger オプションをアクティブ化および非アクティブ化し、サーバーを再起動していましたが、うまくいきませんでした。パーミッションの関係かと思い、出力ディレクトリを変更。URL でフラグをパラメーターとして使用し?XDEBUG_PROFILER=1ても、どちらも役に立たないようです。

cachegrind の構成に関連する他の手がかりはありますか?

私は Cachegrind、Callgrind、Gem5 でいくつかの実験を行っています。アクセス数が、cachegrind の読み取り、callgrind の書き込み、および gem5 による読み取りと書き込みの両方としてカウントされていることに気付きました。

非常に簡単な例を見てみましょう:

私はコンパイルします：

gcc ex.c --static -o ex

基本的に、asmファイルによると、addl $1, -8(%rbp)100,000回実行されます。読み取りと書き込みの両方であるため、100k の読み取りと 100k の書き込みを期待していました。ただし、cachegrind はそれらを読み取りとしてのみカウントし、callgrind は書き込みのみとしてカウントします。

-

誰かが私に合理的な説明をしてもらえますか? 実際には ~100k の読み取りと ~100k の書き込み (つまり、addl の 2 つのキャッシュ アクセス) があると考えるのは正しいでしょうか?

まったく同じ方法で使用される、2 つの同様の関数の行ごとのキャッシュ カウントがあります。関数宣言行 (void f(...)) の Ir カウントは非常に異なります。1 つは 999,999,993 で、もう 1 つは 284 だけです。これは何を意味するのでしょうか？

私は Cachegrind を使用して、libc なしでコンパイルされた静的プログラムのキャッシュ ミスの数を取得してい_startます (asm でメイン関数と exit syscall を呼び出すだけです)。プログラムは完全に決定論的であり、命令とメモリ参照は実行ごとに変化しません。キャッシュは、置換ポリシーとして LRU と完全に関連付けられています。

ただし、ミスの数が時々変化することに気付きました。より具体的には、別のディレクトリに移動するまで、ミスの数は常に同じです。

同じコマンドを何度も実行すると、同じ結果が得られます。しかし、別のディレクトリからこのプログラムを実行すると:

また、別のディレクトリからの結果も異なります。

また、Pin ツールを使用していくつかの実験を行いましたが、これを使用すると、異なる値を取得するためにディレクトリを変更する必要はありません。しかし、可能な値のセットは非常に限られているようで、Cachegrind とまったく同じです。

私の質問は、そのような違いの原因は何でしょうか?

私の最初のヒントは、私のプログラムがメモリ内で同じように配置されていないことです。その結果、以前の実行で同じ行に格納されたいくつかの変数はもうありません。これは、組み合わせの数が限られていることも説明できます。しかし、キャッシュグラインド（およびピン）は仮想アドレスを使用していたと思いますが、OS（Linux）は常に同じ仮想アドレスを提供していると思います。他のアイデアはありますか？

編集: LLd ミスの読み取りを推測できるように、プログラムは 31 の異なるキャッシュ ラインのみを使用します。また、キャッシュには 8 つのキャッシュ ラインしか含めることができません。したがって、実際の場合でも、キャッシュが 2 回目に既に読み込まれているという考えでは、違いを説明できません (最大で、L1 にとどまることができるのは 8 ラインのみです)。

編集 2: Cachegrind のレポートは、実際のキャッシュ ミス (パフォーマンス カウンターによって与えられる) に基づくものではなく、シミュレーションの結果です。基本的に、ミスの数をカウントするためにキャッシュの動作をシミュレートします。結果は一時的なものに過ぎないため、それはまったく問題なく、キャッシュ プロパティ (サイズ、結合性) を変更できます。

編集 3:私が使用しているハードウェアは、Linux 3.2 x86_64 上の Intel Core i7 です。コンパイル フラグは -static で、一部のプログラムでは -nostdlib (IIRC、私は今家にいません) です。

私は人々がキャッシュの最適化をどのように行っているかを知りたいと思っており、この目標に向けた便利なツールとして友人から cachegrind を勧められました。

CPU シミュレーターである Valgrind は、 cachegrind を使用する場合、ここで説明されているように 2 レベルのキャッシュを想定しています。

Cachegrind は、プログラムがマシンのキャッシュ階層および (オプションで) 分岐予測子と対話する方法をシミュレートします。これは、独立した第 1 レベルの命令キャッシュとデータ キャッシュ (I1 および D1) を備えたマシンをシミュレートし、統合された第 2 レベルのキャッシュ (L2) に支えられています。これは、多くの最新のマシンの構成と正確に一致します。

次の段落は次のように続きます。

ただし、一部の最近のマシンには、3 レベルまたは 4 レベルのキャッシュがあります。これらのマシンの場合 (Cachegrind がキャッシュ構成を自動検出できる場合)、Cachegrind は最初のレベルと 最後のレベルのキャッシュをシミュレートします。この選択の理由は、最終レベルのキャッシュがメイン メモリへのアクセスをマスクするため、ランタイムに最も影響を与えるためです。

ただし、単純な行列 - 行列乗算コードで valgrind を実行しようとすると、次の出力が得られました。

ドキュメントによると、L1 キャッシュと L3 キャッシュが使用されているはずですが、出力では L3 キャッシュが無視されていることが示されています。何故ですか？

また、cachegrind は、L1 および最終レベルのキャッシュ サイズを事前に想定していますか? それとも、現在実行されている CPU の L1 および最終レベルのキャッシュ サイズを使用しますか?