缓存行大小背后的理论和测量是什么？答案

【问题标题】：What's the theory and measurements behind cache line sizes?缓存行大小背后的理论和测量是什么？
【发布时间】：2016-07-18 16:43:59
【问题描述】：

缓存行通常为 64 字节，也存在其他大小。

我的一个非常简单的问题是：这个数字背后是否有任何理论，或者它背后的工程师无疑只是大量测试和测量的结果怎么办？

无论哪种方式，我都想知道那些（理论，如果有的话，以及决策背后的各种测试）是什么。

【问题讨论】：

缓存行越小，标签占用的空间越大。我怀疑更大的最后一级缓存是将缓存行大小从 32（奔腾 III）增加到 64（当前）的主要动机之一。我认为这几乎将标签模具面积减少了一半。

标签： cpu cpu-architecture cpu-cache

【解决方案1】：

一般而言，微架构参数倾向于通过性能建模而不是某种理论模型进行调整。也就是说，没有像“大 O”这样用来表征算法性能的东西。相反，基准测试是使用性能模拟器运行的，用于指导选择最佳参数。

已经说过，缓存行大小在已建立的架构中会相当稳定的原因有几个：

大小是 2 的幂：为了简化寻址，行大小应该是 2 的幂，因此这限制了缓存行大小的可能选择数量。 p>
软件基于缓存参数进行优化：许多微架构参数对程序员完全隐藏。但是高速缓存行大小是可见的，并且会对某些应用程序的性能产生重大影响。一旦程序员针对 64 字节缓存线大小优化了他们的代码，那么处理器架构师就有动力在未来的处理器中保持相同的缓存线大小，即使底层技术发生了变化，使得不同大小的缓存线更容易在硬件中实现。
缓存一致性与缓存行交互：缓存一致性协议的验证非常困难，缓存一致性是处理器中许多错误的来源。一致性在高速缓存行级别进行跟踪，因此更改高速缓存行将需要重做一致性协议的所有验证步骤。因此，更改此参数需要有强烈的动机。
更改缓存行大小可能会引入错误共享：这是基于缓存参数优化软件的特殊情况，但我认为值得一提。并行程序很难以实际提供性能优势的方式编写。由于数据以高速缓存行粒度进行跟踪，因此避免false sharing 很重要。如果缓存线大小从一代处理器更改为另一代，这可能会导致新处理器中的错误共享，而旧处理器中不存在。

虽然 64 字节是用于 x86 和大多数 ARM 处理器的行大小，但还有其他行大小正在使用中。例如，MIPS 有许多具有 32 字节行大小的处理器，还有一些具有 16 字节行大小的处理器。

在一定程度上调整了线路大小，以便为架构预期运行的工作负载提供最佳性能。但是，一旦选择了线路大小，并且已经为该架构编写了大量软件，那么线路大小在未来不太可能发生变化，原因我在上面列出了。

【讨论】：

+1 用于基准测试和调优。让我感到难过的是，程序员会针对特定的缓存行大小进行优化，因为它是可见的，并且程序可以轻松适应。但我猜他们这些混蛋很懒……
@Andreas：使用编译时常数边界制作循环可以帮助编译器更好地优化，在某些情况下更好（例如循环展开）。例如，以一种让编译器知道一个变量只能是大于 32 的 2 的幂的方式编写代码，而不在代码中包含运行时检查，这将是很多工作。
@PeterCordes 有趣的一点。我认为编译器不需要变量范围的编译时间信息。此外，可变范围不是由功能需求而不是平台属性决定的吗？也许我非常相信编译器优化功能。
@Andreas：他们不需要它，但如果他们拥有它，他们可以进行更多优化。编译时常量甚至可以直接折叠成指令，而不是占用一个寄存器。例如add rsi, 64 将指针递增 64。64 是指令流中的一个字节，它是指令的一部分。编译器能证明的关于变量值的东西越多，它的优化就越好。
我认为您的真正意思是程序应该可以轻松地为不同的缓存行大小重新编译它们（使用#define 或static constexpr int clsize = 64，而不是到处硬编码. 我同意那个。可能有一些情况可以证明只优化源代码中的一种大小是合理的，例如，某些技巧只对 64B 或更大的缓存行有意义，而实际上没有人编写过代码技巧不是一个好主意的情况。