L1キャッシュヒットのサイクル/コスト対x86での登録？
私のアーキテクチャクラスでは、L1キャッシュヒットは1サイクル（つまり、レジスタアクセス時間と同じ）であると想定しましたが、最近のx86プロセッサでは実際にそうですか？
L1キャッシュヒットには何サイクルかかりますか？登録アクセスと比較してどうですか？
これはこのテーマに関する素晴らしい記事です：
http://arstechnica.com/gadgets/reviews/2002/07/caching.ars/1
あなたの質問に答えるために-はい、キャッシュヒットのコストはレジスタアクセスとほぼ同じです。そしてもちろん、キャッシュミスは非常にコストがかかります;）
PS：
詳細は異なりますが、このリンクにはいくつかの良い球場の数字があります：
さまざまなキャッシュとメインメモリにアクセスするためのおおよそのコスト？
Core i7 Xeon 5500 Series Data Source Latency (approximate)
L1 CACHE hit, ~4 cycles
L2 CACHE hit, ~10 cycles
L3 CACHE hit, line unshared ~40 cycles
L3 CACHE hit, shared line in another core ~65 cycles
L3 CACHE hit, modified in another core ~75 cycles remote
L3 CACHE ~100-300 cycles
Local DRAM ~30 ns (~120 cycles)
Remote DRAM ~100 ns
PPS：
これらの数値はmuch古くて遅いCPUを表しています（ただし、比率は基本的には次のとおりです）。
http://arstechnica.com/gadgets/reviews/2002/07/caching.ars/2
Level Access Time Typical Size Technology Managed By
----- ----------- ------------ --------- -----------
Registers 1-3 ns ?1 KB Custom CMOS Compiler
Level 1 Cache (on-chip) 2-8 ns 8 KB-128 KB SRAM Hardware
Level 2 Cache (off-chip) 5-12 ns 0.5 MB - 8 MB SRAM Hardware
Main Memory 10-60 ns 64 MB - 1 GB DRAM Operating System
Hard Disk 3M - 10M ns 20 - 100 GB Magnetic Operating System/User
番号。
シングルサイクルキャッシュレイテンシは、以前はより低いクロック速度（つまり、各サイクルがより長いナノ秒）の単純な順序のパイプライン上のものでしたが、特に単純なキャッシュ（より小さく、関連性がなく、キャッシュのTLBが小さかった場合） t純粋に仮想的に対処されます。）例 クラシック5ステージRISCパイプライン MIPSのように、WBステージの前に、EXでのアドレス計算とMEMでのメモリアクセスを使用して、キャッシュヒットのメモリアクセスに1サイクルを想定します。
最新の高性能CPUは、パイプラインをより多くのステージに分割し、各サイクルを短くすることができます。これにより、add/or/andのような単純な命令を非常に高速に実行できますが、レイテンシは1サイクルですが、クロック速度は高速です。
サイクルカウントと順不同実行の詳細については、 Agner Fogのmicroarch pdf 、および x86タグwiki の他のリンクを参照してください。
Intel HaswellのL1ロード使用レイテンシは、ポインタ追跡の場合、4サイクルです。これは、現代のx86 CPUに典型的なものです。つまり、mov eax, [eax]がそれ自体を指すポインタを使用してループ内でどれだけ高速に実行できるか。 （または、キャッシュにヒットするリンクリストの場合、閉じたループで簡単にマイクロベンチを作成できます）。参照 base + offsetがbaseとは異なるページにある場合にペナルティはありますか？ その4サイクルのレイテンシの特殊なケースは、ポインタが別のロードから直接来た場合にのみ適用され、それ以外の場合は5サイクルです。
Intel CPUのSSE/AVXベクトルでは、負荷使用時のレイテンシが1サイクル長くなります。
ストアリロードのレイテンシは5サイクルであり、キャッシュヒットまたはミスとは無関係です（ストア転送、ストアバッファーからのストアデータの読み取り、まだL1dキャッシュにコミットされていません）。
ハロルドがコメントしたように、レジスタアクセスは0サイクルです。したがって、たとえば：
inc eaxには1サイクルのレイテンシがあります（ALU演算のみ）add dword [mem], 1からのロードの準備ができるまで、dword [mem]には6サイクルのレイテンシがあります。 （ALU +ストア転送）。例えばループカウンターをメモリに保持すると、ループが6サイクルごとに1回の反復に制限されます。mov rax, [rsi]には、rsiの準備ができてからraxがL1ヒットの準備ができるまでの4サイクルのレイテンシがあります（L1ロード使用レイテンシ。）
http://www.7-cpu.com/cpu/Haswell.html には、キャッシュごとのレイテンシのテーブル（ここにコピーします）と、L2-TLBを含むその他の実験的な数値がありますヒットレイテンシ（L1DTLBミス時）。
Intel i7-4770（Haswell）、3.4 GHz（ターボブーストオフ）、22 nm。 RAM：32 GB（PC3-12800 cl11 cr2）。
- L1データキャッシュ= 32 KB、64 B /ライン、8ウェイ。
- L1命令キャッシュ= 32 KB、64 B /ライン、8ウェイ。
- L2キャッシュ= 256 KB、64 B /ライン、8ウェイ
L3キャッシュ= 8 MB、64 B /ライン
L1データキャッシュのレイテンシ=ポインターによる単純なアクセスの場合は4サイクル（
mov rax, [rax]）- L1データキャッシュのレイテンシ=複雑なアドレス計算（
mov rax, [rsi + rax*8]）でのアクセスに対して5サイクル。- L2キャッシュ遅延= 12サイクル
- L3キャッシュ遅延= 36サイクル
- RAMレイテンシ= 36サイクル+ 57 ns
トップレベルのベンチマークページは http://www.7-cpu.com/utils.html ですが、さまざまなテストサイズの意味を実際には説明していませんが、コードは利用可能です。テスト結果には Skylake が含まれます。これは、このテストのHaswellとほぼ同じです。
@ paulsm4の回答には、リモート（その他のソケット）メモリー/ L3番号を含む、マルチソケットのNehalem Xeonの表があります。
私が正しく覚えている場合、それは約1〜2クロックサイクルですが、これは推定値であり、新しいキャッシュの方が速い場合があります。これは私が持っているコンピュータアーキテクチャブックではなく、これはAMD向けの情報なので、Intelは少し異なるかもしれませんが、5から15クロックサイクルに制限するので、私には良い見積もりのようです。
編集：おっとL2はTAGアクセスで10サイクルです、L1は1〜2サイクルかかります、私の間違い：\
実際、L1キャッシュヒットのコストは、レジスタアクセスのコストとほぼ同じです。それは私にとっては驚くべきことでしたが、少なくとも私のプロセッサー（Athlon 64）にとってはそうです。少し前に、マルチプロセッサシステムでの共有データへのアクセスの効率をベンチマークする簡単なテストアプリケーションを作成しました。アプリケーション本体は、事前定義された期間中に増加する単純なメモリ変数です。 comapisonを作成するために、最初に非共有変数をベンチマークしました。そして、そのアクティビティ中に結果をキャプチャしましたが、アプリケーションの逆アセンブル中に、コンパイラが私の期待をだまし、コードに不要な最適化を適用していることがわかりました。変数をCPUレジスタに入れて、メモリにアクセスせずにレジスタ内で繰り返しインクリメントします。しかし、コンパイラーにレジスター変数ではなくメモリー内変数を使用するように強制したところ、本当に驚きました。更新されたアプリケーションで、ほぼ同じベンチマーク結果を達成しました。パフォーマンスの低下はほんのわずか（1〜2％）であり、何らかの副作用に関連しているように見えます。
結果として：
1）L1キャッシュをアンマネージドプロセッサレジスタプールと見なすことができると思います。
2）コンパイラー・ストアに頻繁にアクセスするデータをプロセッサー・レジスターに強制することにより、残忍なアセンブリ最適化を適用する必要はありません。それらが本当に頻繁にアクセスされる場合、それらはL1キャッシュに存在し、これにより、プロセッサレジスタと同じアクセスコストが発生します。