是否真的对齐结构/类的数据成员不再产生它过去的好处，特别是由于硬件改进在 nehalem 上？如果是这样，那么对齐是否总是会带来更好的性能，与过去的 CPU 相比只是非常小的显着改进？
成员变量的对齐是否扩展到成员函数？我相信我曾经读过(它可能在 wikibooks“C++ performance”上)有规则将成员函数“打包”到各种“单元”(即源文件)中以最佳地加载到指令缓存中？ (如果我在这里的术语有误，请纠正我)。
最佳答案
处理器仍然比 RAM 可以提供的速度快得多，因此它们仍然需要缓存。缓存仍然由固定大小的缓存行组成。此外，主内存以页面形式提供，页面使用转换后备缓冲区进行访问。同样，此缓冲区具有固定大小的缓存。
这意味着空间和时间局部性都非常重要(即您如何打包东西，以及如何访问它)。很好地打包结构(按填充/对齐要求排序)而不是按一些随意的顺序打包它们通常会导致更小的结构尺寸。
较小的结构大小意味着，如果您有大量数据:
- 更多结构适合一个缓存行(缓存未命中 = 50-200 个周期)
- 需要的页面更少(页面错误 = 10-20 百万个 CPU 周期)
- 需要更少的 TLB 条目，更少的 TLB 未命中(TLB 未命中 = 50-500 个周期)
线性处理几千兆字节的紧密打包的 SoA 数据比以不良布局/打包的简单方式做同样的事情快 3 个数量级(如果涉及页面错误，则快 8-10 个数量级) .
无论您是否手动对齐 个人 4 字节或 2 字节值(例如，典型的 int 或 short)到2 或 4 个字节对最近的 Intel CPU 影响很小(几乎不明显)。就此而言，似乎很想对此进行“优化”，但我强烈建议不要这样做。
这通常是最好不要担心的事情，留给编译器来解决。如果没有其他原因，那么因为 yield 充其量是微不足道的，但是如果你弄错了，一些其他处理器架构会引发异常。因此，如果你太聪明了，一旦你在其他架构上编译，你就会突然出现无法解释的崩溃。发生这种情况时，您会感到抱歉。
当然，如果你没有至少几十兆的数据需要处理，你根本不需要关心。
关于c++ - 对齐数据成员和成员函数以提高性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14946281/