本文介绍了FMA指令显示为三个打包双操作?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在分析一段线性代数代码,它是直接调用内在函数,例如

I'm analyzing a piece of linear algebra code which is calling intrinsics directly, e.g.

v_dot0  = _mm256_fmadd_pd( v_x0, v_y0, v_dot0 );

我的测试脚本计算了两个长度为4的双精度向量的点积(因此只需调用一次_mm256_fmadd_pd),重复十亿次.当我用perf计算操作次数时,我得到如下信息:

My test script computes the dot product of two double precision vectors of length 4 (so only one call to _mm256_fmadd_pd needed), repeated 1 billion times. When I count the number of operations with perf I get something as follows:

Performance counter stats for './main':

             0      r5380c7 (skl::FP_ARITH:512B_PACKED_SINGLE)                                                      (49.99%)
             0      r5340c7 (skl::FP_ARITH:512B_PACKED_DOUBLE)                                                      (49.99%)
             0      r5320c7 (skl::FP_ARITH:256B_PACKED_SINGLE)                                                      (49.99%)
 2'998'943'659      r5310c7 (skl::FP_ARITH:256B_PACKED_DOUBLE)                                                      (50.01%)
             0      r5308c7 (skl::FP_ARITH:128B_PACKED_SINGLE)                                                      (50.01%)
 1'999'928'140      r5304c7 (skl::FP_ARITH:128B_PACKED_DOUBLE)                                                      (50.01%)
             0      r5302c7 (skl::FP_ARITH:SCALAR_SINGLE)                                                           (50.01%)
 1'000'352'249      r5301c7 (skl::FP_ARITH:SCALAR_DOUBLE)                                                           (49.99%)

256B_PACKED_DOUBLE操作的数量大约是令我感到惊讶. 30亿,而不是10亿,因为这是我的体系结构指令集中的一条指令. 为什么perf每次调用_mm256_fmadd_pd时都要计算3次压缩双精度运算?

I was surprised that the number of 256B_PACKED_DOUBLE operations is approx. 3 billion, instead of 1 billion, as this is an instruction from my architecture's instruction set. Why does perf count 3 packed double operations per call to _mm256_fmadd_pd?

注意:为了测试代码没有意外调用其他浮点运算,我注释了对上述内在函数的调用,并且perf完全计数了零个256B_PACKED_DOUBLE运算,正如预期的那样.

Note: to test that the code is not calling other floating point operations accidentally, I commented out the call to the above mentioned intrinsic, and perf counts exactly zero 256B_PACKED_DOUBLE operations, as expected.

根据要求MCVE:

ddot.c

#include <immintrin.h>  // AVX

double ddot(int m, double *x, double *y) {
    int ii;
    double dot = 0.0;

    __m128d u_dot0, u_x0, u_y0, u_tmp;
    __m256d v_dot0, v_dot1, v_x0, v_x1, v_y0, v_y1, v_tmp;

    v_dot0 = _mm256_setzero_pd();
    v_dot1 = _mm256_setzero_pd();
    u_dot0 = _mm_setzero_pd();

    ii = 0;

    for (; ii < m - 3; ii += 4) {
        v_x0 = _mm256_loadu_pd(&x[ii + 0]);
        v_y0 = _mm256_loadu_pd(&y[ii + 0]);
        v_dot0 = _mm256_fmadd_pd(v_x0, v_y0, v_dot0);
    }
    // reduce
    v_dot0 = _mm256_add_pd(v_dot0, v_dot1);
    u_tmp = _mm_add_pd(_mm256_castpd256_pd128(v_dot0), _mm256_extractf128_pd(v_dot0, 0x1));
    u_tmp = _mm_hadd_pd(u_tmp, u_tmp);
    u_dot0 = _mm_add_sd(u_dot0, u_tmp);
    _mm_store_sd(&dot, u_dot0);
    return dot;
}

main.c:

#include <stdio.h>

double ddot(int, double *, double *);

int main(int argc, char const *argv[]) {
    double x[4] = {1.0, 2.0, 3.0, 4.0}, y[4] = {5.0, 5.0, 5.0, 5.0};
    double xTy;
    for (int i = 0; i < 1000000000; ++i) {
        ddot(4, x, y);
    }
    printf(" %f\n", xTy);
    return 0;
}

我以

sudo perf stat -e r5380c7 -e r5340c7 -e r5320c7 -e r5310c7 -e r5308c7 -e r5304c7 -e r5302c7 -e r5301c7 ./a.out

ddot的反汇编如下:

0000000000000790 <ddot>:
 790:   83 ff 03                cmp    $0x3,%edi
 793:   7e 6b                   jle    800 <ddot+0x70>
 795:   8d 4f fc                lea    -0x4(%rdi),%ecx
 798:   c5 e9 57 d2             vxorpd %xmm2,%xmm2,%xmm2
 79c:   31 c0                   xor    %eax,%eax
 79e:   c1 e9 02                shr    $0x2,%ecx
 7a1:   48 83 c1 01             add    $0x1,%rcx
 7a5:   48 c1 e1 05             shl    $0x5,%rcx
 7a9:   0f 1f 80 00 00 00 00    nopl   0x0(%rax)
 7b0:   c5 f9 10 0c 06          vmovupd (%rsi,%rax,1),%xmm1
 7b5:   c5 f9 10 04 02          vmovupd (%rdx,%rax,1),%xmm0
 7ba:   c4 e3 75 18 4c 06 10    vinsertf128 $0x1,0x10(%rsi,%rax,1),%ymm1,%ymm1
 7c1:   01 
 7c2:   c4 e3 7d 18 44 02 10    vinsertf128 $0x1,0x10(%rdx,%rax,1),%ymm0,%ymm0
 7c9:   01 
 7ca:   48 83 c0 20             add    $0x20,%rax
 7ce:   48 39 c1                cmp    %rax,%rcx
 7d1:   c4 e2 f5 b8 d0          vfmadd231pd %ymm0,%ymm1,%ymm2
 7d6:   75 d8                   jne    7b0 <ddot+0x20>
 7d8:   c5 f9 57 c0             vxorpd %xmm0,%xmm0,%xmm0
 7dc:   c5 ed 58 d0             vaddpd %ymm0,%ymm2,%ymm2
 7e0:   c4 e3 7d 19 d0 01       vextractf128 $0x1,%ymm2,%xmm0
 7e6:   c5 f9 58 d2             vaddpd %xmm2,%xmm0,%xmm2
 7ea:   c5 f9 57 c0             vxorpd %xmm0,%xmm0,%xmm0
 7ee:   c5 e9 7c d2             vhaddpd %xmm2,%xmm2,%xmm2
 7f2:   c5 fb 58 d2             vaddsd %xmm2,%xmm0,%xmm2
 7f6:   c5 f9 28 c2             vmovapd %xmm2,%xmm0
 7fa:   c5 f8 77                vzeroupper 
 7fd:   c3                      retq   
 7fe:   66 90                   xchg   %ax,%ax
 800:   c5 e9 57 d2             vxorpd %xmm2,%xmm2,%xmm2
 804:   eb da                   jmp    7e0 <ddot+0x50>
 806:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
 80d:   00 00 00 

推荐答案

我刚刚在SKL上使用asm循环进行了测试.像vfmadd231pd ymm0, ymm1, ymm3这样的FMA指令将2个fp_arith_inst_retired.256b_packed_double计数,即使它是单个uop!

I just tested with an asm loop on SKL. An FMA instructions like vfmadd231pd ymm0, ymm1, ymm3 counts for 2 counts of fp_arith_inst_retired.256b_packed_double, even though it's a single uop!

我猜英特尔真的想要FLOP计数器,而不是指令或uop计数器.

您的第3个256位FP uop可能来自您正在做的其他事情,例如,水平和开始时先进行256位改组和另一个256位加法,而不是先减少到128位.希望您不要使用_mm256_hadd_pd

Your 3rd 256-bit FP uop is probably coming from something else you're doing, like a horizontal sum that starts out doing a 256-bit shuffle and another 256-bit add, instead of reducing to 128-bit first. I hope you're not using _mm256_hadd_pd!

测试代码内循环:

$ asm-link -d -n "testloop.asm"  # assemble with NASM -felf64 and link with ld into a static binary

    mov     ebp, 100000000    # setup stuff outside the loop
    vzeroupper

0000000000401040 <_start.loop>:
  401040:       c4 e2 f5 b8 c3          vfmadd231pd ymm0,ymm1,ymm3
  401045:       c4 e2 f5 b8 e3          vfmadd231pd ymm4,ymm1,ymm3
  40104a:       ff cd                   dec    ebp
  40104c:       75 f2                   jne    401040 <_start.loop>


$ taskset -c 3 perf stat -etask-clock,context-switches,cpu-migrations,page-faults,cycles,branches,instructions,uops_issued.any,uops_executed.thread,fp_arith_inst_retired.256b_packed_double -r4 ./"$t"


 Performance counter stats for './testloop-cvtss2sd' (4 runs):

            102.67 msec task-clock                #    0.999 CPUs utilized            ( +-  0.00% )
                 2      context-switches          #   24.510 M/sec                    ( +- 20.00% )
                 0      cpu-migrations            #    0.000 K/sec                  
                 2      page-faults               #   22.059 M/sec                    ( +- 11.11% )
       400,388,898      cycles                    # 3925381.355 GHz                   ( +-  0.00% )
       100,050,708      branches                  # 980889291.667 M/sec               ( +-  0.00% )
       400,256,258      instructions              #    1.00  insn per cycle           ( +-  0.00% )
       300,377,737      uops_issued.any           # 2944879772.059 M/sec              ( +-  0.00% )
       300,389,230      uops_executed.thread      # 2944992450.980 M/sec              ( +-  0.00% )
       400,000,000      fp_arith_inst_retired.256b_packed_double # 3921568627.451 M/sec            

         0.1028042 +- 0.0000170 seconds time elapsed  ( +-  0.02% )

对于200M FMA指令/100M循环迭代,fp_arith_inst_retired.256b_packed_double的计数为400M.

400M counts of fp_arith_inst_retired.256b_packed_double for 200M FMA instructions / 100M loop iterations.

(IDK用perf 4.20.g8fe28c +内核4.20.3-arch1-1-ARCH处理.它们以秒为单位计算每秒的内容,用小数点表示的单位错误.例如3925381.355 kHz是正确的,而不是GHz.不确定是否是性能或内核中的错误.

(IDK what up with perf 4.20.g8fe28c + kernel 4.20.3-arch1-1-ARCH. They calculate per-second stuff with the decimal in the wrong place for the unit. e.g. 3925381.355 kHz is correct, not GHz. Not sure if it's a bug in perf or the kernel.

在没有vzeroupper的情况下,对于FMA,我有时会看到5个周期的延迟,而不是4个周期.如果内核将寄存器保持在污染状态或其他状态,则为IDK.

Without vzeroupper, I'd sometimes see a latency of 5 cycles, not 4, for FMA. IDK if the kernel left a register in a polluted state or something.

您的ddot4在清理开始时运行_mm256_add_pd(v_dot0, v_dot1); ,由于您使用size = 4调用它,因此每个FMA都会进行一次清理.

Your ddot4 runs _mm256_add_pd(v_dot0, v_dot1); at the start of the cleanup, and since you call it with size=4, you get the cleanup once per FMA.

请注意,您的v_dot1始终为零(因为您实际上并未像您计划的那样使用2个累加器展开?)这毫无意义,但CPU并不知道.我的猜测是错误的,它不是256位的hadd,而是无用的256位垂直添加.

Note that your v_dot1 is always zero (because you didn't actually unroll with 2 accumulators like you're planning to?) So this is pointless, but the CPU doesn't know that. My guess was wrong, it's not a 256-bit hadd, it's just a useless 256-bit vertical add.

(对于更大的向量,是许多累加器对于隐藏FMA延迟非常有价值.您至少需要8个向量..请参见,了解有关使用多个累加器展开的更多信息.但是,您将需要一次清理循环,一次执行1个向量,直到最后3个元素为止.)

(For larger vectors, yes multiple accumulators are very valuable to hide FMA latency. You'll want at least 8 vectors. See Why does mulss take only 3 cycles on Haswell, different from Agner's instruction tables? for more about unrolling with multiple accumulators. But then you'll want a cleanup loop that does 1 vector at a time until you're down to the last up-to-3 elements.)

此外,我认为您最终的_mm_add_sd(u_dot0, u_tmp);实际上是一个错误:您已经添加了最后一对具有低效128位hadd的元素,因此这将最低元素加倍了.

Also, I think your final _mm_add_sd(u_dot0, u_tmp); is actually a bug: you've already added the last pair of elements with an inefficient 128-bit hadd, so this double-counts the lowest element.

请参见使用SSE/AVX获取存储在__m256d中的值的总和,以确保不会丢失.

See Get sum of values stored in __m256d with SSE/AVX for a way that doesn't suck.

还请注意,GCC使用vinsertf128将未对齐的负载分成128位半部分,因为您是使用默认的-mtune=generic(支持Sandybridge)编译的,而不是使用-march=haswell启用AVX + FMA并设置了. (或使用-march=native)

Also note that GCC is splitting your unaligned loads into 128-bit halves with vinsertf128 because you compiled with the default -mtune=generic (which favours Sandybridge) instead of using -march=haswell to enable AVX+FMA and set -mtune=haswell. (Or use -march=native)

这篇关于FMA指令显示为三个打包双操作?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-16 06:36