使用 SSE/AVX 获取存储在__m256d中的值的总和

acc = _mm256_add_pd(acc, _mm256_mul_pd(row, vec));
//acc in this point contains {2.0, 8.0, 18.0, 32.0}
acc = _mm256_hadd_pd(acc, acc);
result[i] = ((double*)&acc)[0] + ((double*)&acc)[2];

您似乎正在对输出数组的每个元素进行水平求和。 (也许是垫子的一部分？ 这通常是次优的;尝试在第二个从内部循环上矢量化，这样您就可以在向量中产生result[i + 0..3]，而根本不需要水平和.
对于大于一个向量的数组的点积，垂直求和(成多个累加器)，最后只求和一次。

有关一般的水平约化，请参阅执行水平 SSE 向量和(或其他约简)的最快方法 - 提取高半部分并添加到低半部分。 重复直到减少到 1 个元素。

如果您在内部循环中使用它，那么您绝对不想使用hadd(same,same). 这需要 2 个 shuffle uops 而不是 1 个，除非你的编译器将你从自己身上拯救出来。 (而 gcc/clang 没有。hadd适用于代码大小，但当您只有 1 个向量时，几乎没有其他内容。 对于两个不同的输入，它可以是有用和高效的。

---

对于 AVX，这意味着我们唯一需要的 256 位操作是提取，这在 AMD 和 Intel 上速度很快。 那么剩下的都是 128 位的：

#include <immintrin.h>
inline
double hsum_double_avx(__m256d v) {
__m128d vlow  = _mm256_castpd256_pd128(v);
__m128d vhigh = _mm256_extractf128_pd(v, 1); // high 128
vlow  = _mm_add_pd(vlow, vhigh);     // reduce down to 128
__m128d high64 = _mm_unpackhi_pd(vlow, vlow);
return  _mm_cvtsd_f64(_mm_add_sd(vlow, high64));  // reduce to scalar
}

如果您希望将结果广播到__m256d的每个元素，则可以使用vshufpd和vperm2f128来交换高/低半(如果针对英特尔进行调整)。 并始终使用 256 位 FP 添加。 如果你关心早期的 Ryzen，你可能会减少到 128，使用_mm_shuffle_pd交换，然后vinsertf128得到一个 256 位的向量。 或者使用 AVX2，vbroadcastsd最终结果。 但这在英特尔上会比一直保持 256 位同时仍然避免vhaddpd要慢。

在 Godbolt 编译器资源管理器上使用gcc7.3 -O3 -march=haswell编译

vmovapd         xmm1, xmm0               # silly compiler, vextract to xmm1 instead
vextractf128    xmm0, ymm0, 0x1
vaddpd          xmm0, xmm1, xmm0
vunpckhpd       xmm1, xmm0, xmm0         # no wasted code bytes on an immediate for vpermilpd or vshufpd or anything
vaddsd          xmm0, xmm0, xmm1         # scalar means we never raise FP exceptions for results we don't use
vzeroupper
ret

在内联(你肯定希望它)之后，vzeroupper沉到整个函数的底部，希望vmovapd优化，vextractf128到不同的寄存器中，而不是破坏保存_mm256_castpd256_pd128结果的 xmm0。

---

在第一代锐龙(Zen 1/1+)上，根据Agner Fog的指令表，vextractf128是1 uop，1c延迟和0.33c吞吐量。

不幸的是，@PaulR的版本在Zen 2之前的AMD上很糟糕;它就像你可能会在英特尔库或编译器输出中找到的东西，作为"残缺的AMD"功能。 (我不认为保罗故意这样做，我只是指出忽略AMD CPU如何导致代码运行速度变慢。

在 Zen 1 上，vperm2f128是 8 uops、3c 延迟和每 3c 吞吐量一个。vhaddpd ymm是 8 uops(与您可能预期的 6 个相比)，7c 延迟，每 3c 吞吐量一个。 Agner说这是一个"混合域"指令。 256 位操作始终至少需要 2 uops。

# Paul's version                      # Ryzen      # Skylake
vhaddpd       ymm0, ymm0, ymm0         # 8 uops     # 3 uops
vperm2f128    ymm1, ymm0, ymm0, 49     # 8 uops     # 1 uop
vaddpd        ymm0, ymm0, ymm1         # 2 uops     # 1 uop
# total uops:   # 18         # 5

与。

# my version with vmovapd optimized out: extract to a different reg
vextractf128    xmm1, ymm0, 0x1        # 1 uop      # 1 uop
vaddpd          xmm0, xmm1, xmm0       # 1 uop      # 1 uop
vunpckhpd       xmm1, xmm0, xmm0       # 1 uop      # 1 uop
vaddsd          xmm0, xmm0, xmm1       # 1 uop      # 1 uop
# total uops:   # 4          # 4

总 uop 吞吐量通常是混合加载、存储和 ALU 的代码瓶颈，因此我预计 4-uop 版本在英特尔上可能至少会好一点，在 AMD 上也会好得多。 它还应该产生稍微少一点的热量，从而允许稍微高一点的涡轮增压/使用更少的电池电量。 (但希望这个 hsum 是你总循环中足够小的一部分，可以忽略不计！

延迟也没有更糟，所以真的没有理由使用低效的hadd/vpermf128版本。

---

Zen 2 及更高版本具有 256 位宽矢量寄存器和执行单元(包括随机播放)。 他们不必将车道交叉洗牌分成许多 uop，但相反vextractf128不再像vmovdqa xmm那么便宜。 Zen 2更接近英特尔的256位矢量成本模型。

你可以这样做：

acc = _mm256_hadd_pd(acc, acc);    // horizontal add top lane and bottom lane
acc = _mm256_add_pd(acc, _mm256_permute2f128_pd(acc, acc, 0x31));  // add lanes
result[i] = _mm256_cvtsd_f64(acc); // extract double

注意：如果这是在代码的"热"(即性能关键)部分(特别是在AMD CPU上运行)，那么您可能想看看Peter Cordes关于更高效实现的答案。

在gcc和clang中，SIMD 类型是内置的矢量类型。 例如：

# avxintrin.h
typedef double __m256d __attribute__((__vector_size__(32), __aligned__(32)));

这些内置向量支持索引，因此您可以方便地编写它，并将其留给编译器来制作好的代码：

double hsum_double_avx2(__m256d v) {
return v[0] + v[1] + v[2] + v[3];
}

clang-14 -O3 -march=znver3 -ffast-math生成与 Peter Cordes 内部函数相同的程序集：

# clang -O3 -ffast-math
hsum_double_avx2:
vextractf128    xmm1, ymm0, 1
vaddpd  xmm0, xmm0, xmm1
vpermilpd       xmm1, xmm0, 1           # xmm1 = xmm0[1,0]
vaddsd  xmm0, xmm0, xmm1
vzeroupper
ret

不幸的是，gcc做得更糟，这会产生次优指令，没有利用重新关联 3 个+操作的自由，并使用vhaddpd xmm来完成v[0] + v[1]部分，这在 Zen 3 上花费了 4 uops。 (或在英特尔 CPU 上 3 次 uops，2 次随机播放 + 一个添加。

-ffast-math当然是编译器能够做好工作所必需的，除非您将其编写为(v[0]+v[2]) + (v[1]+v[3])。 有了这个，叮当仍然与没有-ffast-math-O3 -march=icelake-server做同样的asm。

>理想情况下，我想像上面那样编写纯代码，让编译器使用特定于 CPU 的成本模型，以正确的顺序为该特定 CPU 发出最佳指令。

一个原因是，Haswell的劳动密集型手工编码最佳版本对于Zen3来说很可能不是最佳的。 特别是对于这个问题，情况并非如此：从缩小到 128 位开始，vextractf128+vaddpd在任何地方都是最佳的。 不同 CPU 上的随机播放吞吐量略有不同;例如，Ice Lake和后来的英特尔可以在端口1或5上运行vshufps，但像vpermilps/pd或vunpckhpd这样的一些洗牌仍然只在端口5上运行。 Zen 3(如 Zen 2 和 4)对其中任何一个洗牌都有很好的吞吐量，所以 clang 的 asm 恰好在那里很好。 但不幸的是，clang -march=icelake-server仍然使用vpermilpd

如今，一个常见的用例是在云中计算，具有不同的 CPU 型号和代次，在该主机上编译具有-march=native -mtune=native的代码以获得最佳性能。

从理论上讲，如果编译器更聪明，这将优化像这样的短序列到理想的asm，并为启发式方法(如内联和解展开)做出通常不错的选择。 对于仅在一台计算机上运行的二进制文件，它通常是最佳选择，但正如 GCC 在这里演示的那样，结果通常远非最佳。 幸运的是，现代AMD和英特尔在大多数时候并没有太大的不同，某些指令的吞吐量不同，但对于相同的指令通常是单UOP。