空循环比 C 中的非空循环慢

Question

当我想知道一行 C 代码执行了多长时间时，我注意到了这个奇怪的事情：

int main (char argc, char * argv[]) {
    time_t begin, end;
    uint64_t i;
    double total_time, free_time;
    int A = 1;
    int B = 1;

    begin = clock();
    for (i = 0; i<(1<<31)-1; i++);
    end = clock();
    free_time = (double)(end-begin)/CLOCKS_PER_SEC;
    printf("%f\n", free_time);

    begin = clock();
    for (i = 0; i<(1<<31)-1; i++) {
        A += B%2;
    }
    end = clock();
    free_time = (double)(end-begin)/CLOCKS_PER_SEC;
    printf("%f\n", free_time);

    return(0);
}

执行时显示：

5.873425
4.826874

为什么空循环比第二个有指令的循环使用更多时间？当然，我尝试了很多变体，但每次，一个空循环都比一个包含一条指令的循环花费更多时间。

请注意，我已尝试交换循环顺序并添加一些预热代码，但它根本没有改变我的问题。

我将代码块用作带有 GNU gcc 编译器、linux ubuntu 14.04 的 IDE，并且有一个 2.3GHz 的四核英特尔 i5（我尝试在单核上运行该程序，这不会改变结果）。

Answer 1

假设您的代码使用 32 位整数 int 类型（您的系统可能会这样做），则无法从您的代码中确定任何内容。相反，它表现出未定义的行为。

foo.c:5:5: error: first parameter of 'main' (argument count) must be of type 'int'
int main (char argc, char * argv[]) {
    ^
foo.c:13:26: warning: overflow in expression; result is 2147483647 with type 'int' [-Winteger-overflow]
    for (i = 0; i<(1<<31)-1; i++);
                         ^
foo.c:19:26: warning: overflow in expression; result is 2147483647 with type 'int' [-Winteger-overflow]
    for (i = 0; i<(1<<31)-1; i++) {
                         ^

让我们尝试解决这个问题：

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

int main (int argc, char * argv[]) {
    time_t begin, end;
    uint64_t i;
    double total_time, free_time;
    int A = 1;
    int B = 1;

    begin = clock();
    for (i = 0; i<INT_MAX; i++);
    end = clock();
    free_time = (double)(end-begin)/CLOCKS_PER_SEC;
    printf("%f\n", free_time);

    begin = clock();
    for (i = 0; i<INT_MAX; i++) {
        A += B%2;
    }
    end = clock();
    free_time = (double)(end-begin)/CLOCKS_PER_SEC;
    printf("%f\n", free_time);

    return(0);
}

现在，让我们看看这段代码的汇编输出。就个人而言，我发现 LLVM 的内部程序集非常易读，所以我将展示这一点。我将通过运行来生成它：

clang -O3 foo.c -S -emit-llvm -std=gnu99

这是输出的相关部分（主要功能）：

define i32 @main(i32 %argc, i8** nocapture readnone %argv) #0 {
  %1 = tail call i64 @"\01_clock"() #3
  %2 = tail call i64 @"\01_clock"() #3
  %3 = sub nsw i64 %2, %1
  %4 = sitofp i64 %3 to double
  %5 = fdiv double %4, 1.000000e+06
  %6 = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), double %5) #3
  %7 = tail call i64 @"\01_clock"() #3
  %8 = tail call i64 @"\01_clock"() #3
  %9 = sub nsw i64 %8, %7
  %10 = sitofp i64 %9 to double
  %11 = fdiv double %10, 1.000000e+06
  %12 = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), double %11) #3
  ret i32 0
}

请注意，对于任何一种情况，在对clock() 的调用之间没有没有操作。所以它们都被编译成完全相同的东西。

Answer 2

事实上，现代处理器很复杂。执行的所有指令将以复杂而有趣的方式相互交互。感谢"that other guy" for posting the code.

OP 和“那个家伙”显然都发现短循环需要 11 个周期，而长循环需要 9 个周期。对于长循环，即使有很多操作，9 个循环也足够了。对于短循环，一定会因为它太短而导致一些停顿，并且只需添加一个nop 就可以使循环足够长以避免停顿。

如果我们查看代码会发生一件事：

0x00000000004005af <+50>:    addq   $0x1,-0x20(%rbp)
0x00000000004005b4 <+55>:    cmpq   $0x7fffffff,-0x20(%rbp)
0x00000000004005bc <+63>:    jb     0x4005af <main+50>

我们读取 i 并将其写回 (addq)。我们立即再次阅读并比较它（cmpq）。然后我们循环。但是循环使用分支预测。所以在执行addq 时，处理器并不确定是否允许写入i（因为分支预测可能是错误的）。

然后我们比较i。处理器会尽量避免从内存中读取i，因为读取它需要很长时间。相反，一些硬件会记住我们只是通过添加到i 来写入它，而不是读取i，cmpq 指令从存储指令中获取数据。不幸的是，我们目前不确定写到i 是否真的发生了！所以这可能会在这里引入一个摊位。

这里的问题是条件跳转，导致条件存储的addq，以及不确定从哪里获取数据的cmpq，都非常接近。它们异常靠近。可能是它们靠得太近了，处理器此时无法确定是从存储指令中获取i 还是从内存中读取它。并从内存中读取它，这比较慢，因为它必须等待存储完成。并且只添加一个nop 可以为处理器提供足够的时间。

通常你认为有内存，有缓存。在现代英特尔处理器上，读取内存可以从（最慢到最快）读取：

1. 内存 (RAM)
2. L3 缓存（可选）
3. 二级缓存
4. 一级缓存
5. 尚未写入 L1 高速缓存的先前存储指令。

那么处理器在短而慢的循环内部做了什么：

1. 从一级缓存中读取i
2. 给i加1
3. 将i 写入一级缓存
4. 等到i 被写入一级缓存
5. 从一级缓存中读取i
6. 比较 i 与 INT_MAX
7. 如果小于，则分支到 (1)。

在长、快、处理器的循环中：

1. 很多东西
2. 从一级缓存中读取i
3. 将 1 加到 i
4. 执行“存储”指令，将i 写入一级缓存
5. 直接从“存储”指令中读取i，无需触及一级缓存
6. 比较 i 和 INT_MAX
7. 如果小于，则分支到 (1)。

Answer 3

此答案假定您已经了解并解决了关于 sharth 在his answer 中所做的未定义行为的要点。他还指出了编译器可能在您的代码上使用的技巧。您应该采取措施确保编译器不会将整个循环识别为无用。例如，将迭代器声明更改为volatile uint64_t i; 将阻止删除循环，volatile int A; 将确保第二个循环实际上比第一个循环做更多的工作。但即使你做了所有这些，你仍然可能会发现：

程序中后期的代码可能比早期的代码执行得更快。

clock() 库函数可能在读取计时器后和返回之前导致 icache 未命中。这将导致在第一个测量间隔中出现一些额外的时间。 （对于以后的调用，代码已经在缓存中）。然而这种影响会很小，对于clock() 来说肯定太小了，即使它是一直到磁盘的页面错误。随机上下文切换可以添加到任一时间间隔。

更重要的是，您有一个 i5 CPU，它具有动态时钟。当您的程序开始执行时，时钟频率很可能很低，因为 CPU 一直处于空闲状态。仅仅运行程序就可以使 CPU 不再空闲，因此在短暂的延迟后时钟速度会增加。空闲和 TurboBoosted CPU 时钟频率之间的比率可能很大。 （在我的超极本的 Haswell i5-4200U 上，前一个乘数是 8，后一个是 26，这使得启动代码的运行速度低于后来代码的 30%！用于实现延迟的“校准”循环在现代计算机上是一个糟糕的主意！ )

包括预热阶段（重复运行基准测试，并丢弃第一个结果）以获得更精确的计时不仅适用于具有 JIT 编译器的托管框架！

Answer 4

我可以在没有优化的情况下使用 GCC 4.8.2-19ubuntu1 重现这个：

$ ./a.out 
4.780179
3.762356

这是空循环：

0x00000000004005af <+50>:    addq   $0x1,-0x20(%rbp)
0x00000000004005b4 <+55>:    cmpq   $0x7fffffff,-0x20(%rbp)
0x00000000004005bc <+63>:    jb     0x4005af <main+50>

这是非空的：

0x000000000040061a <+157>:   mov    -0x24(%rbp),%eax
0x000000000040061d <+160>:   cltd   
0x000000000040061e <+161>:   shr    $0x1f,%edx
0x0000000000400621 <+164>:   add    %edx,%eax
0x0000000000400623 <+166>:   and    $0x1,%eax
0x0000000000400626 <+169>:   sub    %edx,%eax
0x0000000000400628 <+171>:   add    %eax,-0x28(%rbp)
0x000000000040062b <+174>:   addq   $0x1,-0x20(%rbp)
0x0000000000400630 <+179>:   cmpq   $0x7fffffff,-0x20(%rbp)
0x0000000000400638 <+187>:   jb     0x40061a <main+157>

让我们在空循环中插入一个nop：

0x00000000004005af <+50>:    nop
0x00000000004005b0 <+51>:    addq   $0x1,-0x20(%rbp)
0x00000000004005b5 <+56>:    cmpq   $0x7fffffff,-0x20(%rbp)
0x00000000004005bd <+64>:    jb     0x4005af <main+50>

它们现在跑得同样快：

$ ./a.out 
3.846031
3.705035

我想这表明了对齐的重要性，但恐怕我不能具体说明如何：|