C++ 缓存线对齐的内存分配会有回报吗？

我只知道对齐内存分配的基本概念。但我不太关心对齐问题，因为我不是汇编程序员，也没有MMX/SIMD的经验。我认为这是一个过早的优化

如今，人们越来越多地谈论缓存命中率、缓存一致性、大小优化等。一些源代码甚至在CPU缓存线上显式地分配内存

坦白地说，我不知道我的i7cpu的缓存线大小是多少。我知道大尺寸对齐不会有什么害处。但如果没有SIMD，它真的会有回报吗

假设一个程序中有100000条100字节的数据。访问这些数据是该项目最密集的工作

---

如果我们更改数据结构，使所有100字节大小的数据按16字节对齐，是否有可能获得显著的性能提升？10%? 5%？

这取决于您的系统。试试看，运行一些基准测试，然后找出答案。

这是我最近最喜欢的关于缓存效果的博客之一

关于缓存线对齐的大多数讨论都涉及使用多线程的高性能计算，并尽可能保持线性可伸缩性。在这些讨论中，缓存线对齐的原因是防止对一个数据变量的写入导致缓存线失效，该缓存线还包含其他线程使用的另一个变量

---

因此，除非您试图编写可扩展到非常多处理器内核的代码，否则缓存线对齐可能对您没有多大影响。但是，再次测试它，看看。

缓存优化甚至为单线程应用程序付费。但是缓存优化并不一定要在缓存开始时对齐数据，因为有几个因素需要考虑。因此，要走的路是：

• 您是否满足您的性能要求？如果是，为什么要花时间进行优化。为优化薪酬而优化很少

• 衡量你的瓶颈在哪里。如果您怀疑缓存出现问题，请使用报告缓存未命中的工具，从而了解您可以赢得多少

---

在最高级别上，缓存优化的目标是用感兴趣的数据填充缓存，同时将不感兴趣的数据保留在缓存之外。如果您正在进行多线程编程，那么防止线程之间的干扰也很重要。然后，您还必须防止一些特定于某些缓存实现的事情，例如共振效应，这些效应有时会降低非完全关联缓存的缓存大小。

那么，这确实是过早的优化。在没有可靠的CPU检测功能和CPU缓存信息列表的情况下，如何做到这一点？隐马尔可夫模型。。我担心得太多了吗？在你真正测试了什么是慢的之前，所有的优化都是不成熟的。@9dan-你不需要这些东西，只需要一个时钟。@OrangeDog我的意思是，因为基准测试结果会随着CPU的变化而变化，如果没有CPU检测功能，我无法应用缓存感知优化。@9dan如果需要多个内核来处理处理，那么提前担心错误共享并非过早。如果您无意中共享，那么您的性能将比仅使用单个处理器更差。到目前为止，任何一个多核必须在同一个数据上工作的系统，我想说，正确的数据设计不是一种优化，而是一种要求。这是我读过的关于处理器缓存的最好解释。这确实是缓存的戏剧性效果。如果我太天真，我会害怕。说到过早优化，你知道吗，好的算法通常可以为更大的数据集（甚至更大的数据集）提供数百%或数千%的速度提升对于高性能计算来说，程序对缓存的处理能力等细节都在列表中，但对于大多数应用程序来说，这永远都不重要。我相信64字节是一种常见的缓存线大小，不是16字节。有一次，我通过缓存对齐和预取其内存访问，将一个算法改进了10倍。我认为所有的答案都有自己的教训，但这个答案可能是经验法则（但最低投票数），所以我接受了这一点。谢谢。两条线就足够让虚假分享显示它巨大的头部了。（但由于数据大小为100字节，我怀疑虚假共享对他们来说是个问题。）@Aprogrammer关于写入的观点很好。我只关心阅读。是的，虚假分享会毁掉一个程序。对齐也可用于优化共享。那些总是脏的且多线程需要的变量都可以打包到单个缓存线中。这意味着只需要更新一条缓存线。我不同意，即使对于具有大量内存访问对齐的单线程应用程序，也可能会在性能上产生显著差异。因此，显然对于读，可能对于写，缓存线上的内存分配对齐不是一个重要问题，不是吗？如果您的数据是只读的，重要的是，一起访问的数据尽可能留在缓存中。i7的行大小为64字节（请参阅），因此正确对齐的一个数据将跨越2条缓存线，如果不是，则需要3条缓存线。所以这可能会有所帮助（我写过当你想要优化时，测量是一种方法吗？）