在处理大于其高速缓存行的类型时，英特尔 CPU 的预期行为是什么？答案

【问题标题】：What is the expected behaviour of an Intel CPU when dealing with a type larger than its cache line?在处理大于其高速缓存行的类型时，英特尔 CPU 的预期行为是什么？
【发布时间】：2014-12-07 08:42:53
【问题描述】：

假设我将数组T array[N] 提供给我的CPU，其中T 是一个大类型，一个大struct，大于64 字节，假设64 字节也是大小CPU 中的缓存行；我的问题是：什么应该是可观察的行为？我可以诊断什么？

显然我假设我的T 和我的array 都是打包和对齐的，并且所涉及的数据结构就它们在内存中的布局和位置而言已经过优化。我的主要关注点是关于 T > 缓存行的情况以及可以解释在这种情况下会发生什么的技术细节。

【问题讨论】：

好吧，即使您的类型大于缓存行，实际的机器代码也只会在 128 位或更小的访问中访问您的类型。所以它与一组更小的类型没有什么不同，真的。

标签： c++ c caching cpu cpu-architecture

【解决方案1】：

您的 CPU 看不到类型，特别是没有 struct 类型或任何东西，这是特定于语言的封装。它只看到对编译器从中分离出来的各个字段的访问。所有这些字段最后都是整数、指针或浮点数，您的 CPU 知道如何有效地处理这些。

【讨论】：

我提到了 T 的大小，我知道 CPU 只能以非常通用的方式看到“可寻址”的东西，我的意思是如何考虑这一点以及 CPU 如何运行这个案例;例如，一个 64 字节的缓存行填充了 63 字节的数据被认为是未对齐的，这可能会导致性能方面的一些损失，那么这种情况呢？既然你提到了它，我也想关注一个很好的资源，它可以解释我的 CPU 如何管理无符号和有符号整数，但这可能是 OT。
我不确定我们是否相互理解。编译器正在为您完成所有工作，例如，他确保您的数据在您的struct 中正确对齐，这样您就不必担心这些事情。如果您大部分时间不需要struct 中的所有字段，实际上您可能会将数据分散到比所需更多的缓存行上。但这与访问并非整数数组中的所有元素没有太大区别，例如
我得到了编译器部分，我在描绘这种情况下 CPU 正在做什么以及基于什么协议时遇到了麻烦。例如，一个数据数组（“数组”表示任何“热”数据序列），通常根据缓存行的大小分成相等的部分，例如一个数组[N]，其中 N 远大于 64，被划分为 64 字节的块，并馈送到我的多核 CPU 的不同核心，此时相对容易理解缓存一致性的工作原理以及为什么需要。在任何 T 不适合单个缓存行的情况下，哪种协议是有效的？
基本上可以保证我的 T 会破坏缓存一致性协议 AFAIK 的 CPU 是如何工作的。还有其他政策吗？其他协议？
@user2485710，您似乎对缓存一致性或多线程编程有一些误解。如果您在某个并行框架下编写程序，请在问题中说明这一点，否则您的工作没有理由这样分发。无论哪种方式，缓存一致性都不会像那样中断。