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

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

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

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

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

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

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

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

QCacheGrind でコードをプロファイリングしようとすると、すべて正常にロードされますが、プログラム内のソース コードが表示されません。

何らかの理由でソース コードのパスが間違っています。

今はcachegrind file location＋ですphp file location

だけのはずですphp file location

おはようございます、

私の mac は今日、ワーキング メモリを使い果たしました。これは奇妙でした。スペースが使用されている場所を調べたところ、log/xdebug ファイルに 20 GB 近くの cachegrind.out ファイルがありました。xdebug.profiler_enable をオンにしてから約 3 ～ 4 週間しか経っていませんが、あまり多くはありませんが、デバッグに PHPStorm を使用しています。

x を超えるエントリを削除するか、x メガバイトのデータのみを保存するように xdebug に指示するにはどうすればよいですか?

それとも何かひどく間違っていますか？

参考までに、私のスタックは PHP 用の mod_fastcgi を備えた OSX ネイティブ Apache であり、PHP と MariaDB は自作を使用してインストールされています。通常は Drupal で開発しますが、PHP 5.4 で Drupal 6 を使用すると、PHP 4 のサポートが維持されているため、多くのエラーがスローされます。まだ20ギグ？もう。それは一日のギグのようなものです。

前もって感謝します！

最近、Herb Sutter は"Modern C++: What You Need to Know"について素晴らしい講演を行いました。この講演の主なテーマは、効率と、データの局所性とメモリへのアクセスがどのように重要かということでした。彼はまた、メモリ (配列/ベクトル) の線形アクセスが CPU によってどのように愛されるかについても説明しています。彼は、このトピックに関する別の古典的な参考文献「Bob Nystrom によるゲーム パフォーマンス」から 1 つの例を取り上げました。

これらの記事を読んだ後、プログラムのパフォーマンスに影響を与える 2 種類のキャッシュがあることがわかりました。

1. データキャッシュ
2. 命令キャッシュ

Cachegrindツールは、プログラムの両方のキャッシュ タイプ インストルメンテーション情報も測定します。最初のポイントは、多くの記事/ブログで説明されており、データキャッシュの効率 (データの局所性) を達成する方法です。

しかし、トピック命令キャッシュと、パフォーマンスを向上させるためにプログラムで注意すべきことについては、あまり情報が得られませんでした。私の理解によると、私たち（プログラマー）は、どの命令またはどの順序が実行されるかをあまり制御できません。

小さな C++ プログラムで、このカウンター (つまり、命令キャッシュ) が私たちのプログラムの書き方によってどのように変化するかを説明できれば、本当に素晴らしいことです。この点に関して、プログラマーがより良いパフォーマンスを達成するために従うべきベストプラクティスは何ですか?

私たちのプログラムが(ベクトルとリスト)を同じように行う場合、データキャッシュのトピックについて理解できることを意味し、2番目のポイントについて説明することができます。この質問の主な意図は、このトピックを可能な限り理解することです。

簡単なマイクロベンチマークを使ってキャッシュ効果について調べています。

Nがキャッシュサイズよりも大きい場合、キャッシュは最初の読み取りキャッシュラインごとにミス操作を行うと思います。

私のマシンでは、キャッシュ ライン サイズ = 64 バイトなので、完全にキャッシュが発生し、N/8 ミス操作とキャッシュ グラインドがそれを示していると思います。

ただし、perf ツールでは異なる結果が表示されます。34,265 回のキャッシュ ミス操作しか発生しません。

ハードウェアのプリフェッチが疑わしいので、BIOS でこの機能をオフにします。とにかく、結果は同じです。

perf ツールのキャッシュ ミスが「cachegrind」よりも非常に小さな操作で発生する理由がよくわかりません。誰かが私に合理的な説明をしてもらえますか?

1. これは簡単なマイクロベンチマークプログラムです。

2. 次の結果は、cachegrind の出力です。

3. 次の結果は perf の出力です。

さらに実験結果(2014.05.13):

上記の結果では、「L1D ハードウェア プリフェッチ リクエスト」の数は、cachegrind の D1 ミス (1,250,000) のようです。

私の結論としては、「ストリーム パターン」にメモリ アクセスする場合、L1D プリフェッチ機能が有効になります。また、LLC ミス情報により、メモリからロードされたバイト数を確認できません。

私の結論は正しいですか？

編集者注:
(1) の出力によるとcachegrind、OP はおそらく最適化なしで gcc 4.6.3 を使用していました。
(2) で使用される raw イベントの一部は、perf statNehalem/Westmere でのみ公式にサポートされているため、OP が使用しているマイクロアーキテクチャだと思います。
(3) raw イベント コードの最上位バイト (つまり、3 番目のバイト) に設定されたビットは、 によって無視されperfます。(ただし、3 番目のバイトのすべてのビットが無視されるわけではありません。) したがって、イベントは実質的に r024e、r014e、r0f0a、および r0109 です。
(4) イベント r0f0a と r0109 はコア イベントではありませんが、OP はそれらをコア イベントとして指定していperfます。

cachegrind ファイル (xdebug プロファイリング出力) を制限する方法はありますか? プロジェクト全体 (トリガーだけでなく) をデバッグするために xdebug.profile を有効にしたいのですが、誰かがそれを無効にするのを忘れた場合、ディスクがいっぱいになることは望ましくありません。

プロファイラーのドキュメントにそのようなオプションは見つかりませんでした。

このターミナル ラインを使用して、Valgrind の Cachegrind で C++ アプリケーションをプロファイリングしています。

私が見たオンラインガイドから、これは関数レベルのプロファイリング結果を自動的に提示するはずです。ただし、プログラム レベルの結果しか得られません。

各関数の結果を表示するには、他に何を指定する必要がありますか?

アップデート

これを実行する必要がありました：

関数レベルの結果を取得します。

私は valgrind と cachegrind を使用してコードをプロファイリングするのは初めてで、最近これらのツールを使用して、キャッシュの使用に関して自分のコードがどのように動作しているかを確認し始めました。単純な if ステートメントを実行すると、ほぼ毎回キャッシュ ミスが発生することがわかりました。例として、Fortran プログラムで次の派生型を使用します。

この例は、位置と運動量によって記述される最大 50 個の粒子を含む位置空間内の 100 個のセルを表しています。コードは単純なパーティクル ムーバーを使用して、特定のタイム ステップでのパーティクルの位置と運動量を更新します。これを実装するには、次のようなループを使用します。

if ステートメントを含めることで、特定のセルに粒子がない場合にループを循環させることで、コードを高速化できると考えました。しかし、valgrind と cachegrind ツールを使用してコードのプロファイリングを行ったところ、この単純な if ステートメントではほとんどの場合キャッシュ ミスが発生することがわかりました。--auto=yes以下は、オプションを有効にして cg_annotate を使用したこの if ステートメントの結果の例です。

これは、実行されるたびにキャッシュ ミスのように見えます。セルをループするときにコードでこれを頻繁に行いますが、これが大幅な速度低下の原因になっていると思います。これは派生型を使用した結果ですか? ここで、または一般的に派生型でキャッシュの使用率を改善する方法はありますか?

完全を期すために、gfortran 4.8.3 でコンパイルし、次のフラグを使用しています。-g -O3 -ffast-math -mcmodel=medium -fdefault-real-8