GCC优化：少操作怎么能慢？答案

【问题标题】：GCC optimization: how can less operations be slower?GCC优化：少操作怎么能慢？
【发布时间】：2016-05-06 07:53:03
【问题描述】：

在尝试为我的代码（使用或不使用 128 位整数）对某些选项进行基准测试时，我观察到了一种我无法理解的行为。有人能解释一下吗？

#include <stdio.h>
#include <stdint.h>
#include <time.h>

int main(int a, char** b)
{
    printf("Running tests\n");

    clock_t start = clock();
    unsigned __int128 t = 13;
    for(unsigned long i = 0; i < (1UL<<30); i++)
        t += 23442*t + 25;
    if(t == 0) printf("0\n");
    printf("u128, +25, took %fs\n", double(clock() - start)/CLOCKS_PER_SEC);

    start = clock();
    t = 13;
    for(unsigned long i = 0; i < (1UL<<30); i++)
        t += 23442*t;
    if(t == 0) printf("0\n");
    printf("u128, no+, took %fs\n", double(clock() - start)/CLOCKS_PER_SEC);

    start = clock();
    unsigned long u = 13;
    for(unsigned long i = 0; i < (1UL<<30); i++)
        u += 23442*u + 25;
    if(u == 0) printf("0\n");
    printf("u64 , +25, took %fs\n", double(clock() - start)/CLOCKS_PER_SEC);

    start = clock();
    u = 13;
    for(unsigned long i = 0; i < (1UL<<30); i++)
        u += 23442*u;
    if(u == 0) printf("0\n");
    printf("u64 , no+, took %fs\n", double(clock() - start)/CLOCKS_PER_SEC);

    return 0;
}

（注意 printf 在这里，所以 gcc 不会优化 for 循环）在我的系统上，这可靠地产生以下输出：

u128, +25, took 2.411922s
u128, no+, took 1.799805s
u64 , +25, took 1.797960s
u64 , no+, took 2.454104s

虽然 128 位整数行为是有道理的，但我看不到操作较少的 64 位循环如何执行显着 (30%) 慢。

这是一种已知的行为吗？在编写此类循环时尝试从这种优化中受益的一般规则是什么？

编辑：仅在使用 -O3 选项编译时才会观察到该行为。

gcc -lstdc++ -O3 -o a main.cpp

u128, +25, took 2.413949s
u128, no+, took 1.799469s
u64 , +25, took 1.798278s
u64 , no+, took 2.453414s

gcc -lstdc++ -O2 -o a main.cpp

u128, +25, took 2.415244s
u128, no+, took 1.800499s
u64 , +25, took 1.798699s
u64 , no+, took 1.348133s

【问题讨论】：

还提供您在编译示例时使用的编译器优化设置。
我得到的结果与@user6292850 与 GCC 5.3、默认、-O 和-O2 相似。 -O3 虽然我确实看到了奇怪的行为。
常用答案——查看生成的汇编代码并尝试理解它。
对于“no+”，clang 在我的环境中快 10-20 倍。 gcc 尝试以疯狂的方式进行 SIMD 向量化，结果更糟。
使用 MWE 编辑了原始帖子。使用 O3 而不是 O2 编译时会观察到行为。显然，出于某种原因，O3 只是减慢了 64 位无加循环。

标签： c++ gcc optimization

【解决方案1】：

循环非常紧密，以至于依赖停止、ALU 繁忙等开始发挥作用并主导时间。因此，结果不可靠，并且对实际指令执行之外的其他因素更敏感。

请注意，+25 可以与乘法并行计算。

PS。我在 4970K 上的结果：

gcc version 5.2.1 20151010
gcc -lstdc++ -O2 -o a a.cpp

u128, +25, took 1.346360s
u128, no+, took 1.022965s
u64 , +25, took 1.020189s
u64 , no+, took 0.765725s

编辑：查看-O2 和-O3 的反汇编后，主要区别在于代码生成。（以上原因仍然在不同的测试机器/环境中保持 -O2 产生略有不同的结果）

-O2：

400618:       48 69 d2 93 5b 00 00    imul   $0x5b93,%rdx,%rdx
40061f:       48 83 e8 01             sub    $0x1,%rax
400623:       75 f3                   jne    400618 <_Z4testv+0x18>

-O3：

400628:       66 0f 6f d9             movdqa %xmm1,%xmm3
40062c:       83 c0 01                add    $0x1,%eax
40062f:       66 0f 6f c1             movdqa %xmm1,%xmm0
400633:       66 0f f4 cc             pmuludq %xmm4,%xmm1
400637:       3d 00 00 00 20          cmp    $0x20000000,%eax
40063c:       66 0f f4 da             pmuludq %xmm2,%xmm3
400640:       66 0f 73 d0 20          psrlq  $0x20,%xmm0
....

O3 生成矢量化代码，而循环具有严重的依赖性，无法从矢量化中获取价值。它实际上生成了更复杂的代码，因此需要更长的时间。

【讨论】：

谢谢你的解释！我应该在发布之前尝试不同的 gcc 参数。
关于无用的矢量化，here's a bug report.

【解决方案2】：

您需要测量运行时实际发生的情况才能确定。正如Calvin 在his answer 中提到的，处理器内部发生了很多事情，这会影响循环的最终时序。

您可以使用PAPI 或Intel's brilliant tools 执行测量。英特尔的工具价格昂贵，但您可以免费试用 30 天。它们比 PAPI 更易于使用。

【讨论】：