std::array 在存储大对象时是否仍然缓存友好？ [关闭]答案

【问题标题】：Is std::array still cache friendly when it stores large objects? [closed]std::array 在存储大对象时是否仍然缓存友好？ [关闭]
【发布时间】：2019-09-30 11:44:26
【问题描述】：

我知道 std::array 是缓存友好的，因为存储在 std::array 中的所有项目都彼此紧密排列。如果我遍历数组，当我尝试访问一个项目时，CPU 会预取接下来的几个项目。

这就是我的困惑所在：通常 XEON 缓存行是 64 字节：即 8 int64_t 。成像我有

std::array<BigObject, 100>

其中每个 BigObject 的大小为 512 字节。在这种情况下，即使所有 BigObject 项都彼此相邻打包，CPU 也无法做任何聪明的事情：它仍然必须逐行获取缓存，即每个 BigObject 8 行。因此，不应该有任何缓存友好的优势。

那么我的问题是：对于大对象的 std::array，是否还有缓存友好的优势？如果是这样，为什么？

【问题讨论】：

请记住，现代 CPU 具有多级缓存，x86 类型 CPU 上的第三个缓存是数兆字节。因此，即使一个对象不适合单个缓存行，它仍然可以在缓存中
您到底在寻找什么“洞察力”？显然，C++ 不能对 cpu 架构做任何事情，或者以某种方式将一个大对象缩小为更少的字节数。不幸的是，这将违反我们共享宇宙的几条基本物理定律。因此，目前还不清楚这里到底要问什么。
您的 CPU 只会为您使用的字段获取内存。如果您只使用BigObject 的前 64 个字节中的字段，则一个缓存行获取就足够了。如果一个足够智能的编译器（tm）看到你在这样一个数组上循环，它可以插入预取指令，但我不认为这是一个简单的优化。
在发布您的第一个问题之前，您应该在 stackoverflow.com 上使用tour，访问help center，并了解How to Ask 问题
缓存问题似乎是过早的优化。并非所有缓存都相同。并非所有缓存都像您所猜测的那样工作。

标签： c++ arrays caching cpu-usage cpu-cache

【解决方案1】：

澄清一下，处理器缓存的加速源于这样一个事实，即今天计算机的 RAM 即内存比 CPU 慢几倍。因此 CPU 有一些小的内部存储器，即所谓的高速缓存，速度很快。 CPU为了更好地利用小内存，通常会使用时间和空间的概念，即经常使用的东西保存在缓存中，最近使用的东西旁边的东西，它们在内存中的邻居，也被加载到缓存中，因为接下来很可能需要它们。

所以正如您所理解的那样，当它们紧密地存储在内存中时，它们会被友好地缓存起来。由于std::array 和std::vector 被称为ContiguousContainer，它们在内存中彼此相邻地保存它们的内容。

因此，缓存友好实际上将您经常使用的东西保存在一起，即您在一个循环中迭代或在这样的容器中一个接一个地使用。

如果你的对象和你说的一样大，你可以做你想做的事，它们太大而无法放入缓存中，在合理的数量下。因此，您可以查看在这些对象中如此频繁地操作的是什么，并且只将其存储在容器中，或者您可以忍受不可避免的减速。如果您首先在您使用的类或结构中定义最重要的成员，您也可以加快速度，因为这会转化为成员存储在内存中的布局。班级成员的首要任务。

但正如所有这些更重要的建议：通常您的算法复杂性对您程序的整体运行时间更为重要。例如：问你自己，你是不是程序对每个大对象都做一点工作，然后去下一个，只是稍后对每个大对象做一些其他的小工作，这是非常低效的，或者你能做所有的工作吗？一次为一个对象，然后才前进到下一个大对象？如果不是，为什么你的对象这么大？它们不应该只包含手头任务所需的东西吗？不要把事情弄得乱七八糟，希望事情会变得更快。 “过早的优化是万恶之源”是这种背景下的流行语。首先将您的程序编写清晰易读并确保正确性。然后运行它并测量它实际上慢的地方。关于缓存实现的一般猜测通常不是很有帮助，像“当有疑问时使用向量或数组，因为它们通常是最快的”这样的启发式方法就足够了。

或者更好地回答你的问题：std::array 和 std::vector 都是缓存友好的最佳选择，但是没有容器可以对大对象进行缓存友好，因为大对象由于大而对缓存不友好.

【讨论】：