キャッシュミス対命令比は、キャッシュミス比に対するキャッシュ参照と比較して、キャッシュ性能の指標として優れていますか？

Question

私は理論的にキャッシュフレンドリーなアルゴリズムであることが証明されたコードをテストするためにperfを使用しています。

this articleによれば、命令へのキャッシュミスはキャッシュ性能の優れた指標です。

命令に対するキャッシュミスの割合は、どのようにキャッシュが正常に機能しているかを示します。比率が低いほど良い。この の例では、比率は1.26％（6,605,955キャッシュミス/ 525,543,766 命令）です。 RAMメモリとキャッシュアクセスとの間のコスト差が比較的大きいため（20サイクル） キャッシュミス率のわずかな改善でさえ、 のパフォーマンスを大幅に向上させることができます。 1命令あたりのキャッシュミス率が5％を超える場合は、さらに調査する必要があります（ ）。

しかし私はこのようなPERF実行すると：

perf stat -B -e cache-references,cache-misses,instructions ./td 1.txt 2.txt

をパフォーマンス・は以下を出力します：

Performance counter stats for './td 1.txt 2.txt': 

    93,497,101  cache-references            
    56,452,246  cache-misses    # 60.379 % of all cache refs  
8,115,626,200  instructions    

    2.509309040 seconds time elapsed 

をだから、キャッシュミス率にキャッシュ参照の上、より焦点を当てこの記事で提案されているものの代わりに。

キャッシュ・ミスとキャッシュ・レシオの比は60％と非常に悪いと思われます。これは、アプリケーションがキャッシュにアクセスする時間の60％を意味します。一方、キャッシュミスと命令の比率はわずか0.6％です。

私はこれからどうしたらいいのか分かりません。どの比率を最適化する必要がありますか？

Answer 1

これは最終的にはどちらも誤解を招くことがありますが、その方法は異なります。

ヒットするのは面白いですが、ミスが処理されている間に多くの算術演算を行うことでいくつかのミスを「吸収」することができます。 ＃命令への逃しはあなたにそれについて何かを教えてくれるでしょう。非常に少ない数のミス/命令はあなたがそのような場合にはを示唆しています。たとえば、次の負荷のアドレスが失われた場合、以前のミスに依存する長い計算によって計算され、すべてがシリアル化され、ミス/命令が少し誤解を招くような場合など、実際には意味しません。たとえそれが十分に低いのであれば、合計時間は主に算術に依存するため、ミスは大きな問題にならないでしょう。

無駄な算術演算を行うことで不正行為を行うことができるため、必ずしも最適化する必要はありません。または、より合理的に、いくつかのミスを失うために、より多くの（有用な）算術演算を必要とするトレードオフがあります。明らかに実際の時間がかかり始めると（または一般的にはあなたが本当に心配しているところでパフォーマンスが悪くなり始めます）、それはあなたが気にしていたものでなければかなり人工的なメトリックを改善しても問題ありません。合成ベンチマークの可能性があります）。

あなたのアクセスパターンについては明らかに分かっていますが、メモリ参照が多いメモリを参照することは良いコードの指標ではありません。不必要なメモリ参照が多分あるだけかもしれません。それ以外の方法では、データが1回だけ必要な場合は、もう一度触れても（それがミスを起こさない場合でも）、まだ廃棄されています。それは本当に問題にかかっています。たとえば、配列を集計しているだけであれば、アキュムレータをメモリに入れることは、このメトリックの観点からは非常によく見えますが、明らかに本当に悪いことです。

だから、私は最適化を目指すべき比

？

あなたが純粋な合成物のために行っていない限り、どちらもありません。それらを使って、コードがどのように実行されているかを把握し、経過時間を最適化します（または、あなたの目標に応じて、何でも、何でも）。これらのメトリクスは「疑わしいほど良い」ということは、彼らが「悪い」ものであることを示す手がかりになる可能性があります。