为了衡量程序中缓存未命中的影响，我想了解缓存未命中对实际计算所用周期造成的延迟。我使用perf stat来测量程序中的周期、L1负载、L1未命中、LLC负载和LLC未命中。以下是输出示例：
467 769,70 msec task-clock # 1,000 CPUs utilized
1 234 063 672 432 cycles # 2,638 GHz (62,50%)
572 761 379 098 instructions # 0,46 insn per cycle (75,00%)
129 143 035 219 branches # 276,083 M/sec (75,00%)
6 457 141 079 branch-misses # 5,00% of all branches (75,00%)
195 360 583 052 L1-dcache-loads # 417,643 M/sec (75,00%)
33 224 066 301 L1-dcache-load-misses # 17,01% of all L1-dcache hits (75,00%)
20 620 655 322 LLC-loads # 44,083 M/sec (50,00%)
6 030 530 728 LLC-load-misses # 29,25% of all LL-cache hits (50,00%)
那么我的问题是：如何将缓存未命中的数量转换为"；丢失"；时钟周期或者，用于获取数据的时间比例是多少？
我认为构造函数应该知道这个因素。我的处理器是英特尔酷睿i7-10810U，我在规格和基准CPU列表中都找不到这些信息。
这个相关的问题描述了如何测量缓存未命中中丢失的周期数，但有没有一种方法可以将其作为硬件信息获得？理想情况下，输出将类似于：
L1-hit: 3 cycles
L2-hit: 10 cycles
LLC-hit: 30 cycles
RAM: 300 cycles
无序执行和内存级别的并行性通过将有用的工作与飞行中的数据重叠来隐藏一些延迟。如果你简单地将L3未命中计数乘以每个300个循环，这可能会超过整个程序所花费的循环总数。perf事件cycle_activity.stalls_l3_miss(存在于我的Skylake CPU上(应该在没有执行uop并且存在未完成的三级缓存未命中时计算周期。即，在执行完全停滞时计算周期数。但也会有一些工作的周期，但少于没有缓存未命中的周期，这更难评估。
TL:DR：内存访问是流水线式的；整个核心不会在一次缓存未命中时停止，这就是重点。追逐指针的基准测试(用于测量延迟(只是最坏的情况，其中唯一的工作就是取消对加载结果的引用。参见现代微处理器90分钟指南！其具有关于存储器的部分；记忆墙"；。另请参阅https://agner.org/optimize/和https://www.realworldtech.com/haswell-cpu/以了解有关无序exec CPU的详细信息，以及它们如何在一条指令等待来自缓存未命中的数据时继续进行独立工作，直至其无序窗口大小的限制。(https://blog.stuffedcow.net/2013/05/measuring-rob-capacity/)
Re:供应商编号：
L3和RAM延迟并不是核心时钟周期的固定数量：首先，核心频率是可变的(与非核心和内存时钟无关(，其次是由于来自其他核心的争用以及互连上的跳数。(相关：循环计数本身对程序定时是否可靠？讨论了与L3和内存无关的核心频率的一些影响(
也就是说，英特尔的优化手册确实包括一个表，其中包含L1和L2的确切延迟，以及Skylake服务器上的L3和DRAM的典型延迟。(2.2.1.3 Skylake服务器微体系结构缓存建议(https://software.intel.com/content/www/us/en/develop/articles/intel-sdm.html#optimization-他们说SKX L3延迟通常为50-70个周期。DRAM的速度在一定程度上取决于DIMM的时序。
其他人测试了特定的CPU，比如https://www.7-cpu.com/cpu/Skylake.html.