c - 为什么我无法通过整数加法获得最佳性能？

Question

这是一个对整数 vector 求和的基本函数。当使用具有第三级优化 (-O3) 的 gcc 编译时，我可以达到 CPE 0.51，这是我们可以获得的最大值。

int sum_basic(int a[], long n)
{
    int acc = 0;
    for (long i = 0; i < n; i++) {
        acc += a[i];
    }
    return acc;
}

这是此函数的优化版本，它应用4x4 循环展开。我能得到的最好结果是 CPE 0.84。我尝试了其他类型的优化，但无法接近 CPE 0.51。使用整数乘法我可以击败 gcc，使用浮点运算我也可以达到最佳性能，而 gcc 不能。但是整数加法 gcc 打败了我。有什么问题？

int sum_optimized(int a[], long n) {
    int acc1 = 0;
    int acc2 = 0;
    int acc3 = 0;
    int acc4 = 0;

    for (long i = 0; i < n; i+=4) {
        acc1 += a[i];
        acc2 += a[i+1];
        acc3 += a[i+2];
        acc4 += a[i+3];
    }

    return acc1 + acc2 + acc3 + acc4;
}

我使用此代码来衡量 CPE:

// get CPU cycle counter
static __inline__ unsigned long long rdtsc(void)
{
    unsigned hi, lo;
    __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi));
    return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );
}

#define SIZE  10000
int a[SIZE];

int main(void)
{
    // cache warm up + initialize array
    for (long i = 0; i < SIZE; i++)
        a[i] = rand();

    long r_begin = rdtsc();
    //---------- MEASURE THIS ------------
    int res = sum_optimized(a, SIZE);
    //------------------------------------
    long r_end = rdtsc();
    long cycles = r_end - r_begin;
    double cpe = cycles / (double)SIZE;
    printf("CPE:    %.2f \n", cpe);

    return res;
}

Answer 1

TL:DR:这可能是一个已知的优化错误错误(gcc 不对带符号的整数进行关联数学优化)，再加上普通的老式编译器实际上并不是人工智能并且生成的代码很慢。

---

首先，RDTSC 测量挂钟时间，不一定是核心时钟周期。使用性能计数器测量微基准测试中的核心时钟周期，这样您就不必担心 CPU 频率缩放。 (除非您的微基准测试涉及 L2 缓存未命中，因为以纳秒为单位的相同时间是更高频率下更多的时钟周期。即高频意味着缓存未命中造成的伤害更大，并且主内存带宽以每个周期的字节数计更低。)

---

gcc 5.3(没有 -march=nehalem 或 -mtune=haswell 或任何东西)将基本版本自动矢量化为其通常选择的标量，直到对齐边界，然后是向量化的内循环:

来自Godbolt compiler explorer :

 # gcc5.3  -O3 -fverbose-asm   (-mtune=generic; only SSE2 because no -march used)

 sum_basic:
 ... scalar prologue
.L14:   ### inner loop
    add     rdx, 1    # ivtmp.39,
    paddd   xmm0, XMMWORD PTR [r9]        # vect_acc_10.34, MEM[base: _156, offset: 0B]
    add     r9, 16    # ivtmp.40,
    cmp     r8, rdx   # bnd.28, ivtmp.39
    ja      .L14        #,

  ... horizontal sum and scalar epilogue

所以，愚蠢的 gcc，保留两个独立的循环计数器，而不是仅仅检查 r9 是否到达 a+n。或者至少使用 dec rdx/jnz 循环以避免 cmp。但是不，所以循环有 4 个融合域微指令，它们都需要一个 ALU 端口。因此它可以在 Intel Core2 及更高版本上每个时钟迭代一次，但在 Haswell 及更高版本(添加了第 4 个 ALU 端口)上每个时钟只能执行一次迭代。

在 SnB 及更高版本上，具有两个 vector ALU 的展开将使小型阵列的吞吐量翻倍，因为 PADDD 具有一个周期延迟，但每个周期吞吐量有两个(或三个)，负载也是如此.在更大的阵列上，您仍然只是内存带宽的瓶颈。

---

当您手动展开 4 个累加器时，gcc 决定保留这些语义，并且只在内部循环中使用未对齐的加载。不幸的是，gcc 5.3 最终做得非常糟糕:

# gcc5.3 -O3 -fverbose-asm   (-mtune=generic, same lack of enabling SSE4/AVX/AVX2)
sum_optimized:
   zero xmm0 and some other minor setup
.L3:
    mov     rdx, rax
    add     rax, 1
    sal     rdx, 4           # what the hell gcc?  just add 16 instead of copying and shifting a separate instructions.  Even if it takes two loop counters like in the basic version.
    cmp     rcx, rax         # cmp not next to ja, can't macro-fuse.  (-mtune=haswell fixes this)
    movdqu  xmm1, XMMWORD PTR [rdi+rdx]    # separate load, not folded into paddd because it's unaligned.
    paddd   xmm0, xmm1
    ja      .L3
    ...
    A hilarious horizontal sum that uses MOVD on each element separately and sums with scalar integer ops.  (With -march=nehalem, it uses PEXTRD)

这是 Intel Nehalem 及更高版本上的 7 个融合域微指令。在 Core2 上，它是 9 uops IIRC。在 Nehalem 之前，movdqu 是多个 uops，运行速度比 movdqa 慢，即使数据在运行时对齐也是如此。

无论如何，假设 Nehalem 或更高版本，这可以每 2 个周期迭代一次，这就是瓶颈。执行每 2 个周期最多可以处理 6 个 ALU 微指令。即使指针未对齐，也不应再减慢它的速度，因为 gcc 的代码已经很慢了。

---

我的理论是，这是因为 gcc 中一个已知的未优化错误:以不同的顺序添加数字会导致溢出。多亏了 2 的补码，一切最终都会成功，但 gcc 不知道如何利用它。 C 中的有符号溢出是未定义的行为，但在 x86 上不是。

理查德·比纳 (Richard Biener) 对 my gcc bug report about gcc not doing associative-math optimizations on signed-int a+b+c+d+e+f+g+h 的回应，他说:

It's a long-standing issue that reassoc doesn't associate ! TYPE_OVERFLOW_WRAPS chains.It's a long-standing issue that reassoc doesn't associate ! TYPE_OVERFLOW_WRAPS chains. It could do that to a limited extent (only cancelling ops that don't affect overflow) or fully if it re-writes the operation to unsigned arithmetic at commit time. Some way of detecting desired vs. just canonicalization transforms is required to avoid rewriting all signed integer ops into unsigned (well, maybe it's not that bad actually, who knows).

两个版本使用的水平求和算法为这一理论提供了一些分量:sum_basic 使用正常的向下移动高半和 vector 相加。 sum_optimized 分别提取每个 vector 元素。

---

如何使这个运行得更快:

使用 -march=native 编译，尤其是当您的 CPU 支持 AVX2 时。

正如我之前提到的，多个 vector 累加器可以在 Intel SnB 系列或 AMD K10 或更高版本上为您提供两个负载和每个时钟的两个 128 或 256b vector 加法. (IIRC，AMD K8 可以每个时钟执行两次加载，但没有 128b 宽的执行单元。)

与往常一样，在什么硬件上运行微基准测试以及阵列大小很重要!