c++ - 在 C/C++ 中的特定地址边界上对齐内存是否仍能提高 x86 性能？

Question

许多低延迟开发指南讨论了在特定地址边界上对齐内存分配:

https://github.com/real-logic/simple-binary-encoding/wiki/Design-Principles#word-aligned-access

http://www.alexonlinux.com/aligned-vs-unaligned-memory-access

但是，第二个链接是2008年的。在地址边界上对齐内存是否仍然在2019年为Intel CPU提供性能提升？我认为英特尔 CPU 不再会因访问未对齐的地址而导致延迟损失？如果不是，在什么情况下应该这样做？我应该对齐每个堆栈变量吗？类成员变量？

有没有人有任何例子表明他们发现对齐内存有显着的性能改进？

Answer 1

惩罚通常很小，但在 Skylake 受到较大惩罚(~150 个周期)之前，在 Intel CPU 上跨越了 4k 页边界。 How can I accurately benchmark unaligned access speed on x86_64有一些关于跨越缓存线边界或 4k 边界的实际影响的细节。 (即使加载/存储在一个 2M 或 1G 的大页面内，这也适用，因为硬件直到开始两次检查 TLB 的过程后才能知道这一点。)例如在 double 的数组中。那只是 4 字节对齐，在页面边界上会有一个 double 数，它被均匀地分成两个 4k 页面。每个缓存行边界都相同。

不跨越 4k 页面的常规缓存行拆分在 Intel 上花费了大约 6 个额外的延迟周期(Skylake 上总共为 11c，而正常 L1d 命中为 4 或 5c)，并且花费了额外的吞吐量(这可能很重要)通常每个时钟维持接近 2 个负载的代码。)

未跨越 64 字节高速缓存线边界的未对齐对英特尔的惩罚为零。在 AMD 上，缓存线仍然是 64 字节，但缓存线内有 32 字节的相关边界，在某些 CPU 上可能是 16 字节。

Should I align every stack variable?

不，编译器已经为你做了这些 . x86-64 调用约定保持 16 字节堆栈对齐，因此他们可以免费获得任何对齐，包括 8 字节 int64_t和 double数组。

还要记住，大多数局部变量在大部分时间都被大量使用时保存在寄存器中。除非变量是 volatile ，或者您在没有优化的情况下编译，在访问之间不必存储/重新加载该值。

正常 ABIs还需要所有原始类型的自然对齐(与其大小对齐)，因此即使在结构等内部，您也将获得对齐，并且单个原始类型永远不会跨越缓存行边界。 (异常(exception):i386 System V 只需要 int64_t 和 double 的 4 字节对齐。在结构之外，编译器会选择给它们更多的对齐，但在结构内部它不能改变布局规则。所以声明你的结构以将 8 字节成员放在最前面的顺序，或者至少布局以使它们获得 8 字节对齐。如果您关心 32 位代码，也许在此类结构成员上使用 alignas(8)，如果还没有需要这么多对齐的成员。)

如果 x86-64 System V ABI(所有非 Windows 平台)在结构外具有自动或静态存储，则需要将数组按 16 对齐。 maxalign_t在 x86-64 SysV 上是 16，所以 malloc/new返回 16 字节对齐的内存用于动态分配。面向 Windows 的 gcc 也会对齐堆栈数组，如果它在该函数中自动矢量化它们。

(如果您通过违反 ABI 的对齐要求导致未定义的行为，它通常不会使任何性能不同。它通常不会导致 x86 的正确性问题，但它可能导致 SIMD 类型的错误，以及标量的自动矢量化类型。例如 Why does unaligned access to mmap'ed memory sometimes segfault on AMD64? 。因此，如果您故意错位数据，请确保不要使用任何比 char* 宽的指针访问它。
例如使用 memcpy(&tmp, buf, 8)与 uint64_t tmp做一个未对齐的负载。 gcc 可以通过它自动向量化，IIRC。)

您有时可能想要 alignas(32)或 64 表示大型数组，如果您编译时启用了 AVX 或 AVX512 .对于大阵列上的 SIMD 循环(不适合 L2 或 L1d 缓存)，使用 AVX/AVX2(32 字节 vector )，确保它在 Intel Haswell/Skylake 上按 32 对齐通常几乎为零。来自 L3 或 DRAM 的数据中的内存瓶颈将使内核的加载/存储单元和 L1d 缓存时间在引擎盖下进行多次访问，即使每隔一个加载/存储跨越缓存线边界。

但是使用 Skylake 服务器上的 AVX512，实际上对阵列的 64 字节对齐有显着影响，即使阵列来自 L3 缓存或 DRAM .我忘记了细节，我已经有一段时间没有看示例了，但即使对于内存绑定(bind)循环，也可能是 10% 到 15%？如果它们不对齐，每个 64 字节 vector 加载和存储将跨越 64 字节缓存线边界。

根据循环，您可以通过执行第一个可能未对齐的 vector 来处理未对齐的输入，然后循环对齐的 vector 直到最后一个对齐的 vector 。到达数组末尾的另一个可能重叠的 vector 可以处理最后几个字节。这对于复制和处理循环非常有用，在这种循环中可以重新复制和重新处理重叠中的相同元素，但还有其他技术可以用于其他情况，例如标量循环直到对齐边界、更窄的 vector 或掩码。如果您的编译器是自动矢量化的，则由编译器来选择。如果您使用内在函数手动矢量化，您必须/必须选择。如果数组通常是对齐的，最好只使用未对齐的加载(如果指针在运行时对齐，则不会受到惩罚)，并让硬件处理罕见的未对齐输入的情况，这样您就没有任何软件开销对齐的输入。