メモリ内に多数の異なるポイントからの値を使用すると、キャッシュミスが発生し、パフォーマンスが低下することがあります。プログラムが実行されると、L1キャッシュに似た小さなブロックで実際にCPUからメモリにロードされますか？おそらくメモリ内を頻繁にジャンプすると、このキャッシュにミスが発生し、パフォーマンスが低下するため、私は尋ねます。だから私はそれは2つの質問だと思う：そのような "実行キャッシュ"は頻繁にパフォーマンスを傷つける周りを飛び回っています。キャッシュの問題により、プログラム内でジャンプするとパフォーマンスが低下する
P.S.どのような適切なタグがパフォーマンスとキャッシュ以外のものであるかは不明です。
P.P.S.例として、多くのネストされたifとelseが含まれているタイトなループがあります。ここで、ifおよびelseネストの末尾の最終結果はほんのわずかなコードです。
はい。このキャッシュは命令キャッシュと呼ばれます。それを排除することは、パフォーマンスに重大な影響を及ぼす可能性があります。これは、インライン関数が必ずしも有益ではない理由です。インライン関数は高速になりますが、膨大なコードサイズによってI-Cacheからホットパスが追い出される可能性があります。
Linuxカーネルのデverlopersメーリングリストには、このトピックに関する興味深い議論があります。
あなたの例では、頻繁に呼び出される小さな関数が命令キャッシュにロードされてそこに残るため、インライン関数として頻繁に呼び出すとコードが遅くなる可能性があることを意味します。インライン関数が複数の場所を命令キャッシュにロードしています。正しい？ –
命令キャッシュの現在の日数はどれくらいでしょうか（たとえば、私が正しく覚えていれば、16Kと4MはL1キャッシュとL2キャッシュの正しい順番になっていたと思います）。 –
@JohnRobertson私はあなたの最初の文を理解することができませんでした;-)長すぎる、ネストすぎます。私は非常に寒い関数をインライン展開すると、ホットコードがキャッシュから追い出される可能性があるため、パフォーマンスが損なわれる可能性があると言っていました。インライン展開（たいていの場合）はCPU命令を作成します。同じプログラムからより多くの命令をインライン化するほど、頻繁にインライン展開されます。同じ理由から、コンパイラはサイズの最適化をサポートします。私のCore i7のI-cacheサイズは32kbです。それは小さいです。 1つのUDPパケットであっても、完全にキャッシュに留まるかどうかは不明です。 – usr
コードをすばやく高速化する必要がない限り、おそらくキャッシュミスを心配する必要はありません。あなたのプログラムを最適化するもっと簡単な方法があります。 – Jonathan
私のコードの99.9％について、私はこれについて気にしません。これは、ほんのわずかしかなく、稀で重要な部分にのみ関連し、実際には高速でなければならず、高性能で多数の小さな相関関係のケースを迅速に処理する方法の問題は、現在私が直面している問題です。 –