【问题标题】:Improving performance of floating-point dot-product of an array with SIMD使用 SIMD 提高数组的浮点点积的性能
【发布时间】:2021-01-20 21:53:48
【问题描述】:

我有这个函数来计算一个双精度数组:

void avx2_mul_64_block(double& sum, double* lhs_arr, double* rhs_arr) noexcept
{
    __m256i accumulator = _mm256_setzero_pd();

    for (std::size_t block = 0; block < 64; block += 4)
    {
        __m256i lhs = _mm256_set_pd(
            lhs_arr[block    ],
            lhs_arr[block + 1],
            lhs_arr[block + 2],
            lhs_arr[block + 3]);

        __m256i rhs = _mm256_set_pd(
            rhs_arr[block    ],
            rhs_arr[block + 1],
            rhs_arr[block + 2],
            rhs_arr[block + 3]);

        accumulator = _mm256_add_pd(accumulator, _mm256_mul_pd(lhs, rhs));
    }
    double* res = reinterpret_cast<double*>(&accumulator);
    sum += res[0] + res[1] + res[2] + res[3];
}

,这段代码的性能不是我想要的。我相信让它成功 - 避免为其所有元素创建双数组,但我不知道如何做到这一点。

顺便说一句,与_mm256_setzero_si256相比,_mm256_setzero_pd 将整个功能减慢了一半。

我的标志:-O3 -ftree-vectorize -march=native

附:这不是真正的问题,只是设计问题。

【问题讨论】:

  • 请提供minimal reproducible example,您的示例将无法编译。你在使用编译器优化吗?代码有多快?你希望它有多快?您的输入是否符合适当的界限?如果不是,他们会吗?
  • 首先,您的注册类型错误。它应该是__m256d,而不是__m256i。其次,使用正确对齐的输入数组(32 字节对齐),您应该使用_mm256_load_pd 来获取数据。否则,您将依靠编译器来理解这是那些 _mm256_set_pd 调用试图实现的目标,而且可能不会。作为一个小的改进,您可以考虑对最终总和使用水平加法(使用_mm256_hadd_pd
  • 你看生成的asm了吗? set_pd 将数字按内存的相反顺序排列。您还可以查看编译器为幼稚代码生成的 asm,自动矢量化应该可以很好地使用 -ffast-math。
  • @paddy: _mm256_hadd_pd 对于单个向量的有效水平总和并不是特别有用,除非您正在优化代码大小而不是速度。但是,是的,绝对使用 loadloadu 内部函数和 __m256d,是的,hsum 可能会更好(参见 Get sum of values stored in __m256d with SSE/AVX
  • 几乎是How do you load/store from/to an array of doubles with GNU C Vector Extensions? 的副本,但这只是因为我的答案有一个关于英特尔内在函数的部分,而问题要求没有内在函数的 GNU C 本机向量内容。也相关:Why doesn't gcc resolve _mm256_loadu_pd as single vmovupd? - 除了这似乎不是 GCC,可能是铿锵声。 GCC 不会让你摆脱 __m256i 和 __m256d 之间的隐式转换

标签: c++ x86 simd intrinsics avx


【解决方案1】:

一些建议已经在 cmets 中提到,但我会尝试提出一些建议。

Haswell 和更新的 CPU 上的大多数 SIMD 浮点指令的倒数吞吐量都小于其延迟,这意味着如果并行执行多条指令,则可以提高性能。例如,根据 Agner Fog 的instruction tablesvaddpd 在 Haswell 上的延迟为 3,倒数吞吐量为 1 个时钟周期,这意味着 CPU 可以潜在地并行执行 3 条指令。更多的vmulpd 指令可以在其 5 和 0.5 个时钟周期内并行执行,以实现延迟和互惠吞吐量。

您的代码可能没有利用这种指令级并行性 (ILP),因为循环体依赖于在上一次循环迭代中更新的 accumulator 值。这是因为不允许编译器执行许多优化,例如对 FP 数的数学运算重新排序,因为这可能会导致数学上不同的结果。因此,您的算法会受到延迟限制。

您可以通过使用特定于编译器的选项来缓解这种情况,例如用于 gcc 和兼容编译器的 -ffast-math,但考虑到这种并行性,只重写您的算法更便于移植。

我还将在下面的代码中加入其他建议,例如:

  • 修复了错误的向量类型,应该是__m256d
  • 使用专用指令从内存中加载整个向量,而不是依赖编译器优化_mm256_set_pd
  • 使用 FMA 内在函数而不是依赖编译器优化 _mm256_add_pd+_mm256_mul_pd 对。 FMA 指令减少了计算的延迟,使加法有效地免费。 FMA 还产生更精确的结果,因为乘法和加法之间没有舍入。请注意,FMA 需要 AVX2,它不适用于仅支持 AVX 的 CPU。
  • 使用适当的内在函数从向量中提取最终总和(由于 double 无论如何都存储在向量寄存器中,这可能会在最终汇编程序中被优化掉)。
void avx2_mul_64_block(double& sum, double* lhs_arr, double* rhs_arr) noexcept
{
    __m256d accumulator1 = _mm256_setzero_pd();
    __m256d accumulator2 = _mm256_setzero_pd();

    for (std::size_t block = 0; block < 64; block += 4 * 2)
    {
        __m256d lhs1 = _mm256_loadu_pd(lhs_arr + block);
        __m256d lhs2 = _mm256_loadu_pd(lhs_arr + block + 4);
        __m256d rhs1 = _mm256_loadu_pd(rhs_arr + block);
        __m256d rhs2 = _mm256_loadu_pd(rhs_arr + block + 4);

        accumulator1 = _mm256_fmadd_pd(lhs1, rhs1, accumulator1);
        accumulator2 = _mm256_fmadd_pd(lhs2, rhs2, accumulator2);
    }

    accumulator1 = _mm256_add_pd(accumulator1, accumulator2);

    __m128d accumulator = _mm_add_pd(_mm256_castpd256_pd128(accumulator1),
        _mm256_extractf128_pd(accumulator1, 1));
    accumulator = _mm_add_pd(accumulator,
        _mm_unpackhi_pd(accumulator, accumulator));

    sum += _mm_cvtsd_f64(accumulator);
}

在上面的代码中,我使用了两个单独的累加器,因此 CPU 现在能够并行执行两条累加链。进一步提高并行性可能是有益的(参见上面提到的性能数据),但如果块长度不能被累加器的数量乘以向量中的元素数量整除,则问题可能会更大。您可能需要设置尾部处理,这可能会产生一些轻微的性能开销。

请注意,如前所述,由于算术运算和 FMA 的不同顺序以及因此数学误差的不同累积,此算法可能会产生不严格等于原始结果的结果。但是,这通常不是问题,尤其是double 的高精度。


上面代码中没有用到的一些建议:

  • 未使用水平加法 (_mm256_hadd_pd) 来累积最终总和,因为在当前的 Intel(最高 Coffee Lake)和 AMD(最高 Zen 2)处理器上,vhadd 指令的延迟比vunpckhpd 稍长+vaddpd 对,即使后者有依赖链。这可能会在未来的处理器中发生变化,并且使用水平加法可能会变得有益。不过,在当前 CPU 中,水平相加可能有助于节省一些代码大小。
  • 代码使用来自内存的未对齐负载,而不是_mm256_load_pd,因为支持 AVX2 的现代 CPU 上的未对齐负载不会有性能损失,只要负载实际上在运行时对齐或至少不对齐跨缓存线边界。跨越缓存线,尤其是页面边界时会有开销,但通常这仍然不会降低现代 CPU 上的性能(在 Peter Cordesthis 帖子中有一些性能数据,如以及那里链接的材料)。

【讨论】:

  • 很好的答案,但是一件小事,_mm256_hadd_pd 很慢,它会在所有 CPU 上解码成多个微操作。我通常这样做:gist.github.com/Const-me/0c08f7bef1fd32f31db81bf1c1cb72a1
  • @Sonts 是的,水平添加指令的延迟似乎比 unpack+add 对稍长。我已经更新了答案,谢谢。
  • 未对齐的加载对任何缓存行拆分都会产生延迟和吞吐量损失,因为加载执行单元需要第二次访问 L1d 以访问拆分的另一侧。 (也有有限数量的拆分缓冲区,以及用于 CPU 耗尽情况的性能计数器。)实际上,当数据还没有时,对于具有 256b 向量的未对齐输入,性能差异通常很小(几个 %) L1d 缓存中的热点 - 等待来自外部缓存或特别是 DRAM 的数据的瓶颈使核心 + L1d 有时间隐藏成本。与 AVX512 不同,错位成本更高。
  • @PeterCordes 当数据不在 L1d 缓存中时,与较低级别缓存和 RAM 的延迟相比,未对齐的访问损失(如果有)是微不足道的。当访问跨越页面边界时会有额外的惩罚。否则,如果数据在缓存中,我的印象是最近的 x86 CPU 中消除了惩罚。您是否有参考表明情况并非如此?
  • How can I accurately benchmark unaligned access speed on x86_64 有我来自 Skylake 的测试结果:重复使用相同的地址(L1d 中的热)缓存行拆分负载具有 1c 吞吐量,而非拆分负载为 0.5c。 (页面拆分加载的吞吐量约为 3.8c)。对于跨越缓存线边界的未对齐负载,确实是零惩罚,例如address % 64 &lt;= 60时加载一个dword
【解决方案2】:

正如 Marc Glisse 在上面的 cmets 中提到的,您可能希望在编译器标志中设置 -ffast-math。这是编译器很容易优化的函数之一,最好直接用 C++ 编写代码。

void mul_64_block(double& sum, double* lhs_arr, double* rhs_arr) {
    double res = 0;
    for(int i = 0; i < 64; ++i) {
        res += lhs_arr[i] * rhs_arr[i];
    }
    sum += res;
}

此 C++ 代码产生与您的 simd 代码相同的输出。

https://godbolt.org/z/cddPMd

【讨论】:

猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-09-27
  • 1970-01-01
  • 1970-01-01
  • 2020-04-17
  • 1970-01-01
  • 1970-01-01
  • 2021-01-04
相关资源
最近更新 更多