我们经常听到将我们的变量与内存中的N字节边界对齐可以提高性能（通过阻止CPU必须将两个单独的单词加载到缓存中以读取我们的变量）。另一方面，我们也听到（较不经常）将大块内存（数组/缓冲区）与一个很好的二舍五入幂的地址对齐可能是不好的，因为散列函数分配内存地址以缓存地址不再统一（这称为页面对齐）。内存对齐与页面对齐
因此，我的问题是，是否存在某种规则或阈值时间点，我们应该故意忽略数据以避免页面对齐问题;什么时候不去，以获得标准内存对齐的好处？
如果性能对您的应用程序来说特别重要，而且您的应用程序通常会对已知数据集（类型和大小）进行迭代，那么知道并理解MMU，L缓存和缓存行的效果非常重要。不是因为您可以提前避免这些问题，而是因为您可能需要在事实后识别它们，同时盯着分析结果，并试图弄清楚为什么某些事情比以前更长，或者“通常应该“。而且 - 如果你很幸运并且数据集足够在你的控制之内 - 你可以调整一些东西来解决某种CPU缓存性能问题。
不幸的是，大多数应用程序并没有遍历已知数据集，并且知道它们的目标硬件类型。这对于游戏和多媒体应用程序开发以及操作系统工程来说是相当独特的。对于世界上大多数应用程序的其他应用程序而言，改进某个特定大小的特定数据集的缓存配置文件意味着将其降低为另一个特定大小。
最后，即使是“将我们的变量与N字节边界对齐”的“经验法则”也会受到底层硬件的影响。大多数更新的桌面级x86架构（大部分是在2011年左右制造的）更喜欢打包的数据而不是对齐的数据，因为加载跨缓存线边界的单词的成本比加载更多总缓存线来代表相同数据集要便宜。但在运行ARM的移动设备上？对齐仍然非常关键。
更多关键字，您可以搜索上，进一步教育：缓存着色和高速缓存收回。但是，这一切都非常依赖于目标CPU，不幸的是，很少有（或没有）概括。
我不认为你可以得到这个通用的规则。它取决于您使用的处理器，即底层系统的MMU和缓存实现。这将因系统而异。因此，如果您想要最佳性能，您需要了解当前系统的所有低级别细节。一般来说，我认为将大内存块对齐到2的幂次边界的好处是有限的。
“缓存关联性”是一个很好的搜索术语。希望你可以用你想要避免的特定事物的更好模型替换你的大脑中的第二段。 – tmyklebu
这肯定与C＃，C++或C没有关系，尤其不是C＃。 – abligh
我选择了这些语言，因为它们是您通常需要考虑的有关这些问题的语言。是的，我认为你也是用C＃做的。 – Xenoprimate