时钟周期内的缓存未命中延迟

Ven*_*dec 2 performance latency cpu-architecture cpu-cache perf

为了测量程序中缓存未命中的影响,我想要计算缓存未命中对用于实际计算的周期造成的延迟。\n我用它来perf stat测量周期、L1 负载、L1 未命中、LLC 负载和 LLC - 我的程序中遗漏了。这是一个示例输出:

\n
               467\xe2\x80\xaf769,70 msec task-clock                #    1,000 CPUs utilized          \n        1\xe2\x80\xaf234\xe2\x80\xaf063\xe2\x80\xaf672\xe2\x80\xaf432      cycles                    #    2,638 GHz                      (62,50%)\n          572\xe2\x80\xaf761\xe2\x80\xaf379\xe2\x80\xaf098      instructions              #    0,46  insn per cycle           (75,00%)\n          129\xe2\x80\xaf143\xe2\x80\xaf035\xe2\x80\xaf219      branches                  #  276,083 M/sec                    (75,00%)\n            6\xe2\x80\xaf457\xe2\x80\xaf141\xe2\x80\xaf079      branch-misses             #    5,00% of all branches          (75,00%)\n          195\xe2\x80\xaf360\xe2\x80\xaf583\xe2\x80\xaf052      L1-dcache-loads           #  417,643 M/sec                    (75,00%)\n           33\xe2\x80\xaf224\xe2\x80\xaf066\xe2\x80\xaf301      L1-dcache-load-misses     #   17,01% of all L1-dcache hits    (75,00%)\n           20\xe2\x80\xaf620\xe2\x80\xaf655\xe2\x80\xaf322      LLC-loads                 #   44,083 M/sec                    (50,00%)\n            6\xe2\x80\xaf030\xe2\x80\xaf530\xe2\x80\xaf728      LLC-load-misses           #   29,25% of all LL-cache hits     (50,00%)\n
Run Code Online (Sandbox Code Playgroud)\n

那么我的问题是:\n如何将缓存未命中数转换为“丢失”时钟周期数?\n或者,获取数据所花费的时间比例是多少?

\n

我认为构造函数应该知道这个因素。我的处理器是 Intel Core i7-10810U,我在规格和基准测试 CPU列表中都找不到此信息。

\n

这个相关问题描述了如何测量缓存未命中中丢失的周期数,但是有没有办法将其作为硬件信息获取?理想情况下,输出将类似于:

\n
L1-hit: 3 cycles\nL2-hit: 10 cycles\nLLC-hit: 30 cycles\nRAM: 300 cycles\n
Run Code Online (Sandbox Code Playgroud)\n

Pet*_*des 6

无序执行和内存级并行性的存在是为了通过将有用的工作与数据传输的时间重叠来隐藏一些延迟。如果您只是将 L3 未命中计数乘以每个周期 300 个,则可能会超过整个程序所花费的周期总数。cycle_activity.stalls_l3_miss当没有 uops 执行并且存在未完成的 L3 缓存未命中时,perf 事件(存在于我的 Skylake CPU 上)应该对周期进行计数。即执行完全停止时的循环。但也会有一些工作的周期,但少于没有缓存未命中的情况,这更难以评估。

TL:DR:内存访问是高度流水线化的;整个核心不会因一次缓存未命中而停止,这就是重点。指针追踪基准(用于测量延迟)只是最坏的情况,其中唯一的工作是取消引用加载结果。请参阅现代微处理器 90 分钟指南!其中有一个关于内存和“内存墙”的部分。另请参阅https://agner.org/optimize/https://www.realworldtech.com/haswell-cpu/了解有关乱序执行 CPU 的详细信息以及它们如何在一条指令正在等待高速缓存未命中的数据,直至其无序窗口大小的限制。(https://blog.stuffedcow.net/2013/05/measuring-rob-capacity/


回复:来自供应商的号码:

L3 和 RAM 延迟不是固定数量的核心时钟周期:首先,核心频率是可变的(并且独立于非核心和内存时钟),其次是因为来自其他核心的争用以及互连上的跳数。(相关:周期计数本身对程序时序可靠吗?讨论了独立于 L3 和内存的核心频率的一些影响)

也就是说,英特尔的优化手册确实包含一个表格,其中包含 L1 和 L2 的精确延迟、L3 的典型延迟以及 Skylake 服务器上的 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