问题是:显然，一行额外的代码使程序的速度提高了近两倍。
提出原始问题相当困难，它来自边界检查消除算法。因此，只是一些我不理解的简单测试。
显然，一行额外的代码可以使程序加速近两倍。
有以下来源:
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
long i = 0, a = 0, x = 0;
int up = 200000000;
int *values = malloc(sizeof(int)*up);
for (i = 0; i < up ; ++i)
{
values[i]=i % 2;
}
for (i = 0; i < up ; ++i)
{
x = (a & i);
#ifdef FAST
x = 0;
#endif
a += values[x];
}
printf ("a=%ld\n", a);
return 0;
}/*main*/
在此示例中，“a”的值始终为0。
x = 0;
是额外的。
但是，(看-没有任何优化!)
$ gcc -O0 -o short short.c &&时间./short
a = 0
真正的0m2.808s
用户0m2.196s
sys 0m0.596s
$ gcc -O0 -DFAST -o short short.c && time ./short
a = 0
真正的0m1.869s
用户0m1.260s
sys 0m0.608s
而且，这在许多编译器/优化选项和程序变体上都是可重现的。
而且，除了将这个愚蠢的额外0放入某些寄存器外，它们实际上产生相同的汇编代码!例如。:
gcc -S -O0 -DFAST short.c && mv short.s shortFAST.s
gcc -S -O0 short.c && mv short.s shortSLOW.s
diff shortFAST.s shortSLOW.s
55d54
而且，对某些(我能测试的)其他编译器/语言(包括Java JIT)具有相同的效果。唯一共享的是x86-64体系结构。已在Intel和AMD处理器上进行了测试...
最佳答案
简短答案:存储0消除了其中一个循环的写后读依赖性。
详细信息:
我认为这是一个有趣的问题，尽管您专注于O0优化级别，但在O3上也看到了相同的提速。但是查看O0可以更轻松地将精力集中在处理器为优化代码所做的工作上，而不是编译器上，因为正如您所指出的，生成的汇编代码仅相差1条指令。
感兴趣的循环的汇编代码如下所示
movq $0, -32(%rbp)
jmp .L4
.L5:
movq -32(%rbp), %rax
movq -24(%rbp), %rdx
andq %rdx, %rax
movq %rax, -16(%rbp)
movq $0, -16(%rbp) ;; This instruction in FAST but not SLOW
movq -16(%rbp), %rax
leaq 0(,%rax,4), %rdx
movq -8(%rbp), %rax
addq %rdx, %rax
movl (%rax), %eax
cltq
addq %rax, -24(%rbp)
addq $1, -32(%rbp)
.L4:
movl -36(%rbp), %eax
cltq
cmpq -32(%rbp), %rax
jg .L5
在系统上以
perf stat运行时，我得到以下结果:慢速代码的结果
Performance counter stats for './slow_o0':
1827.438670 task-clock # 0.999 CPUs utilized
155 context-switches # 0.085 K/sec
1 CPU-migrations # 0.001 K/sec
195,448 page-faults # 0.107 M/sec
6,675,246,466 cycles # 3.653 GHz
4,391,690,661 stalled-cycles-frontend # 65.79% frontend cycles idle
1,609,321,845 stalled-cycles-backend # 24.11% backend cycles idle
7,157,837,211 instructions # 1.07 insns per cycle
# 0.61 stalled cycles per insn
490,110,757 branches # 268.195 M/sec
178,287 branch-misses # 0.04% of all branches
1.829712061 seconds time elapsed
快速代码的结果
Performance counter stats for './fast_o0':
1109.451910 task-clock # 0.998 CPUs utilized
95 context-switches # 0.086 K/sec
1 CPU-migrations # 0.001 K/sec
195,448 page-faults # 0.176 M/sec
4,067,613,078 cycles # 3.666 GHz
1,784,131,209 stalled-cycles-frontend # 43.86% frontend cycles idle
438,447,105 stalled-cycles-backend # 10.78% backend cycles idle
7,356,892,998 instructions # 1.81 insns per cycle
# 0.24 stalled cycles per insn
489,945,197 branches # 441.610 M/sec
176,136 branch-misses # 0.04% of all branches
1.111398442 seconds time elapsed
因此，您可以看到，即使“快速”代码执行更多的指令，它的停顿也更少。当乱序的CPU(如大多数x64架构)在执行代码时，它会跟踪指令之间的依赖关系。如果操作数已准备就绪，则等待指令可以被另一条指令绕过。
在此示例中，关键点可能是此指令序列:
andq %rdx, %rax
movq %rax, -16(%rbp)
movq $0, -16(%rbp) ;; This instruction in FAST but not SLOW
movq -16(%rbp), %rax
leaq 0(,%rax,4), %rdx
movq -8(%rbp), %rax
在快速代码中，
movq -8(%rbp), %rax指令将movq $0, -16(%rbp)的结果转发给它，它将能够更快地执行。而较慢的版本将不得不等待movq %rax, -16(%rbp)，它在循环迭代之间具有更多的依赖性。请注意，在不了解特定微体系结构的情况下，这种分析可能过于简单。但是我怀疑潜在的原因是这种依赖性，执行0的存储(
movq $0, -16(%rbp)指令)使CPU在执行代码序列时能够执行更激进的推测。关于c - gcc简单算术循环性能，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/26474282/