有没有办法获取存储在 __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];
此代码有效,但我想用 SSE/AVX 指令替换它。
最佳答案
看来您正在对输出数组的每个元素进行水平求和。 (也许作为 matmul 的一部分?)这通常是次优的;尝试对第 2 个内循环进行矢量化,这样您就可以在 vector 中生成 result[i + 0..3]
而根本不需要水平总和。
对于大于一个 vector 的数组的点积,垂直求和 ( into multiple accumulators ),最后只求和一次。
有关一般的水平缩减,请参阅 Fastest way to do horizontal SSE vector sum (or other reduction) - 提取高半部分并添加到低半部分。重复直到只剩下 1 个元素。
如果您在内部循环中使用它,您肯定不想使用 hadd(same,same)
。这需要 2 个 shuffle uops 而不是 1 个,除非你的编译器把你从你自己身上救了出来。 (而 gcc/clang 没有。)hadd
对代码大小有好处,但当你只有 1 个 vector 时几乎没有别的。对于两个不同的输入,它可能有用且高效。
对于 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
交换高电平/low halves(如果针对 Intel 进行调整)。并全程使用 256 位 FP 添加。如果您完全关心早期的 Ryzen,您可能会减少到 128,使用 _mm_shuffle_pd
交换,然后使用 vinsertf128
获得 256 位 vector 。还是用AVX2,vbroadcastsd
就这样的最终结果。但这在 Intel 上会比始终保持 256 位同时仍然避免 vhaddpd
慢。
使用 gcc7.3 -O3 -march=haswell
编译 on the Godbolt compiler explorer
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。
在第一代 Ryzen (Zen 1/1+) 上,根据 Agner Fog's instruction tables ,vextractf128
是 1 uop,延迟为 1c,吞吐量为 0.33c。
不幸的是,在 Zen 2 之前,@PaulR 的版本在 AMD 上很糟糕;这就像您可能会在 Intel 库或编译器输出中发现的“削弱 AMD”功能。 (我不认为 Paul 是故意这样做的,我只是指出忽略 AMD CPU 会导致代码在其上运行速度变慢。)
在 Zen 1 上,vperm2f128
是 8 微指令、3c 延迟和每 3c 吞吐量一个。 vhaddpd ymm
是 8 微指令(相对于您可能期望的 6 微指令),7c 延迟,每 3c 吞吐量一个。 Agner 说这是一个“混合域”指令。 256 位操作总是至少需要 2 微指令。
# 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 版本在 Intel 上可能至少好一点,以及很多 在 AMD 上更好。它还应该产生更少的热量,从而允许更高的涡轮增压/使用更少的电池电量。 (但希望这个 hsum 是整个循环中足够小的一部分,可以忽略不计!)
延迟也不差,所以真的没有理由使用低效的 hadd
/vpermf128
版本。
Zen 2 及更高版本具有 256 位宽的 vector 寄存器和执行单元(包括随机播放)。他们不必将跨车道洗牌分成许多 uops,但相反 vextractf128
不再像 vmovdqa xmm
那样便宜。 Zen 2 更接近英特尔的 256 位 vector 成本模型。
关于c++ - 使用 SSE/AVX 获取存储在 __m256d 中的值的总和,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49941645/