考虑执行相同计算的这三个函数:
#include <x86intrin.h>
void testfunc_loop(double a, double b, double* dst)
{
double f[] = {a,b,-a,-b};
for(int n = 0; n < 4; ++n)
{
dst[n] = 0.1 + f[n]*(1.0 + 0.5*f[n]);
}
}
void testfunc_flat(double a, double b, double* dst)
{
dst[0] = 0.1 + ( a)*(1.0 + 0.5*( a));
dst[1] = 0.1 + ( b)*(1.0 + 0.5*( b));
dst[2] = 0.1 + (-a)*(1.0 + 0.5*(-a));
dst[3] = 0.1 + (-b)*(1.0 + 0.5*(-b));
}
void testfunc_avx(double a, double b, double* dst)
{
__m256d one = _mm256_set1_pd(1.0);
__m256d half = _mm256_set1_pd(0.5);
__m256d tenth = _mm256_set1_pd(0.1);
__m256d v = _mm256_set_pd(-b,-a,b,a);
__m256d q = _mm256_add_pd(tenth,_mm256_mul_pd(v,_mm256_add_pd(one,_mm256_mul_pd(half,v))));
_mm256_store_pd(dst,q);
}
GCC 4.7.2(使用 -O3 -mavx)对循环版本进行向量化,但对展开的循环使用标量运算。三个版本所用的(归一化)时间为 3.3(循环、自动矢量化)、1.2(展开、标量)、1(手动 avx)。展开版本和手动矢量化函数之间的性能差异很小,但我想强制矢量化,因为它对完整代码是有益的。
使用不同编译器进行测试(请参阅 https://godbolt.org/g/HJH2CX )表明 clang 自动矢量化展开的循环(自版本 3.4.1 起),但 GCC 直至版本 7 不会。我可以使用 GCC 自动获得类似的矢量化吗?我只找到了与循环矢量化相关的优化选项,这没有帮助。 GCC website自 2011 年以来没有显示任何新闻。
最佳答案
gcc 通常不会对单向量内容进行向量化。我见过类似的缺乏自动向量化的情况,如 Point{ double x,y; }
现有代码库中的类 ( Endless Sky )。
因此,如果您需要内联快速代码,您可能必须手动针对 x86 进行矢量化。 (您还可以考虑传递 __m256d
值而不是存储到数组中。)
顺便说一句,手动矢量化版本可能会更快。我在 Godbolt 上尝试了一下,发现 _mm256_set_pd(-b,-a, b,a)
正在编译成愚蠢的代码,因此手动执行会更有效。此外,如果您没有可用的 FMA,您可以通过重构表达式来减少延迟。 (允许 0.1 -/+ a 与平方同时发生)。 Code+asm here
// 0.1 + a + 0.5*a*a = 0.1 + a * (1.0 + 0.5*a)
// + b
// 0.1 - a + 0.5*a*a = 0.1 + (-a) * (1.0 - 0.5*a)
// - b
// only one of the mul+add pairs can fuse into an FMA
// but 0.1+/-a happens in parallel with 0.5*a*a, so it's lower latency without FMA
void testfunc_latency_without_fma(double a, double b, double* dst)
{
// 6 AVX instructions other than the store:
// 2 shuffles, 1 mul, 1 FMA, 1 add. 1 xor. In theory could run one iteration per 2 clocks
__m256d abab = _mm256_setr_pd(a, b, a, b); // 1c + 3c latency (unpck + vinsertf128)
__m256d sq256 = _mm256_mul_pd(abab, abab); // 5c
const __m256d half = _mm256_set1_pd(0.5);
__m256d sq_half256 = _mm256_mul_pd(sq256, half); // 5c: dependency chain 1 ready in 14c from a and b being ready
// we could use a smaller constant if we do _mm256_setr_m128d(ab, xor(ab, set1(-0.))
// but that takes an extra vinsertf128 and this part isn't the critical path.
const __m256d upper_signmask = _mm256_setr_pd(0. ,0. ,-0. ,-0.);
__m256d ab_negab = _mm256_xor_pd(abab, upper_signmask); // chain2: 1c from abab
const __m256d tenth = _mm256_set1_pd(0.1);
__m256d tenth_plusminus_ab = _mm256_add_pd(tenth, ab_negab); // chain2: 3c (ready way ahead of squared result)
__m256d result = _mm256_add_pd(tenth_plusminus_ab, sq_half256); // fuses with the sq_half
_mm256_store_pd(dst, result);
}
<小时/>
不知道为什么在测试时自动矢量化循环如此慢。它会将标量存储到数组中,然后进行矢量加载,从而导致约 11 个周期的存储转发停顿。因此它的延迟比其他两种方式都要高得多,但我不知道这是否会影响吞吐量。 IDK 你是如何测试的;也许您正在使用一个调用的结果作为下一个调用的输入?或者同一 block 堆栈空间上重复的存储转发停顿可能是一个问题?
<小时/>一般来说,对于较大的数组,gcc 确实喜欢指针对齐。它生成巨大的完全展开的标量开头/结尾代码以到达对齐的指针,然后使用对齐的存储/加载。
这对现代 CPU 没有太大帮助(但通常也不会造成太大伤害),特别是对于通常在运行时对齐的数据,但如果数据通常是对齐的,则可能会很好未对齐,或者运行在 Nehalem 之前的 CPU 上。
不知道这是否与 gcc 不愿意自动矢量化小东西有关,但告诉它 double*
对齐似乎没有帮助。
我认为问题的一部分在于它不擅长插入洗牌来矢量化需要洗牌的代码。
关于gcc - 如何使用 GCC 获得更好的矢量化?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39947582/