algorithm - 与缓存引用与缓存未命中的比率相比，为什么缓存未命中与指令的比率是缓存性能的更好指标？

Question

我正在使用 perf 来测试理论上被证明是缓存友好算法的代码。

根据 this article指令的缓存未命中是缓存性能的良好指标。

The ratio of cache-misses to instructions will give an indication how well the cache is working; the lower the ratio the better. In this example the ratio is 1.26% (6,605,955 cache-misses/525,543,766 instructions). Because of the relatively large difference in cost between the RAM memory and cache access (100’s cycles vs <20 cycles) even small improvements of cache miss rate can significantly improve performance. If the cache miss rate per instruction is over 5%, further investigation is required.

但是当我这样运行 perf 时:

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

Perf 将打印以下内容:

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

它们最终都具有误导性，但方式不同。

命中未命中很有趣，但是您可以通过在处理未命中时进行大量算术运算来“吸收”一些未命中。未命中#instructions 会告诉您一些相关信息，因为极少的未命中/指令表明您处于这种情况。这并不意味着你实际上是这样，例如，如果下一个未命中的负载的地址是通过本身取决于前一个未命中的长计算来计算的，那么它都会被序列化并且未命中/指令变得有点误导。即便如此，如果它足够低，那么总时间主要取决于算法，因此未命中不会成为大问题。

它不一定要优化，因为你可以通过做无用的算术工作来作弊。或者，更合理地，做一个权衡，花费更多(有用的)算术来丢失一些未命中，这听起来不错，但你可能会走得太远。显然，如果它开始花费更多的实际时间(或者通常它开始在你真正关心的任何事情上表现更差)，那么你改进一些相当人为的指标并不重要(除非那真的是你关心的，你可能在综合基准中)。

未命中/引用显然告诉您有关访问模式的一些信息，但是进行大量缓存命中内存引用并不是好的代码的指标:也许只是有很多不必要的内存引用。或者换句话说，如果数据只需要一次，那么再次触摸它(即使不会产生遗漏)仍然是一种浪费。这真的取决于问题。例如，如果您只是对数组求和，从这个指标的角度来看，将累加器放入内存看起来确实不错，但显然这是一件非常糟糕的事情。

所以，

Which ratio should I aim to optimize?

都不是，除非您想要纯合成的东西。使用它们来了解代码的执行情况，然后优化耗时(或功率或其他任何东西，取决于您的目标)。这些指标“好得可疑”和“坏得好”一样都是一个线索，所以也许这应该被称为低和高。