意外的运行时差

时间:2013-08-21 21:44:04

标签: c

考虑给定的两种情况,

在下面的这种情况下,我只是运行两个嵌套循环,这两个循环都是从0初始化并运行到100000

int k = 100000;
for(i=0;i<k;i++)
    for(j=0;j<k;j++){
    // Do nothing
 }
我系统上的

time = 22.6 seconds

我再次做同样的事情,只是在里面增加一个变量c

int k = 100000, cnt=0;
for(i=0;i<k;i++)
    for(j=0;j<k;j++){
    cnt++;
 }
我系统上的

time = 19.6 seconds

怎么来的???为什么时间在case2 < case1 ??

4 个答案:

答案 0 :(得分:5)

我刚刚复制了结果,并问自己与OP相同的问题。

这是代码:

>>>> test1.c
int
main ()
{
  long long int i;
  long long int j;
  long long int k = 100000;
  for(i=0;i<k;i++)
    for(j=0;j<k;j++)
      {
        // Do nothing
      }

  return 0;
}

>>>> test2.c
int
main ()
{
  long long int i;
  long long int j;
  long long int c = 0;

  long long int k = 100000;
  for(i=0;i<k;i++)
    for(j=0;j<k;j++)
      {
        c++;
      }

  return 0;
}

使用gcc -o testx testx.c -g在amd64 gentoo linux机器上编译。 运行时,我会得到以下时间:

  test1: 0m32.000s
  test2: 0m28.307s

我已经多次测试了这一点,并且推算量非常小。

要了解这里发生的事情,我们必须查看反汇编。

>>>> test1
Dump of assembler code for function main:
   0x00000000004004fc <+0>:     push   %rbp
   0x00000000004004fd <+1>:     mov    %rsp,%rbp
   0x0000000000400500 <+4>:     movq   $0x186a0,-0x18(%rbp)
   0x0000000000400508 <+12>:    movq   $0x0,-0x8(%rbp)
   0x0000000000400510 <+20>:    jmp    0x400530 <main+52>
   0x0000000000400512 <+22>:    movq   $0x0,-0x10(%rbp)
   0x000000000040051a <+30>:    jmp    0x400521 <main+37>
   0x000000000040051c <+32>:    addq   $0x1,-0x10(%rbp)
   0x0000000000400521 <+37>:    mov    -0x10(%rbp),%rax
   0x0000000000400525 <+41>:    cmp    -0x18(%rbp),%rax
   0x0000000000400529 <+45>:    jl     0x40051c <main+32>
   0x000000000040052b <+47>:    addq   $0x1,-0x8(%rbp)
   0x0000000000400530 <+52>:    mov    -0x8(%rbp),%rax
   0x0000000000400534 <+56>:    cmp    -0x18(%rbp),%rax
   0x0000000000400538 <+60>:    jl     0x400512 <main+22>
   0x000000000040053a <+62>:    mov    $0x0,%eax
   0x000000000040053f <+67>:    pop    %rbp
   0x0000000000400540 <+68>:    retq   
End of assembler dump.

>>>> test2:
Dump of assembler code for function main:
   0x00000000004004fc <+0>:     push   %rbp
   0x00000000004004fd <+1>:     ov    %rsp,%rbp
   0x0000000000400500 <+4>:     movq   $0x0,-0x18(%rbp)
   0x0000000000400508 <+12>:    movq   $0x186a0,-0x20(%rbp)
   0x0000000000400510 <+20>:    movq   $0x0,-0x8(%rbp)
   0x0000000000400518 <+28>:    jmp    0x40053d <main+65>
   0x000000000040051a <+30>:    movq   $0x0,-0x10(%rbp)
   0x0000000000400522 <+38>:    jmp    0x40052e <main+50>
   0x0000000000400524 <+40>:    addq   $0x1,-0x18(%rbp)
   0x0000000000400529 <+45>:    addq   $0x1,-0x10(%rbp)
   0x000000000040052e <+50>:    mov    -0x10(%rbp),%rax
   0x0000000000400532 <+54>:    cmp    -0x20(%rbp),%rax
   0x0000000000400536 <+58>:    jl     0x400524 <main+40>
   0x0000000000400538 <+60>:    addq   $0x1,-0x8(%rbp)
   0x000000000040053d <+65>:    mov    -0x8(%rbp),%rax
   0x0000000000400541 <+69>:    cmp    -0x20(%rbp),%rax
   0x0000000000400545 <+73>:    jl     0x40051a <main+30>
   0x0000000000400547 <+75>:    mov    $0x0,%eax
   0x000000000040054c <+80>:    pop    %rbp
   0x000000000040054d <+81>:    retq   
End of assembler dump.

正如预期的那样,看起来非常相似。

我已经在下面的注释版本的test2中突出显示了代码的功能。装配线的缩进表示它们所处的循环级别或它们实现的循环级别。

>>>> test2:
Dump of assembler code for function main:
   // setup the stackframe
   0x00000000004004fc <+0>:     push   %rbp
   0x00000000004004fd <+1>:     ov    %rsp,%rbp
   // initialize variable c
   0x0000000000400500 <+4>:     movq   $0x0,-0x18(%rbp)
   // initialize variable k
   0x0000000000400508 <+12>:    movq   $0x186a0,-0x20(%rbp)
     // initialize variable i
     0x0000000000400510 <+20>:  movq   $0x0,-0x8(%rbp)
     // enter the outer loop
     0x0000000000400518 <+28>:  jmp    0x40053d <main+65>
       // initialize variable j
       0x000000000040051a <+30>:    movq   $0x0,-0x10(%rbp)
       // enter the inner loop
       0x0000000000400522 <+38>:    jmp    0x40052e <main+50>
         // increment variable c
         0x0000000000400524 <+40>:  addq   $0x1,-0x18(%rbp)
       // increment variable j
       0x0000000000400529 <+45>:    addq   $0x1,-0x10(%rbp)
       // check if the inner loop condition still holds
       0x000000000040052e <+50>:    mov    -0x10(%rbp),%rax
       0x0000000000400532 <+54>:    cmp    -0x20(%rbp),%rax
       // jump to the start of the inner loop, if true, else continue
       0x0000000000400536 <+58>:    jl     0x400524 <main+40>
     // increment variable i
     0x0000000000400538 <+60>:  addq   $0x1,-0x8(%rbp)
     // check if the outer loop condition still holds
     0x000000000040053d <+65>:  mov    -0x8(%rbp),%rax
     0x0000000000400541 <+69>:  cmp    -0x20(%rbp),%rax
     // jump to the start of the outer loop, if true, else continue
     0x0000000000400545 <+73>:  jl     0x40051a <main+30>
   // tear down and return to main
   0x0000000000400547 <+75>:    mov    $0x0,%eax
   0x000000000040054c <+80>:    pop    %rbp
   0x000000000040054d <+81>:    retq   
End of assembler dump.

正如您所看到的,代码结构与实际的C代码非常相似,而test1和test2的程序集之间的差异非常小。

test2执行速度稍快的原因可能深深地隐藏在硬件规范中。我认为现代处理器可能有优化指令缓存和流水线操作的简单循环,因为这些在程序中很常见,并且优化不适用于空循环,因为它们(1)在实际程序中非常罕见(2)运行时优化对于空循环实际上并不重要,因为它们通常用于(忙)等待。

无论出于什么原因,它可能具有学术意义,对真实软件的影响可能不存在:)

我刚刚发现英特尔发布的这份文件,如果您对细节感兴趣,应该是一本有趣的读物http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&ved=0CFgQFjAD&url=http%3A%2F%2Fwww.agner.org%2Foptimize%2Fmicroarchitecture.pdf&ei=8-sVUtWyM8nPtAb4ooCQBQ&usg=AFQjCNGRPm4A8ixWqSSGOOtNPCxp1YRfQg&sig2=Qe6Nxmz4Lee5Oo8UOGwTJw&bvm=bv.51156542,d.Yms

答案 1 :(得分:3)

当CPU设计人员最近考虑性能时,他们会尝试很好地了解他们的处理器将运行的代码,然后他们设计他们的芯片以便在该工作负载上尽可能快地运行。在他们进入的联赛中,这意味着进行权衡。因此,更常见的代码运行得更快,并且可以提高整体性能。

答案 2 :(得分:0)

如果像@JesseJ上面评论的那样,重复试验会产生相同的结果,那么编译器对代码的优化程度可能会有所不同。如果您在优化关闭的情况下进行编译,则可能会得到预期的结果(case2 > case1)。启动优化器后,所有投注均已关闭。

答案 3 :(得分:0)

可能是因为您的编译器进行了优化。

现代编译器非常擅长优化循环。

实际上我很惊讶第一个案例花了这么长时间,大多数编译器优化器会看到你的循环没有做任何事情直接影响i=j=k^2而没有把它编译成一个充满跳跃的空循环的负担(汇编程序中的JNZ) )指令,第二种情况可能只会影响cnt=10e8(可能溢出),因为编译器足够聪明,知道这将是循环的最终结果,并且循环不会执行任何其他操作不会触发任何其他副作用,因此可以跳过。

尝试使用-O0再次运行测试以关闭编译器优化。 实际上你没有提到你用来执行测试的编译器和编译器选项,所以到目前为止任何结论都没用。