现有的答案显示了由特定编译器为特定目标使用特定选项集生成的代码，并不能完全回答这个问题——除非在特定的上下文中提出了这个问题(例如，“对于带有默认选项的x86_64，使用gcc 4.7.2哪个更快?”)。

就语言定义而言，在抽象机器中while(1)计算整数常数1,while(2)计算整数常数2;在这两种情况下，比较结果是否等于零。语言标准完全没有说明这两种构造的相对性能。

我可以想象，一个极其幼稚的编译器可能会为这两种表单生成不同的机器代码，至少在编译时没有请求优化。

另一方面，C编译器绝对必须在编译时计算一些常量表达式，当它们出现在需要常量表达式的上下文中时。例如，这个:

int n = 4;
switch (n) {
    case 2+2: break;
    case 4:   break;
}

需要诊断;延迟编译器没有将2+2的计算延迟到执行时的选项。由于编译器必须具备在编译时计算常量表达式的能力，因此即使不需要也没有充分的理由不利用这种能力。

C标准(N1570 6.8.5p4)说

一个迭代语句导致一个称为循环体的语句 重复执行，直到控制表达式比较为 0.

所以相关的常数表达式是1 == 0和2 == 0，它们的值都是int值0。(这些比较隐含在while循环的语义中;它们并不作为实际的C表达式存在。)

非常简单的编译器可能会为这两种构造生成不同的代码。例如，对于第一个，它可以生成一个无条件的无限循环(将1视为特殊情况)，对于第二个，它可以生成一个显式的运行时比较，等价于2 != 0。但我从来没有遇到过这样的C编译器，我严重怀疑这样的编译器是否存在。

大多数编译器(我倾向于说所有生产质量的编译器)都有请求额外优化的选项。在这种选择下，任何编译器都不太可能为这两种表单生成不同的代码。

如果编译器为这两种构造生成不同的代码，首先检查不同的代码序列是否具有不同的性能。如果有，请尝试使用优化选项(如果可用)再次编译。如果它们仍然不同，则向编译器供应商提交错误报告。这(不一定)是一个不符合C标准的错误，但几乎可以肯定这是一个应该纠正的问题。

底线:while(1)和while(2)几乎肯定具有相同的性能。它们具有完全相同的语义，任何编译器都没有理由不生成相同的代码。

尽管编译器为while(1)生成比while(2)更快的代码是完全合法的，但在同一个程序中，编译器为while(1)生成比另一个while(1)更快的代码也是合法的。

(你问的问题中还暗含着另一个问题:你如何应对坚持提出一个错误的技术观点的面试官?这可能是一个适合Workplace网站的好问题)。

也许面试官是故意问这个愚蠢的问题，想让你回答3点:

基本的推理。这两个循环都是无限的，很难谈论性能。 关于优化级别的知识。他想听听你的意见，如果你让编译器为你做任何优化，它会优化条件，特别是如果块不是空的。 了解微处理器架构。大多数架构都有一个特殊的CPU指令用于与0进行比较(但不一定更快)。

你的解释很正确。这似乎是一个在技术知识之外考验你自信的问题。

顺便说一下，如果你回答了

这两段代码同样快，因为它们都需要无限长的时间来完成

面试官会说

但是虽然(1)每秒可以做更多的迭代;你能解释一下原因吗?(这是无稽之谈;再次考验你的信心)

所以，通过像你那样回答，你节省了一些时间，否则你会浪费在讨论这个糟糕的问题上。

---

下面是编译器在我的系统(MS Visual Studio 2012)上生成的示例代码，优化关闭:

yyy:
    xor eax, eax
    cmp eax, 1     (or 2, depending on your code)
    je xxx
    jmp yyy
xxx:
    ...

打开优化后:

xxx:
    jmp xxx

因此生成的代码是完全相同的，至少在优化编译器中是如此。

对这个问题最有可能的解释是，面试官认为处理器会逐一检查数字的每一位，直到它达到一个非零值:

1 = 00000001
2 = 00000010

如果“is 0 ?”算法从数字的右侧开始，并且必须检查每一位直到它达到非零位，那么while(1){}循环每次迭代必须检查的比特数是while(2){}循环的两倍。

这需要一个关于计算机如何工作的非常错误的思维模型，但它确实有自己的内部逻辑。一种检查方法是询问while(-1){}或while(3){}是否同样快，或者while(32){}是否更慢。

看到这么多人深入研究这个问题，正好说明了为什么这可以很好地作为一个测试，看看您想要多快地进行微优化。

我的答案是;这并不重要，我更关注我们正在解决的业务问题。毕竟，这就是我的工作。

此外，我会选择while(1){}，因为它更常见，其他队友不需要花时间去弄清楚为什么有人会选择比1更高的数字。

现在去写一些代码。: -)

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

使用gcc，我编译了以下两个程序，以不同的优化级别进行汇编:

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

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

即使没有优化(-O0)，两个程序生成的程序集也是相同的。因此，两个循环之间没有速度差异。

作为参考，下面是生成的程序集(使用gcc main.c -S -masm=intel并带有优化标志):

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

我不太懂汇编，但这显然是一个无条件循环。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()) {}

At -O0, these two examples actually call x and perform a comparison for each iteration.

First example (returning 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"

Second example (returning sqrt(7)):

.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"

However, at -O1 and above, they both produce the same assembly as the previous examples (an unconditional jmp back to the preceding label).

TL;DR

Under GCC, the different loops are compiled to identical assembly. The compiler evaluates the constant values and doesn't bother performing any actual comparison.

The moral of the story is:

• There exists a layer of translation between C source code and CPU instructions, and this layer has important implications for performance.
• Therefore, performance cannot be evaluated by only looking at source code.
• The compiler should be smart enough to optimize such trivial cases. Programmers should not waste their time thinking about them in the vast majority of cases.