sse - 使用无格式数据时，loadu_ps 和 set_ps 有什么区别？

Question

我有一些未存储为数组结构的数据。在寄存器中加载数据的最佳做法是什么？

__m128 _mm_set_ps (float e3, float e2, float e1, float e0)
// or
__m128 _mm_loadu_ps (float const* mem_addr)

与 _mm_loadu_ps ，我会将数据复制到临时堆栈数组中，而不是直接将数据复制为值。有区别吗？

Answer 1

这可能是延迟和吞吐量之间的权衡，因为将存储单独存储到数组中会导致 a store-forwarding stall当您进行矢量加载时。所以它的延迟很高，但吞吐量仍然可以，并且它不会与向量 shuffle 执行单元的周围代码竞争。因此，如果周围的代码也有 shuffle 操作，这可能是吞吐量的胜利，而不是在第一个标量加载后将 3 个元素插入 XMM 寄存器的 3 次 shuffle。无论哪种方式，它仍然有很多总 uops，这是另一个吞吐量瓶颈。

大多数编译器(如 gcc 和 clang)在 _mm_set_ps () 方面做得很好。使用 -O3 优化时，无论输入是在内存中还是寄存器中。我会推荐它，除非在某些特殊情况下 .

最常见的遗漏优化 _mm_set是当输入之间存在某些局部性时 .例如不要做_mm_set_ps(a[i+2], a[i+3], a[i+0], a[i+1]]) ，因为许多编译器将使用它们的常规模式，而没有利用 2 对元素在内存中是连续的这一事实。在这种情况下，使用(内部函数)movsd和 movhps加载两个 64 位块。 (不是 movlps :它合并到现有寄存器中而不是将高位元素归零，因此它对旧内容有错误的依赖性，而 movsd 将高位归零。)或者 shufps如果在 64 位块之间或内部需要一些重新排序。

编译器使用的“常规模式”通常是 movss/insertps如果使用 SSE4 编译，则从内存中，或 movss负载和 unpcklps洗牌组合成对，然后是另一个 unpcklps , unpcklpd , 或 movlhps洗牌到一个寄存器。或 shufps或 shufpd如果编译器喜欢在直接混洗控制操作数上浪费代码端，而不是智能地使用固定混洗。

另见 Agner Fog's optimization guides一些方便的数据移动指令表，以更好地了解编译器必须使用什么以及如何执行。请注意，Haswell 及更高版本每个时钟只能进行 1 次 shuffle。还有其他链接 the x86 tag wiki .

编译器或人类没有真正便宜的方法来执行此操作，在一般情况下，当您有 4 个在内存中根本不连续的单独标量时 .或者对于寄存器输入，它首先无法优化它们在寄存器中生成的方式，以便将其中一些已经打包在一起。 (例如，对于在寄存器中传递给不能/不内联的函数的函数 args。)

反正是没什么大不了的，除非你把它放在一个内循环中 .在这种情况下，绝对要担心它(和 check the compiler's asm output 看看它是否弄得一团糟，或者如果你自己编写程序集，使用映射到单个指令(如 _mm_load_ss/_mm_shuffle_ps )的内在函数可以做得更好。

如果可能，重新排列您的数据布局，使数据至少以小块/ strip 的形式连续。 (参见 https://stackoverflow.com/tags/sse/info ，特别是 these slides 。但有时程序的一部分需要以一种方式获取数据，而另一部分需要另一种方式。选择适合需要更快或运行更频繁的情况的布局，或者其他什么，把它吸进去，为程序的另一部分尽你所能。:P 可能转置/转换一次以设置多个 SIMD 操作，但是额外的数据传递没有计算只会浪费时间并且可以损害您的计算强度(每次将数据加载到寄存器时您做了多少 ALU 工作)而不是它们的帮助。

顺便说一句，实际收集指令(如 AVX2 vgatherdps )不是很快；即使在 Skylake 上，对于已知位置的四个 32 位元素使用聚集指令也可能不值得。在 Broadwell/Haswell 上，gather 绝对不值得为此使用。