哪一个更快：while(1)还是while(2)？

Question

这是一位高级经理问的面试问题。

哪个更快？

while(1) {
    // Some code
}

while(2) {
    //Some code
}

我说过，这两者具有相同的执行速度，因为while内部的表达式最终应计算为true或false。在这种情况下，两者的计算结果都为true，while条件中没有额外的条件指令。因此，两者的执行速度相同，我更喜欢while（1）。

但面试官自信地说：“检查一下你的基础，while(1)比while(2)要快。”（他不是在考验我的信心）

这是真的吗？

Answer 1

两个循环都是无限的，但是我们可以看到哪个循环每次迭代需要更多的指令/资源。

使用gcc，我编译了以下两个程序，以便在不同的优化级别上进行组装：

int main(void) {
    while(1) {}
    return 0;
}

int main(void) {
    while(2) {}
    return 0;
}

即使没有优化(-o0)，生成的程序集对于两个程序都是相同的。因此，两个环路之间没有速度差异。

使用-o0:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    push    rbp
    .seh_pushreg    rbp
    mov rbp, rsp
    .seh_setframe   rbp, 0
    sub rsp, 32
    .seh_stackalloc 32
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

使用-o1:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

使用-O2和-O3（相同输出）：

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .section    .text.startup,"x"
    .p2align 4,,15
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

 .L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

.L2:
    jmp .L2

我不能很好地读取assembly，但这显然是一个无条件循环。jmp指令无条件地将程序重置回.l2标签，甚至不需要将值与true进行比较，并且当然会立即再次这样做，直到程序以某种方式结束。这直接对应于C/C++代码：

L2:
    goto L2;

编辑：

非常有趣的是，即使没有优化，以下循环都在汇编中生成了完全相同的输出（无条件jmp)：

while(42) {}

while(1==1) {}

while(2==2) {}

while(4<7) {}

while(3==3 && 4==4) {}

while(8-9 < 0) {}

while(4.3 * 3e4 >= 2 << 6) {}

while(-0.1 + 02) {}

#include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

用户定义函数会让事情变得更有趣：

int x(void) {
    return 1;
}

while(x()) {}

#include<math.h>

double x(void) {
    return sqrt(7);
}

while(x()) {}

在-o0处，这两个示例实际上调用x并为每个迭代执行一个比较。

第一个示例（返回1）：

.L4:
    call    x
    testl   %eax, %eax
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

.L4:
    call    x
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jp  .L4
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

在GCC下，不同的循环被编译成相同的程序集。编译器计算常量值，而不需要执行任何实际比较。

这个故事的寓意是：

• 在C++源代码和CPU指令之间存在一个转换层，这一层对性能有重要影响。
• 因此，不能仅通过查看源代码来评估性能。
• 编译器应该足够聪明来优化这种琐碎的情况。程序员在绝大多数情况下都不应该把时间浪费在考虑这些问题上。