[英]Fastest way to do horizontal SSE vector sum (or other reduction)
给定三个（或四个）浮点数的向量。 求和它们的最快方法是什么？
SSE（movaps、shuffle、add、movd）总是比 x87 快吗？ SSE3 中的水平添加指令值得吗？
迁移到 FPU，然后是 faddp，faddp 的成本是多少？ 最快的特定指令序列是什么？
“尝试安排事物，以便一次将四个向量相加”不会被接受为答案。 :-) 例如，对于一个数组求和，您可以使用多个向量累加器进行垂直求和（以隐藏 addps 延迟），并在循环后减少到一个，但随后您需要对最后一个向量进行水平求和。
一般来说，对于任何类型的向量水平减少，提取/混洗高半到低，然后垂直添加（或最小/最大/或/和/异或/乘/任何）； 重复直到剩下一个元素。 如果您从大于 128 位的向量开始，将其缩小一半直到达到 128（然后您可以在该向量上使用此答案中的函数之一）。 除非最后需要将结果广播到所有元素，否则可以考虑一直做全宽shuffle。
更宽向量、整数和FP 的相关问答
__m128和__m128d这个答案（见下文）
__m256d与 Ryzen 1 与 Intel 的性能分析（说明为什么vextractf128比vperm2f128 ） 使用 SSE/AVX 获取存储在 __m256d 中的值的总和
__m256 如何水平求和 __m256？
数组的点积（不仅仅是 3 或 4 个元素的单个向量）：在多个累加器中进行垂直 mul/add 或 FMA，并在最后进行 hsum。 完整的 AVX+FMA 数组点积示例，包括循环后的高效 hsum。 （对于数组的简单求和或其他缩减，使用该模式但没有乘法部分，例如添加而不是 fma）。 不要为每个SIMD向量分别做水平工作; 最后做一次。
如何使用 SIMD作为计数_mm256_cmpeq_epi8匹配的整数示例来计算字符出现次数，再次在整个数组上进行，仅在最后进行求和。 （特别值得一提的是，先进行一些 8 位累加，然后扩大 8 -> 64 位以避免溢出，而无需在此时执行完整的 hsum。）
整数
__m128i 32 位元素：这个答案（见下文）。 64 位元素应该是显而易见的：只有一个 pshufd/paddq 步骤。
__m128i 8 位无符号元素： psadbw对_mm_setzero_si128() ，然后 hsum 两个 qword 一半（或 4 或 8 为更宽的向量）。 水平求和 SSE 无符号字节向量的最快方法显示 128 位与 SSE2。 在 __m512i 中使用 AVX 内在函数求和 8 位整数有一个 AVX512 示例。 如何使用 SIMD 计算字符出现次数有一个 AVX2 __m256i示例。
（对于有符号字节，您可以 XOR set1(0x80) 在 SAD 之前翻转为无符号，然后从最终的 hsum 中减去偏差）。
_mm_madd_epi16与 set1(1) 作为单 uop 加宽水平添加构建块，用于窄整数： SIMD：累积相邻对
__m256i和__m512i具有 32 位元素。 使用 AVX512 或 AVX2 计算所有打包 32 位整数总和的最快方法。 对于 AVX512，英特尔添加了一堆“reduce”内联函数（不是硬件指令）来为您执行此操作，例如_mm512_reduce_add_ps （以及 pd、epi32 和 epi64）。 还减少_min/max/mul/和/或。 手动执行会导致基本相同的 asm。
水平最大值（而不是添加）： 使用 SSE 在 __m128i 向量中获取最大值？
__m128这里有一些基于Agner Fog 的 microarch guide 的 microarch guide 和指令表调整的版本。 另请参阅x86标签维基。 它们在任何 CPU 上都应该是高效的，没有大的瓶颈。 （例如，我避免了对一个 uarch 有一点帮助但在另一个 uarch 上缓慢的事情）。 代码大小也被最小化。
常见的 SSE3 / SSSE3 2x hadd习惯用法仅适用于代码大小，不适用于任何现有 CPU 的速度。 它有一些用例（如转置和添加，见下文），但单个向量不是其中之一。
我还包含了一个 AVX 版本。 任何类型的 AVX / AVX2 水平缩减都应该从vextractf128和“垂直”操作开始，以减少到一个 XMM ( __m128 ) 向量。 一般来说，对于宽向量，最好的办法是反复缩小一半，直到缩小到 128 位向量，无论元素类型如何。 （除了 8 位整数，如果您想在不溢出到更宽元素的情况下进行 hsum，则vpsadbw作为第一步。）
在 Godbolt Compiler Explorer 上查看所有这些代码的 asm 输出。 另请参阅我对Agner Fog 的 C++ 矢量类库horizontal_add函数的改进。 （留言板线程和github上的代码）。 我使用 CPP 宏为 SSE2、SSE4 和 AVX 的代码大小选择最佳洗牌，并在 AVX 不可用时避免movdqa 。
有一些权衡需要考虑：
haddps ，因此这在这里非常相关。当水平添加不频繁时：
如果很少使用，没有 uop-cache 的CPU 可能更喜欢 2x haddps ：它在运行时很慢，但这并不常见。 只有 2 条指令最大限度地减少了对周围代码（I$ 大小）的影响。
带有 uop 缓存的CPU 可能会偏爱使用较少 uop 的东西，即使它有更多指令/更多 x86 代码大小。 使用的总 uops 缓存线是我们想要最小化的，这不像最小化总 uops 那么简单（采用的分支和 32B 边界总是开始一个新的 uop 缓存线）。
无论如何，话虽如此，水平总和出现了很多，所以这是我仔细制作一些编译良好的版本的尝试。 未在任何真实硬件上进行基准测试，甚至未经过仔细测试。 shuffle 常量或其他东西中可能存在错误。
如果您正在制作代码的回退/基线版本，请记住只有旧 CPU 才能运行它； 较新的 CPU 将运行您的 AVX 版本或 SSE4.1 或其他任何版本。
像 K8、Core2(merom) 和更早版本的旧 CPU 只有 64 位 shuffle 单元。 Core2 为大多数指令提供 128 位执行单元，但对于 shuffle 则没有。 （Pentium M 和 K8 将所有 128b 向量指令作为两个 64 位一半处理）。
像movhlps这样以 64 位块移动数据（在 64 位一半内没有混洗）的混洗也很快。
相关：新 CPU 上的洗牌，以及避免 Haswell 及更高版本上 1/clock shuffle 吞吐量瓶颈的技巧： AVX512 中的 128 位交叉通道操作是否提供更好的性能？
在慢 shuffle 的旧 CPU 上：
movhlps (Merom: 1uop) 明显快于shufps (Merom: 3uops)。 在 Pentium-M 上，比movaps便宜。 此外，它在 Core2 上的 FP 域中运行，避免了其他 shuffle 的旁路延迟。unpcklpd比unpcklps快。pshufd很慢， pshuflw / pshufhw很快（因为它们只随机播放 64 位的一半）pshufb mm0 (MMX) 很快， pshufb xmm0很慢。haddps非常慢（Merom 和 Pentium M 上为 6uops）movshdup (Merom: 1uop) 很有趣：它是唯一一个在 64b 元素内随机播放的 1uop insn。 Core2（包括 Penryn）上的shufps将数据带入整数域，导致绕过延迟将其返回到addps的 FP 执行单元，但movhlps完全在 FP 域中。 shufpd也在浮动域中运行。
movshdup在整数域中运行，但只有一个 uop。
AMD K10、Intel Core2(Penryn/Wolfdale) 和所有后来的 CPU，将所有 xmm shuffle 作为单个 uop 运行。 （但请注意 Penryn 上shufps的旁路延迟，避免了movhlps ）
如果没有 AVX，避免浪费的movaps / movdqa指令需要仔细选择movdqa 。 只有少数洗牌作为复制和洗牌工作，而不是修改目的地。 组合来自两个输入的数据（如unpck*或movhlps ）的movhlps可以与不再需要的 tmp 变量一起使用，而不是_mm_movehl_ps(same,same) 。
通过将虚拟 arg 用作初始洗牌的目的地，其中一些可以做得更快（保存 MOVAPS）但更难看/不那么“干净”。 例如：
// Use dummy = a recently-dead variable that vec depends on,
// so it doesn't introduce a false dependency,
// and the compiler probably still has it in a register
__m128d highhalf_pd(__m128d dummy, __m128d vec) {
#ifdef __AVX__
// With 3-operand AVX instructions, don't create an extra dependency on something we don't need anymore.
(void)dummy;
return _mm_unpackhi_pd(vec, vec);
#else
// Without AVX, we can save a MOVAPS with MOVHLPS into a dead register
__m128 tmp = _mm_castpd_ps(dummy);
__m128d high = _mm_castps_pd(_mm_movehl_ps(tmp, _mm_castpd_ps(vec)));
return high;
#endif
}
float hsum_ps_sse1(__m128 v) { // v = [ D C | B A ]
__m128 shuf = _mm_shuffle_ps(v, v, _MM_SHUFFLE(2, 3, 0, 1)); // [ C D | A B ]
__m128 sums = _mm_add_ps(v, shuf); // sums = [ D+C C+D | B+A A+B ]
shuf = _mm_movehl_ps(shuf, sums); // [ C D | D+C C+D ] // let the compiler avoid a mov by reusing shuf
sums = _mm_add_ss(sums, shuf);
return _mm_cvtss_f32(sums);
}
# gcc 5.3 -O3: looks optimal
movaps xmm1, xmm0 # I think one movaps is unavoidable, unless we have a 2nd register with known-safe floats in the upper 2 elements
shufps xmm1, xmm0, 177
addps xmm0, xmm1
movhlps xmm1, xmm0 # note the reuse of shuf, avoiding a movaps
addss xmm0, xmm1
# clang 3.7.1 -O3:
movaps xmm1, xmm0
shufps xmm1, xmm1, 177
addps xmm1, xmm0
movaps xmm0, xmm1
shufpd xmm0, xmm0, 1
addss xmm0, xmm1
我报告了一个关于 pessimizing the shuffles 的 clang 错误。 它有自己的洗牌内部表示，并将其转回洗牌。 gcc 更经常使用与您使用的内在函数直接匹配的指令。
通常 clang 比 gcc 做得更好，在指令选择不是手动调整的代码中，或者即使当内在函数对于非常量情况是最佳的时，常量传播也可以简化事情。 总的来说，编译器可以像内部函数的合适编译器一样工作，而不仅仅是汇编器，这是一件好事。 编译器通常可以从标量 C 生成好的 asm，甚至不会尝试像好的 asm 那样工作。 最终编译器会将内在函数视为另一个 C 运算符作为优化器的输入。
float hsum_ps_sse3(__m128 v) {
__m128 shuf = _mm_movehdup_ps(v); // broadcast elements 3,1 to 2,0
__m128 sums = _mm_add_ps(v, shuf);
shuf = _mm_movehl_ps(shuf, sums); // high half -> low half
sums = _mm_add_ss(sums, shuf);
return _mm_cvtss_f32(sums);
}
# gcc 5.3 -O3: perfectly optimal code
movshdup xmm1, xmm0
addps xmm0, xmm1
movhlps xmm1, xmm0
addss xmm0, xmm1
这有几个优点：
不需要任何movaps副本来解决破坏性洗牌（没有 AVX）： movshdup xmm1, xmm2的目的地是只写的，因此它为我们从死寄存器中创建了tmp 。 这也是我使用movehl_ps(tmp, sums)而不是movehl_ps(sums, sums) 。
代码量小。 改组指令很小： movhlps是 3 个字节， movshdup是 4 个字节（与shufps相同）。 不需要立即字节，因此对于 AVX， vshufps是 5 个字节，但vmovhlps和vmovshdup都是 4 个字节。
我可以用addps而不是addss保存另一个字节。 由于这不会在内部循环内使用，因此切换额外晶体管的额外能量可能可以忽略不计。 来自上面 3 个元素的 FP 异常没有风险，因为所有元素都保存有效的 FP 数据。 然而，clang/LLVM 实际上“理解”向量混洗，并且如果它知道只有低元素重要的话，它会发出更好的代码。
与 SSE1 版本一样，向自身添加奇数元素可能会导致 FP 异常（如溢出），否则不会发生，但这应该不是问题。 Denormals 很慢，但 IIRC 产生 +Inf 结果不是在大多数 uarches 上。
如果代码大小是您的主要关注点，那么两条haddps ( _mm_hadd_ps ) 指令就可以解决问题（Paul R 的回答）。 这也是最容易输入和记住的。 不过，它并不快。 甚至英特尔 Skylake 仍将每个haddps解码为 3 haddps ，具有 6 个周期延迟。 因此，即使它节省了机器代码字节（L1 I-cache），它也会在更有价值的 uop-cache 中占用更多空间。 haddps实际用例： 转置和求和问题，或在此 SSE atoi()实现的中间步骤中进行一些缩放。
与Marat 对 AVX 问题的回答相比，此版本节省了一个代码字节。
#ifdef __AVX__
float hsum256_ps_avx(__m256 v) {
__m128 vlow = _mm256_castps256_ps128(v);
__m128 vhigh = _mm256_extractf128_ps(v, 1); // high 128
vlow = _mm_add_ps(vlow, vhigh); // add the low 128
return hsum_ps_sse3(vlow); // and inline the sse3 version, which is optimal for AVX
// (no wasted instructions, and all of them are the 4B minimum)
}
#endif
vmovaps xmm1,xmm0 # huh, what the heck gcc? Just extract to xmm1
vextractf128 xmm0,ymm0,0x1
vaddps xmm0,xmm1,xmm0
vmovshdup xmm1,xmm0
vaddps xmm0,xmm1,xmm0
vmovhlps xmm1,xmm1,xmm0
vaddss xmm0,xmm0,xmm1
vzeroupper
ret
double hsum_pd_sse2(__m128d vd) { // v = [ B | A ]
__m128 undef = _mm_undefined_ps(); // don't worry, we only use addSD, never touching the garbage bits with an FP add
__m128 shuftmp= _mm_movehl_ps(undef, _mm_castpd_ps(vd)); // there is no movhlpd
__m128d shuf = _mm_castps_pd(shuftmp);
return _mm_cvtsd_f64(_mm_add_sd(vd, shuf));
}
# gcc 5.3.0 -O3
pxor xmm1, xmm1 # hopefully when inlined, gcc could pick a register it knew wouldn't cause a false dep problem, and avoid the zeroing
movhlps xmm1, xmm0
addsd xmm0, xmm1
# clang 3.7.1 -O3 again doesn't use movhlps:
xorpd xmm2, xmm2 # with #define _mm_undefined_ps _mm_setzero_ps
movapd xmm1, xmm0
unpckhpd xmm1, xmm2
addsd xmm1, xmm0
movapd xmm0, xmm1 # another clang bug: wrong choice of operand order
// This doesn't compile the way it's written
double hsum_pd_scalar_sse2(__m128d vd) {
double tmp;
_mm_storeh_pd(&tmp, vd); // store the high half
double lo = _mm_cvtsd_f64(vd); // cast the low half
return lo+tmp;
}
# gcc 5.3 -O3
haddpd xmm0, xmm0 # Lower latency but less throughput than storing to memory
# ICC13
movhpd QWORD PTR [-8+rsp], xmm0 # only needs the store port, not the shuffle unit
addsd xmm0, QWORD PTR [-8+rsp]
存储到内存并返回避免了 ALU uop。 如果 shuffle 端口压力或一般的 ALU uops 是瓶颈，那很好。 （请注意，它不需要sub rsp, 8或任何东西，因为 x86-64 SysV ABI 提供了信号处理程序不会踩到的红色区域。）
有些人存储到一个数组并将所有元素相加，但编译器通常没有意识到数组的低元素仍然存在于存储之前的寄存器中。
pshufd是一个方便的复制和洗牌。 不幸的是，位和字节移位是就地的， punpckhqdq将目标的高半部分放在结果的低半部分，这与movhlps可以将高半部分提取到不同寄存器的方式相反。
在某些 CPU 上，第一步使用movhlps可能会很好，但movhlps是我们有一个临时注册。 pshufd是一个安全的选择，Merom 之后的一切都很快。
int hsum_epi32_sse2(__m128i x) {
#ifdef __AVX__
__m128i hi64 = _mm_unpackhi_epi64(x, x); // 3-operand non-destructive AVX lets us save a byte without needing a mov
#else
__m128i hi64 = _mm_shuffle_epi32(x, _MM_SHUFFLE(1, 0, 3, 2));
#endif
__m128i sum64 = _mm_add_epi32(hi64, x);
__m128i hi32 = _mm_shufflelo_epi16(sum64, _MM_SHUFFLE(1, 0, 3, 2)); // Swap the low two elements
__m128i sum32 = _mm_add_epi32(sum64, hi32);
return _mm_cvtsi128_si32(sum32); // SSE2 movd
//return _mm_extract_epi32(hl, 0); // SSE4, even though it compiles to movd instead of a literal pextrd r32,xmm,0
}
# gcc 5.3 -O3
pshufd xmm1,xmm0,0x4e
paddd xmm0,xmm1
pshuflw xmm1,xmm0,0x4e
paddd xmm0,xmm1
movd eax,xmm0
int hsum_epi32_ssse3_slow_smallcode(__m128i x){
x = _mm_hadd_epi32(x, x);
x = _mm_hadd_epi32(x, x);
return _mm_cvtsi128_si32(x);
}
在某些 CPU 上，对整数数据使用 FP shuffle 是安全的。 我没有这样做，因为在现代 CPU 上最多可以节省 1 或 2 个代码字节，而没有速度提升（代码大小/对齐效果除外）。
const __m128 t = _mm_add_ps(v, _mm_movehl_ps(v, v));
const __m128 sum = _mm_add_ss(t, _mm_shuffle_ps(t, t, 1));
const __m128 t1 = _mm_movehl_ps(v, v);
const __m128 t2 = _mm_add_ps(v, t1);
const __m128 sum = _mm_add_ss(t1, _mm_shuffle_ps(t2, t2, 1));
我发现这些速度与双HADDPS速度大致相同（但我没有进行过密切测量）。
您可以在 SSE3 中的两条HADDPS指令中执行此操作：
v = _mm_hadd_ps(v, v);
v = _mm_hadd_ps(v, v);
这会将总和放在所有元素中。
我肯定会尝试 SSE 4.2。 如果您多次执行此操作（我假设您是性能问题），则可以使用 (1,1,1,1) 预加载寄存器，然后执行多个 dot4(my_vec(s), one_vec)在上面。 是的，它做了一个多余的乘法，但这些现在相当便宜，这样的操作很可能由水平依赖性主导，这可能在新的 SSE 点积函数中得到更优化。 您应该进行测试，看看它是否优于 Paul R 发布的双水平添加。
我还建议将它与直接标量（或标量 SSE）代码进行比较 - 奇怪的是它通常更快（通常是因为它在内部被序列化但使用寄存器旁路紧密流水线化，其中特殊的水平指令可能无法快速路径（还）），除非你正在运行类似 SIMT 的代码，听起来你不是（否则你会做四个点积）。
通常，最快可能方式的问题以需要在时间关键循环中多次完成的任务为前提。
那么最快的方法可能是成对工作的迭代方法，它在迭代之间分摊了一些工作。
inline vec update(vec context, vec data) {
vec even = get_evens(context, data);
vec odd = get_odds(context, data);
return vertical_operation(even, odd);
}
void my_algo(vec *data, int N, vec_element_type *out) {
vec4 context{0,0,0,0};
context = update(context, data[0]);
int i;
for (int i = 0; i < N-1; i++) {
context = update(context, data[i+1]);
output[i] = extract_lane(context, 1);
}
context = update(context, anything);
output[N-1] = extract_lane(context, 1);
}
需要的总和将从累加器的第二个元素（索引 1）中找到（在 1 次迭代之后），而第一个元素将包含到目前为止所有元素的总减少量。
Reduct = [ -- ][ -- ][ -- ][ -- ]
New input = [i0 ][ i1 ][ i2 ][ i3 ]
evens = [ -- ][ -- ][ i0 ][ i2 ]
odds = [ -- ][ -- ][ i1 ][ i3 ]
------- vertical arithmetic reduction ----
Reduct = [ -- ][ -- ][ 01 ][ 23 ]
input = [ 4 ][ 5 ][ 6 ][ 7 ]
evens = [ -- ][ 01 ][ 4 ][ 6 ]
odds = [ -- ][ 23 ][ 5 ][ 7 ]
Reduct = [ -- ][ 0123 ][ 45 ][ 67 ]
New input: [ 8 ] [ 9 ] [ a ] [ b ]
evens = [ -- ][ 45 ][ 8 ][ a ]
odds = [0123][ 67 ][ 9 ][ b ]
------------------------------
Reduct = [0123][4567][ 89 ][ ab ]
我怀疑，对于 3 或 4 的向量长度，这是否会比 Cordes 先生提出的更快，但是对于 16 或 8 位数据，这种方法应该被证明是值得的。 那么当然需要分别执行 3 轮或 4 轮才能获得结果。
如果水平操作恰好是求和——那么实际上每个操作只能使用一个hadd 。
使用 192/256 位整数求和无符号 64 位整数向量的点积的最快方法？
[英]Fastest way to sum dot product of vector of unsigned 64 bit integers using 192/256 bit integer?
计算大数的数位和的最快方法（作为十进制字符串）
[英]Fastest way to calculate a digit-sum for a large number (as a decimal string)
在 SSE2 上进行无符号 64 位比较的最有效方法是什么？
[英]What is the most efficient way to do unsigned 64 bit comparison on SSE2?
使用 pre-SSE4 计算 vector2 double 的 floor 和 ceil
[英]Calculating floor & ceil of vector2 double using pre-SSE4
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.