AVX-512 `_mm512_load_epi64` 和 `_mm512_loadu_epi64` 之间有什么性能差异吗？

Question

这个问题的动机

未对齐的负载通常更常用。 当地址已经对齐时，开发人员应该使用对齐的 SIMD 加载。 所以我开始怀疑在已经对齐的地址上这两个函数调用之间是否存在一些性能差异。 直观的猜测是对齐加载比未对齐加载更快。

我知道这个问题可能非常依赖硬件。 另一个动机点是 Zen4 是第一个提供 AVX-512 的 AMD 微架构，所以我想在 Zen4 上尝试一些 AVX-512 并看看结果。

基准代码和程序集

代码： https ://godbolt.org/z/W3qvcjGWs

我以两种情况为基准：

• 第一种情况：我保证要访问data的内存大小小于一级缓存。 所以我没有缓存未命中； 因此不受内存限制。
• 第二种情况：访问的内存大于缓存。 汇编中的函数调用之间的唯一区别： vmovdqa64和vmovdqu64 。

结果

我的实验是在 AMD Zen4 上进行的。 我对函数调用进行了十次基准测试。 结果是一致的，原来这两个函数调用是一样快的。 这违背了我的直觉。 如果为真，则没有实际对齐加载的用例，它具有最小的场景并导致未对齐地址上的段错误。

Answer 1

对齐数据没有缺点

如果内存对齐（因此load可以工作而不是故障）， 性能是相同的。 自 Nehalem 和 K10 以来，Intel 和 AMD CPU 一直是这种方式。 （或者当数据对齐时，用于movdqu存储的 Bulldozer 也与需要对齐的方式运行相同。）

对于 512 位向量，这没有改变， _mm512_loadu_si512在对齐数据上速度很快。

如果你的数据通常是对齐的，未对齐的加载是一个很好的选择； 没有额外指令的开销检查常见情况的对齐，并且在极少数情况下硬件处理得不是很好。 如果您想大声失败以检测数据是否曾经未对齐，请使用对齐加载（并使用 GCC 或 clang 进行编译，而不是 MSVC 或 ICC，它们从不在 asm 中使用需要对齐的加载/存储）。

要实际测试未对齐，如果编译器将您的加载内在函数折叠到其他指令的内存源操作数中，您可能需要禁用优化（以巨大的性能代码）。 验证对齐预期是vmovdqa64和朋友的用例。

---

如果您的数据实际上大部分时间都未对齐，对于 256 位向量，让 CPU 处理它仍然可以。 （当心为什么 gcc 不将 _mm256_loadu_pd 解析为单个 vmovupd？在 GCC11 之前使用 GCC 的默认调整）。 每次检查对齐时都必须运行额外的代码可能是值得的，并且可能会执行未对齐的第一个向量，如果您的 SIMD 操作可以的话，可能会与第一个对齐的向量重叠。

请参阅如何准确地对 x86_64 上的未对齐访问速度进行基准测试？ 有关性能影响的一些详细信息，以及x86 上成功的未对齐访问的实际影响是什么？ .

---

未对齐的 512 位向量特别慢

关于512 位向量的有趣之处在于，任何未对齐都必然意味着缓存行拆分，不可能未对齐但仍包含在单个 64 字节缓存行中，就像 16 字节和 32 字节向量一样。 （在那些情况下，我认为自 Haswell 以来的英特尔和自 Zen 2 或 3 以来的 AMD（？）仍然具有未对齐加载/存储的完整性能。）参见https://uops.info/和https://agner.org/optimize /

至少对于 Intel CPU，对齐数据对于 AVX-512 非常有用，即使您的代码在 DRAM 带宽上存在瓶颈； 显然未对齐的 64 字节加载实际上在运行时未对齐导致每核内存带宽降低，可能降低 15% 左右，而使用 256 位向量的代码只有几个百分点，如果是这样的话。