使用 -O3 的冒泡排序比使用 GCC 的 -O2 慢

Question

我在 C 中做了一个bubble sort 实现，并在测试它的性能时注意到-O3 标志使它运行得比没有标志还要慢！同时-O2 让它运行得比预期的快很多。

没有优化：

time ./sort 30000

./sort 30000  1.82s user 0.00s system 99% cpu 1.816 total

-O2:

time ./sort 30000

./sort 30000  1.00s user 0.00s system 99% cpu 1.005 total

-O3:

time ./sort 30000

./sort 30000  2.01s user 0.00s system 99% cpu 2.007 total

代码：

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <time.h>

int n;

void bubblesort(int *buf)
{
    bool changed = true;
    for (int i = n; changed == true; i--) { /* will always move at least one element to its rightful place at the end, so can shorten the search by 1 each iteration */
        changed = false;

        for (int x = 0; x < i-1; x++) {
            if (buf[x] > buf[x+1]) {
                /* swap */
                int tmp = buf[x+1];
                buf[x+1] = buf[x];
                buf[x] = tmp;

                changed = true;
            }
        }
    }
}

int main(int argc, char *argv[])
{
    if (argc != 2) {
        fprintf(stderr, "Usage: %s <arraysize>\n", argv[0]);
        return EXIT_FAILURE;
    }

    n = atoi(argv[1]);
    if (n < 1) {
        fprintf(stderr, "Invalid array size.\n");
        return EXIT_FAILURE;
    }

    int *buf = malloc(sizeof(int) * n);

    /* init buffer with random values */
    srand(time(NULL));
    for (int i = 0; i < n; i++)
        buf[i] = rand() % n + 1;

    bubblesort(buf);

    return EXIT_SUCCESS;
}

为-O2（来自godbolt.org）生成的汇编语言：

bubblesort:
        mov     r9d, DWORD PTR n[rip]
        xor     edx, edx
        xor     r10d, r10d
.L2:
        lea     r8d, [r9-1]
        cmp     r8d, edx
        jle     .L13
.L5:
        movsx   rax, edx
        lea     rax, [rdi+rax*4]
.L4:
        mov     esi, DWORD PTR [rax]
        mov     ecx, DWORD PTR [rax+4]
        add     edx, 1
        cmp     esi, ecx
        jle     .L2
        mov     DWORD PTR [rax+4], esi
        mov     r10d, 1
        add     rax, 4
        mov     DWORD PTR [rax-4], ecx
        cmp     r8d, edx
        jg      .L4
        mov     r9d, r8d
        xor     edx, edx
        xor     r10d, r10d
        lea     r8d, [r9-1]
        cmp     r8d, edx
        jg      .L5
.L13:
        test    r10b, r10b
        jne     .L14
.L1:
        ret
.L14:
        lea     eax, [r9-2]
        cmp     r9d, 2
        jle     .L1
        mov     r9d, r8d
        xor     edx, edx
        mov     r8d, eax
        xor     r10d, r10d
        jmp     .L5

-O3 也一样：

bubblesort:
        mov     r9d, DWORD PTR n[rip]
        xor     edx, edx
        xor     r10d, r10d
.L2:
        lea     r8d, [r9-1]
        cmp     r8d, edx
        jle     .L13
.L5:
        movsx   rax, edx
        lea     rcx, [rdi+rax*4]
.L4:
        movq    xmm0, QWORD PTR [rcx]
        add     edx, 1
        pshufd  xmm2, xmm0, 0xe5
        movd    esi, xmm0
        movd    eax, xmm2
        pshufd  xmm1, xmm0, 225
        cmp     esi, eax
        jle     .L2
        movq    QWORD PTR [rcx], xmm1
        mov     r10d, 1
        add     rcx, 4
        cmp     r8d, edx
        jg      .L4
        mov     r9d, r8d
        xor     edx, edx
        xor     r10d, r10d
        lea     r8d, [r9-1]
        cmp     r8d, edx
        jg      .L5
.L13:
        test    r10b, r10b
        jne     .L14
.L1:
        ret
.L14:
        lea     eax, [r9-2]
        cmp     r9d, 2
        jle     .L1
        mov     r9d, r8d
        xor     edx, edx
        mov     r8d, eax
        xor     r10d, r10d
        jmp     .L5

似乎对我来说唯一显着的不同是明显尝试使用SIMD，这似乎应该是一个很大的改进，但我也无法判断它到底是什么尝试使用那些pshufd 指令...这只是 SIMD 的失败尝试吗？或者也许这两条额外的指令只是为了消除我的指令缓存？

计时是在 AMD Ryzen 5 3600 上完成的。

Answer 1

看起来 GCC 对store-forwarding 停顿的天真正在损害其自动矢量化策略。另请参阅 Store forwarding by example 了解有关英特尔硬件性能计数器的一些实用基准，以及 What are the costs of failed store-to-load forwarding on x86? 以及 Agner Fog's x86 optimization guides。

(gcc -O3 启用-ftree-vectorize 和-O2 未包含的一些其他选项，例如if-转换为无分支cmov，即another way -O3 can hurt，具有GCC 没有预料到的数据模式。通过相比之下，Clang 甚至在 -O2 也启用了自动矢量化，尽管它的一些优化仍然只在 -O3 上启用。）

它在整数对上执行 64 位加载（以及是否分支存储）。这意味着，如果我们交换了最后一次迭代，则此负载一半来自该存储，一半来自新内存，因此每次交换后我们都会遇到存储转发停止。但是冒泡排序通常有很长的交换链，因为元素冒泡很远，所以这真的很糟糕。

（Bubble sort is bad in general，特别是如果天真地实现而不将前一个迭代的第二个元素保留在寄存器中。分析 asm 细节以了解其糟糕的确切原因可能很有趣，因此想要尝试是公平的。）

无论如何，这显然是一种反优化，您应该使用“missed-optimization”关键字报告GCC Bugzilla。标量负载很便宜，而存储转发停顿的成本很高。 （Can modern x86 implementations store-forward from more than one prior store? 不，microarchitectures 也不能在与前一个存储部分重叠并且部分来自必须来自 L1d 缓存的数据时有效加载。 )

最好将buf[x+1] 保存在寄存器中，并在下一次迭代中将其用作buf[x]，避免存储和加载。 （就像优秀的手写 asm 冒泡排序示例一样，其中一些存在于 StackOverflow 上。）

如果不是因为商店转发摊位（AFAIK GCC 在其成本模型中不知道这一点），这种策略可能会达到收支平衡。 SSE 4.1 用于无分支 pmind / pmaxd 比较器可能很有趣，但这意味着始终存储并且 C 源代码不会这样做。

---

如果这种双宽度加载策略有任何优点，最好在 64 位机器上使用纯整数实现，例如 x86-64，您可以在低位 32 上进行操作上半部分带有垃圾（或有价值的数据）的位。例如，

## What GCC should have done,
## if it was going to use this 64-bit load strategy at all

        movsx   rax, edx           # apparently it wasn't able to optimize away your half-width signed loop counter into pointer math
        lea     rcx, [rdi+rax*4]   # Usually not worth an extra instruction just to avoid an indexed load and indexed store, but let's keep it for easy comparison.
.L4:
        mov     rax, [rcx]       # into RAX instead of XMM0
        add     edx, 1
            #  pshufd  xmm2, xmm0, 0xe5
            #  movd    esi, xmm0
            #  movd    eax, xmm2
            #  pshufd  xmm1, xmm0, 225
        mov     rsi, rax
        rol     rax, 32   # swap halves, just like the pshufd
        cmp     esi, eax  # or eax, esi?  I didn't check which is which
        jle     .L2
        movq    QWORD PTR [rcx], rax   # conditionally store the swapped qword

（或者使用-march=native 提供的BMI2，rorx rsi, rax, 32 可以在一个uop 中进行复制和交换。没有BMI2，mov 并且如果在没有mov-的CPU 上运行，则交换原始文件而不是副本可以节省延迟消除，如Ice Lake with updated microcode。）

因此，从加载到比较的总延迟只是整数加载 + 一次 ALU 操作（旋转）。比。 XMM 加载 -> movd。而且它的 ALU 微指令更少。 这没有帮助解决存储转发停滞问题，但这仍然是一个障碍。这只是相同策略的整数 SWAR 实现，替换 2x pshufd和 2x movd r32, xmm 只需 mov + rol。

实际上，这里没有理由使用 2x pshufd。即使使用 XMM 寄存器，GCC 也可以进行一次 shuffle，交换低两个元素，同时设置 store 和 movd。因此，即使使用 XMM regs，这也是次优的。但显然 GCC 的两个不同部分发出了这两个 pshufd 指令；一个甚至用十六进制打印洗牌常数，而另一个使用十进制！我假设一个交换，另一个只是试图获得vec[1]，qword 的高元素。

---

比没有标志还慢

默认为-O0，即spills all variables to memory after every C statement 的一致调试模式，所以它非常可怕，并造成很大的存储转发延迟瓶颈。 （有点像如果每个变量都是volatile。）但它成功 存储转发，而不是停顿，所以“只有”~5 个周期，但仍然比寄存器的 0 差得多。 （包括Zen 2 在内的一些现代微架构有一些special cases that are lower latency）。必须通过管道的额外存储和加载指令没有帮助。

对-O0 进行基准测试通常并不有趣。 -O1 或 -Og 应该是编译器的首选基线，以执行正常人所期望的基本优化量，没有任何花哨的东西，但也不会通过跳过寄存器分配来故意 gimp asm。

---

半相关：为 size 而不是速度优化冒泡排序可能涉及内存目标旋转（为背靠背交换创建存储转发停顿）或内存目标 @987654367 @（隐式 lock 前缀 -> 非常慢）。见this Code Golf answer。