进行水平SSE矢量总和（或其他还原）的最快方法

Question

给定三个（或四个）浮子的向量。总结最快的方法是什么？

SSE（移动，洗牌，添加，movd）总是比x87快吗？ SSE3中的水平添加说明值得吗？

搬到FPU，然后FADDP，FADDP的成本是多少？什么是最快的特定指令序列？

“尝试安排事情，以便您可以一次总结四个向量”将不会被视为答案。 :-)例如，为了求和一个数组，您可以使用多个向量蓄能器进行垂直总和（隐藏addps延迟），并在循环后降低到一个，但是您需要水平总和最后一个向量。

Answer 1

我肯定会尝试一下SSE 4.2。如果您要多次执行此操作（我认为如果您是性能是问题），则可以预先加载（1,1,1,1），然后执行几个dot4（my_vec（s），one_vec）在上面。是的，它会产生多余的乘积，但是如今这些倍数相当便宜，这种OP可能由水平依赖项主导，这在新的SSE DOT产品功能中可能更优化。您应该测试以查看它是否胜过双水平添加Paul R发布。

我还建议将其与直型标量（或标量SSE）代码进行比较 - 奇怪的是，它通常更快（通常是因为它内部是序列化的，但使用寄存器旁路进行了紧密的管道，在此，在特殊的水平说明中可能不会快速（尚未途径）（尚））正在运行类似Simt的代码，听起来您不是（否则您将制作四个点产品）。

Answer 2

通常，最快的方法的问题 会以一项需要多次完成的任务，即临时循环。

然后，最快的方法可能是迭代方法成对的迭代方法，它摊销了迭代之间的某些工作。

通过将矢量拆分为低/高零件来减少的总成本为O（log2（n）），而通过将矢量拆分为偶数/奇数序列的摊销成本为o（1）。

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比MR提出的速度要快，但是对于16或8位数据，该方法应该被证明是值得的。当然，在获得结果之前，必须分别进行3或4轮。

如果水平操作恰好是总和 - 那么实际上只能使用一个 hadd 每次迭代。

Answer 3

通常，对于任何形式的矢量水平还原，提取/洗牌高的一半以与低点对齐，然后垂直添加（或min/max/of/or/and/and/xor/multiply/whyther）；重复直到只有一个元素（在其余的矢量中有高垃圾）。

如果您从矢量宽于128位开始，则缩小一半，直到到达128（那么您可以在该矢量上使用此答案中的一个功能）。但是，如果您需要在末尾广播到所有元素的结果，那么您可以考虑一路进行全宽宽。

相关的Q＆amp;与更宽的向量和整数，以及 fp

• __ M128 和 __ M128D 此答案（请参阅下面）

• __ m256d perf for Ryzen 1与Intel（显示为什么 vextractf128 比 vperm2f128 ）获得__m256d中存储的值的总和，

• 的值__m256 如何水平总和__m256？
  

• a href =“ https://stackoverflow.com/questions/10454150/10454150/intel-avx-256-bits-version-of-dot-product-for-double-double-double-floation-floation-floation-point-v/474444445367#47445367”> intel AVX：单个向量的双精度浮点变量的256位版本的DOT产品。

• 数组的点乘积（不仅是3或4个元素的一个向量）：将垂直mul/add或fma或fma 最终。 完整的AVX+FMA阵列点示例示例循环之后有效的Hsum 。 （对于简单的总和或其他降低数组，请使用该模式，但没有多个部分，例如添加而不是FMA）。 do 不是为每个SIMD向量分别进行水平工作；最后一次。

  如何使用Simd 计数字符出现为整数示例计数 _MM256_CMPEQ_EPI8 匹配，在整个数组中再次匹配，仅在末尾进行hsumm。 （值得一提的是进行一些8位积累，然后扩大8 - ＆gt; 64位，以避免溢出而无需完成全部HSUM。）

Integer

• __ m128i 32位元素：此答案（见下文）。 64位元素应该很明显：只有一个PSHUFD/PADDQ步骤。

  


• __ m128i 8位unsigned uint8_t 元素不包装/溢出： psadbw 反对 _mm_setzero_si128（），然后hsum两个QWord Harves（或4或8 。 最快的方式到达水平sme sse sse sse sse nosigned byte vector 显示SSE2 128位。
  在__m512i中求和8位整数，具有AVX内在 有一个AVX512示例。 如何使用simd 计数字符出现有一个avx2 __ M256I

  （对于 int8_t 签名字节您可以XOR SET1_EPI8（0x80）在悲伤之前翻转至未签名，然后从最终的HSUM中减去偏差；请参阅 details 也显示了仅在内存中进行9个字节的优化16）。

• 16位未签名： _mm_madd_epi16 带有set1_epi16（1）是单一uop扩大的水平添加： simd：累积相邻对。然后继续使用32位的Hsum。

• __ M256i 和 __ M512i 带有32位元素。
  最快的方法使用AVX512或AVX2 计算所有包装32位整数的总和。对于AVX512，英特尔添加了为您执行此操作的一堆“减少”内联函数（不是硬件说明），例如 _MM512_REDUCE_ADD_PS （以及PD，EPI32和EPI64）。还要降低_min/max/mul/和/或。手动导致基本相同的ASM。

• 水平最大值（而不是添加）：使用SSE中的__M128i向量获取最大值？

---

this 问题的主要答案：主要是float和 __ M128

以下是基于 Agner Fog的Microarch指南的Microarch指南和说明表。另请参见 x86 tag wiki。它们在任何CPU上都应有效，没有主要瓶颈。 （例如，我避免有助于一个Uarch但在另一个UARCH上慢一点的事情）。代码尺寸也被最小化。

常见的SSE3 / SSSE3 2X HADD < / code>习惯仅适用于代码大小，而不是任何现有CPU的速度。有一些用例（例如转台和添加，请参见下文），但是单个向量不是其中之一。

我还提供了一个AVX版本。使用AVX/AVX2的任何水平减少都应以 vextractf128 和“垂直”操作开始，以减少一个XMM（ __ M128 ）向量。通常，对于宽矢量，您最好的选择是重复缩小一半，直到到达128位向量，而不论元素类型如何。 （除了8位整数外，如果您想在没有溢出到更宽的元素的情况下进行HSUM，则 vpsadbw 是第一步。）

请参阅所有此代码的ASM输出 agner fog的C ++ vector类库 horizo​​ntal_add functions。 （消息板线程和 github ）。我使用CPP宏来选择用于SSE2，SSE4和AVX的代码尺寸的最佳洗牌，并避免使用 movdqa 何时不可用。

---

需要考虑以下方面的权衡：

• 代码尺寸：出于L1 I-CACH的原因而较小，并且从磁盘（较小的二进制文件）中获取代码。总二进制规模主要是针对整个程序反复做出的编译器决策。如果您不愿用内在的用手编码一些内容，那么如果为整个程序提供任何加速，则值得花几个代码字节（请注意使展开看起来不错的微问题）。
• UOP-CACHE尺寸：通常比L1 I $更宝贵。 4单一UOP指令的空间比2 HADDPS 的空间少，因此在这里非常相关。
• 延迟：有时相关的
• 吞吐量（后端端口）：通常无关紧要，水平和不应是最内向的循环中唯一的东西。端口压力仅作为包含此过程的整个循环的一部分。
• 吞吐量（总前端融合域UOPS）：如果周围的代码不在HSUM使用的端口上瓶颈，则这是HSUM对整个物体吞吐量的影响的代理。

当水平添加不经常：

CPU 没有UOP-CACHE 可能会喜欢2x HADDPS 如果很少使用：运行时它的运行速度很慢。 ，但这并不常见。只有2个说明最大程度地减少对周围代码的影响（I $大小）。

CPU 使用UOP-CACHE < / strong>可能会偏爱更少的UOPS，即使它是更多的说明 / X86代码大小。使用的总UOPS缓存线是我们想要最小化的，它不像最小化总UOPS那样简单（占分支和32B边界总是启动新的UOP缓存线）。

无论如何，话虽如此，水平总和出现了一个 lot ，所以这是我仔细制作一些编译的版本的尝试。在任何真实硬件上都没有基准测试，甚至仔细测试。洗牌常数或其他东西中可能有错误。

---

如果您正在制作代码的后备 /基线版本，请记住，只有旧的CPU才能运行< / strong>；较新的CPU将运行您的AVX版本，SSE4.1或其他。

旧的CPU，例如K8和Core2（Merom），而更早的Core2（Merom）只有64位随机装置。 Core2在大多数说明中具有128位执行单元，但没有用于混音。 （Pentium M和K8将所有128B矢量说明作为两个64位半半处理）。

像 movhlps 之类的示意者在64位块中移动数据（在64位内部没有改组）也很快。

相关：在新CPU上进行散装，以及避免使用1/时钟散装吞吐量瓶颈的技巧：在AVX512中的128位交叉车道操作提供更好的性能吗？

slow Shuffles ：

• movhlps （merom>（merom>） 1UOP）比 shufps （merom：3UOPS）快得多。在五角星上，比 Movaps 便宜。此外，它在Core2上的FP域中运行，避免了其他混乱的旁路延迟。
• umpcklpd 比 unpcklps 快。
• pshufd 很慢， pshuflw / pshufhw 很快（因为它们只会随机降低64位半场）
• pshufb mm0 （mmx ）快速， pshufb xmm0 很慢。
• HADDPS 非常慢（Merom和Pentium M上的6UOPS）
• movshdup （merom：1UOP）很有趣：这是唯一的1uop insn insn insn in 64B元素。

shufps core2（包括Penryn）将数据带入整数域，导致旁路延迟使其返回 addps 的FP执行单元，但是 movhlps < /代码>完全在FP域中。 SHUFPD 也在浮点域中运行。

movshdup 在整数域运行，但仅是一个UOP。

AMD K10，Intel Core2（Penryn/Wolfdale）和后来的所有CPU，将所有XMM随机运行为单个UOP。 （但请在Penryn上注意带有 shufps 的旁路延迟，避免使用 movhlps ）

---

没有AVX，避免浪费 Move> Moveaps / movdqa 指令需要仔细选择洗牌。只有少数几个散装可以用作复制和剃须，而不是修改目的地。可以将来自两个输入的数据组合的混合（例如 umpck*或 movhlps ）与不再需要的TMP变量一起使用，而不是 _MM_MOVEHL_PS（相同，相同） 。

其中一些可以更快地做（节省动作），但通过将假人arg用作初始混音的目的地来丑陋 /更少“清洁”。< / strong>：

// 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
}

---

___m128 float with sse1（aka） SSE）：

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

我报告了a clang bug在悲观的造成混乱。它有自己的内部代表，用于改组，并将其恢复为洗牌。 GCC经常使用直接匹配您使用的固有的说明。

通常，在指令选择未手动调整的代码中，Clang的表现要好于GCC，或者即使在非构成案例最佳的情况下，恒定的传播也可以简化事物。总体而言，编译器像适当的编译器有关内在的编译器，而不仅仅是汇编器，这是一件好事。编译器通常可以从标量C中产生良好的ASM，甚至不会尝试按照ASM的方式工作。最终，编译器将将内在物作为另一个C运算符作为优化器的输入。

---

__m128带有SSE3的浮动，

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

这具有多个优点：

• 不需要任何 Movapaps 副本可以围绕破坏性的洗牌工作（无AVX）： movshdup xmm1，xmm2 的目的地仅写作，因此它为我们创建 tmp 。这也是为什么我使用 movehl_ps（tmp，sums）而不是 movehl_ps（sums，sums）。

  。

• 小型代码大小。改组指令很小： movhlps 是3个字节， movshdup 为4个字节（与 shufps 相同）。不需要立即字节，因此使用AVX， vshufps 是5个字节，但是 vmovhlps and vmovshdup 均为4。

。代码> addps 而不是 addss 。由于它不会在内部环内使用，因此切换额外晶体管的额外能量可能可以忽略不计。上层3个元素的FP异常不是风险，因为所有元素都有有效的FP数据。但是，clang/llvm实际上“理解”向量的示意图，如果知道只有低元素很重要，则会发出更好的代码。

像SSE1版本一样，添加奇数元素可能会导致fp异常（例如溢出），否则不会发生，但这不是问题。 Denmals很慢，但是产生A +INF结果的IIRC并不是大多数Uarches。

---

SSE3优化用于代码尺寸的SSE Size

如果代码大小是您的主要问题，则两个 HADDPS （ _MM_HADD_PS ）指令将执行此技巧（Paul R的答案）。这也是最容易输入和记住的。但是，它不是快速。甚至英特尔Skylake仍然将每个 HADDPS 分解为3个UOP，并具有6个周期延迟。因此，即使它保存了机器代码字节（L1 I-CACHE），它仍占用了可估计的UOP-CACHE中的更多空间。 haddps 的真实用例： transpose-and-sum问题，或在中间步骤进行缩放在此sse <代码> atoi（）实现。

---

__m256带有AVX的float：

此版本保存代码字节vs. 。

#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

---

__M128D双重精确：

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。如果洗牌端口压力（通常是Alu Uops）是瓶颈，那很好。 （请注意，它不需要 sub rsp，8 或任何

东西并总结所有元素，但是编译器通常没有意识到该数组的低元素仍在商店前的寄存器中。

---

__m128i int32_t Integer：

pshufd 是一个方便的复制和调整。不幸的是，位和字节偏移是就地的， punpckhqdq 将目的地的最高一半放在结果的低一半中，与 movhlps 相反一半陷入另一个寄存器。

在某些CPU上使用 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 Shuffles。我没有这样做，因为在现代CPU上最多可以节省1或2个代码字节，而没有速度增长（除了代码大小/对齐效果）。

Answer 4

SSE2

全部四个：

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));

R1+R2+R3：

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));

我发现它们的速度与double haddps （但我没有太仔细地测量）。

Answer 5

您可以在SSE3中的两个 HADDPS 指令中进行操作：

v = _mm_hadd_ps(v, v);
v = _mm_hadd_ps(v, v);

这将总和在所有元素中。