【译文】性能轮盘赌：代码对齐的运气
内容提要
代码对齐对软件性能有重大影响，差异范围从5%到20%。对齐问题可能导致性能不稳定，但无法完全控制。使用Rust编译器选项可以检查对齐问题是否引起性能波动。
延伸解读
性能波动的根源：微操作缓存对齐
文章指出，代码对齐问题可能导致性能波动，其根源在于微操作缓存（如Intel的DSB）的对齐限制。在Sandy Bridge等架构中，每32字节对齐的指令窗口只能缓存18个微操作，若热循环跨越边界，则可能避免限制，反之则导致性能下降。这种微架构层面的细节使得性能表现难以预测，即使代码完全相同，仅地址不同也会造成显著差异。
对齐并非银弹：可能适得其反
虽然对齐代码有时能消除性能差异，但文章强调，盲目对齐可能使代码更大更慢。例如，使用LLVM标志将所有函数对齐到64字节边界后，性能差异消失，但所有函数都变慢了。因此，对齐应视为诊断工具，而非优化手段。在CI中默认使用对齐标志可能影响性能一致性，需谨慎评估。
诊断对齐问题：Rust编译器选项
文章提供了实用的诊断方法：通过Rust编译器的LLVM标志（如-align-all-functions=6和-align-all-nofallthru-blocks=6）将函数和代码块对齐到64字节边界。如果性能差异消失，则表明对齐是原因。此外，硬件性能计数器（如DSB_MISS_PS）也可用于分析。这些方法帮助开发者识别性能波动是否源于对齐，避免过度优化。
跨架构影响与应对局限
代码对齐问题不仅限于x86架构，ARM架构（如Cortex A53/A57）也可能出现类似性能不稳定。然而，由于微架构多样性，开发者无法完全控制对齐，且针对特定微架构的优化不切实际。文章建议，意识到这一因素可避免追逐性能鬼魂，但解决根本问题仍缺乏直接答案，需依赖具体平台和工具。
Q&A
代码对齐为什么会导致性能差异？
代码对齐会影响CPU前端微操作缓存（如DSB）的效率。在Sandy Bridge等架构中，每32字节对齐的指令窗口只能缓存18个微操作，如果热循环跨越32字节边界，可能避免此限制，从而提升性能；反之则可能导致DSB thrashing，使性能下降。
如何检查性能波动是否由代码对齐引起？
可以使用Rust编译器的LLVM标志，如-align-all-functions=6和-align-all-nofallthru-blocks=6，将所有函数和代码块对齐到64字节边界。如果性能差异消失，则说明对齐是原因。此外，还可以使用硬件性能计数器分析DSB_MISS_PS和DSB2MITE_SWITCHES.PENALTY_CYCLES等指标。
在CI中应该始终使用对齐标志来保证性能一致性吗？
不应该。虽然对齐可能提供更一致的性能，但前提是底层代码相同。如果基准函数不同，编译器可能生成不同的布局，改变对齐要求不一定能带来更公平的比较。因此，不建议默认使用对齐标志，仅用于检查性能差异是否由对齐引起。
代码对齐问题只存在于x86架构吗？
不仅限于x86。在ARM架构上也可能出现类似问题，例如在M3 Max芯片上观察到可能由微操作缓存效率低下引起的性能不稳定，ARM Cortex A53/A57微架构也容易因代码放置出现性能波动。
对齐代码总是能提高性能吗？
不一定。对齐代码可能导致性能提升或下降。在更大的边界上对齐代码可能使代码变得更大更慢，如文章所示，将所有热循环对齐到32字节边界后，所有函数都变慢了。因此，需要谨慎验证结果。
如何解决代码对齐导致的性能不稳定问题？
目前没有直接的解决方案。即使系统级语言也只提供基本控制手段，且微架构多样性使得优化不切实际。意识到这一因素有助于避免过度优化，但无法完全控制。
