而（1）for（;;）是否存在速度差异？

长版...

一位同事在看到我while (1)在for (;;)更快的Perl脚本中使用后断言。我认为他们应该是一样的，希望解释器可以优化任何差异。我设置了一个脚本，该脚本将为循环迭代和相同数量的while循环运行1,000,000,000，并记录它们之间的时间。我发现没有明显的区别。我的同事说，一位教授告诉他while (1)正在进行比较1 == 1，for (;;)而没有进行比较。我们使用C ++的迭代次数进行了100倍的重复相同的测试，并且差异可以忽略不计。但是，这是一个图形示例，说明了与脚本语言相比，编译后的代码可以提高多少速度。

精简版...

如果您需要无限循环来突破，有什么理由while (1)比a for (;;)优先？

注意：如果问题尚不清楚。这纯粹是几个朋友之间有趣的学术讨论。我知道这不是所有程序员都应该苦恼的超级重要概念。感谢您提供的所有出色答案，我（而且我敢肯定其他人）已经从这次讨论中学到了一些东西。

更新：上述同事在下面进行了回应。

以防万一它被埋在这里。

它来自AMD组装程序员。他说C程序员（人）没有意识到他们的代码效率低下。他今天说，但是，gcc编译器非常好，使像他这样的人破产了。他举例称，并告诉我关于while 1VS for(;;)。我现在已经习惯使用它了，但是由于它们已经过优化，因此gcc尤其是解释器这两天都将执行相同的操作（处理器跳转）。

在perl中，它们产生相同的操作码：

$ perl -MO=Concise -e 'for(;;) { print "foo\n" }'
a  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 2 -e:1) v ->3
9     <2> leaveloop vK/2 ->a
3        <{> enterloop(next->8 last->9 redo->4) v ->4
-        <@> lineseq vK ->9
4           <;> nextstate(main 1 -e:1) v ->5
7           <@> print vK ->8
5              <0> pushmark s ->6
6              <$> const[PV "foo\n"] s ->7
8           <0> unstack v ->4
-e syntax OK

$ perl -MO=Concise -e 'while(1) { print "foo\n" }'
a  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 2 -e:1) v ->3
9     <2> leaveloop vK/2 ->a
3        <{> enterloop(next->8 last->9 redo->4) v ->4
-        <@> lineseq vK ->9
4           <;> nextstate(main 1 -e:1) v ->5
7           <@> print vK ->8
5              <0> pushmark s ->6
6              <$> const[PV "foo\n"] s ->7
8           <0> unstack v ->4
-e syntax OK

同样在GCC中：

#include <stdio.h>

void t_while() {
    while(1)
        printf("foo\n");
}

void t_for() {
    for(;;)
        printf("foo\n");
}

    .file   "test.c"
    .section    .rodata
.LC0:
    .string "foo"
    .text
.globl t_while
    .type   t_while, @function
t_while:
.LFB2:
    pushq   %rbp
.LCFI0:
    movq    %rsp, %rbp
.LCFI1:
.L2:
    movl    $.LC0, %edi
    call    puts
    jmp .L2
.LFE2:
    .size   t_while, .-t_while
.globl t_for
    .type   t_for, @function
t_for:
.LFB3:
    pushq   %rbp
.LCFI2:
    movq    %rsp, %rbp
.LCFI3:
.L5:
    movl    $.LC0, %edi
    call    puts
    jmp .L5
.LFE3:
    .size   t_for, .-t_for
    .section    .eh_frame,"a",@progbits
.Lframe1:
    .long   .LECIE1-.LSCIE1
.LSCIE1:
    .long   0x0
    .byte   0x1
    .string "zR"
    .uleb128 0x1
    .sleb128 -8
    .byte   0x10
    .uleb128 0x1
    .byte   0x3
    .byte   0xc
    .uleb128 0x7
    .uleb128 0x8
    .byte   0x90
    .uleb128 0x1
    .align 8
.LECIE1:
.LSFDE1:
    .long   .LEFDE1-.LASFDE1
.LASFDE1:
    .long   .LASFDE1-.Lframe1
    .long   .LFB2
    .long   .LFE2-.LFB2
    .uleb128 0x0
    .byte   0x4
    .long   .LCFI0-.LFB2
    .byte   0xe
    .uleb128 0x10
    .byte   0x86
    .uleb128 0x2
    .byte   0x4
    .long   .LCFI1-.LCFI0
    .byte   0xd
    .uleb128 0x6
    .align 8
.LEFDE1:
.LSFDE3:
    .long   .LEFDE3-.LASFDE3
.LASFDE3:
    .long   .LASFDE3-.Lframe1
    .long   .LFB3
    .long   .LFE3-.LFB3
    .uleb128 0x0
    .byte   0x4
    .long   .LCFI2-.LFB3
    .byte   0xe
    .uleb128 0x10
    .byte   0x86
    .uleb128 0x2
    .byte   0x4
    .long   .LCFI3-.LCFI2
    .byte   0xd
    .uleb128 0x6
    .align 8
.LEFDE3:
    .ident  "GCC: (Ubuntu 4.3.3-5ubuntu4) 4.3.3"
    .section    .note.GNU-stack,"",@progbits

所以我想答案是，它们在许多编译器中都是相同的。当然，对于其他一些编译器来说，不一定是这种情况，但是循环内的代码可能比循环本身要贵数千倍，那么谁在乎呢？

使用GCC，它们似乎都可以编译为相同的汇编语言：

L2:
        jmp     L2

没有太多理由比另一个更喜欢一个。我确实认为这while(1)尤其while(true)是比更具可读性for(;;)，但这只是我的偏爱。

根据标准没有差异。6.5.3 / 1具有：

for语句

for ( for-init-statement ; conditionopt ; expressionopt ) statement

相当于

{
  for-init-statement
  while ( condition ) {
    statement
    expression ;
  }
}

而6.5.3 / 2具有：

条件和表达式中的一个或两个都可以省略。缺少条件会使隐式while子句等效于while（true）。

因此，根据C ++标准，代码如下：

for (;;);

与以下内容完全相同：

{
  while (true) {
    ;
    ;
  }
}

用于发出警告的Visual C ++编译器

while (1) 

（常量表达式），但不适用于

for (;;)

for (;;)由于这个原因，我继续了首选的做法，但是我不知道这些天编译器是否仍然这样做。

for(;;) 如果您想朝那个方向去优化，则少键入一个字符。

使用这种旧编译器的Turbo C可以for(;;)加快代码的编写while(1)。

如今，gcc，Visual C（我认为几乎所有的）编译器都能很好地进行优化，并且很少使用4.7 MHz的CPU。

在那些日子里，a的for( i=10; i; i-- )速度快于for( i=1; i <=10; i++ )，因为compare i为0，因此导致CPU零标志条件跳转。并且使用最后的递减操作对零标记进行了修改( i-- )，不需要额外的cmp操作。

    call    __printf_chk
    decl    %ebx          %ebx=iterator i 
    jnz     .L2
    movl    -4(%ebp), %ebx
    leave

并for(i=1; i<=10; i++)带有额外的cmpl：

    call    __printf_chk
    incl    %ebx
    cmpl    $11, %ebx
    jne     .L2
    movl    -4(%ebp), %ebx
    leave

对于所有争论的人，您不应该使用indefinte while循环，并建议一些愚蠢的东西，例如使用open goto的东西（严重的是，ouch）

while (1) {
     last if( condition1 );
     code();
     more_code(); 
     last if( condition2 ); 
     even_more_code(); 
}

真的无法通过其他任何方式有效地表示出来。并非没有创建出口变量并进行魔术操作以使其保持同步。

如果您更喜欢goto-esque语法，请使用一些合理的方法来限制范围。

flow: { 

   if ( condition ){ 
      redo flow;
   }
   if ( othercondition ){ 
       redo flow;
   }
   if ( earlyexit ){ 
       last flow;
   }
   something(); # doesn't execute when earlyexit is true 
}

最终速度不是那么重要

担心速度明智的不同循环结构的有效程度是浪费大量时间。过早的优化。我想不出任何情况，在选择循环构造时，分析代码会发现瓶颈。

一般其如何循环和什么样的循环。

您应该“优化”可读性和简洁性，并写出最能说明问题的信息给找到您的代码的下一个可怜的傻瓜。

如果您使用有人提到的“ goto LABEL”技巧，并且我必须使用您的代码，请准备睁开一只眼睛睡觉，尤其是如果您不止一次这样做，因为这种东西会产生 令人讨厌的意大利面条式代码。

仅仅因为您可以创建意大利面条代码并不意味着您应该

源自Stroustrup，TC ++ PL（第3版），第6.1.1节：

好奇符号for (;;)是指定无限循环的标准方法。您可以说“永远”。[...] while (true)是一种替代方法。

我更喜欢for (;;)。

如果编译器不做任何优化，for(;;)总是会比while(true)。这是因为while语句每次都会评估条件，而for语句是无条件跳转。但是，如果编译器优化了控制流程，则可能会生成一些操作码。您可以非常轻松地阅读反汇编代码。

PS，您可以编写一个无限循环，如下所示：

#define EVER ;;
  //...
  for (EVER) {
    //...
  }

我听说过一次

它来自AMD组装程序员。他说，C程序员（人们）没有意识到他们的代码效率低下。他今天说，但是，gcc编译器非常好，使像他这样的人破产了。他举例称，并告诉我关于while 1VS for(;;)。我现在已经习惯了使用它，但是由于它们已经过优化，因此gcc尤其是解释器这两天都将执行相同的操作（处理器跳转）。

在优化的编译语言版本中，两者之间应该没有明显的区别。两者都不应最终在运行时执行任何比较，它们只会执行循环代码，直到您手动退出循环（例如使用break）。

令我感到惊讶的是，没有人能for (;;)对while (1)Perl 进行适当的测试！

因为perl是解释语言，所以运行perl脚本的时间不仅包括执行阶段（在这种情况下是相同的），还包括执行之前的解释阶段。进行速度比较时，必须考虑这两个阶段。

幸运的是，perl有一个方便的Benchmark模块，我们可以使用它来实现一个基准，例如：

#!/usr/bin/perl -w

use Benchmark qw( cmpthese );

sub t_for   { eval 'die; for (;;) { }'; }
sub t_for2  { eval 'die; for (;;)  { }'; }
sub t_while { eval 'die; while (1) { }'; }

cmpthese(-60, { for => \&t_for, for2 => \&t_for2, while => \&t_while });

请注意，我正在测试infinite for循环的两个不同版本：一个版本比while循环短，而另一个版本具有额外的空间以使其长度与while循环相同。

在具有perl 5.10.1的Ubuntu 11.04 x86_64上，我得到以下结果：

          为for2评分
持续100588 / s--0％-2％
for2 100937 / s 0％--1％
而102147 / s 2％1％-

while循环显然是此平台上的赢家。

在带有perl 5.14.1的FreeBSD 8.2 x86_64上：

         为for2评分
持续53453 / s--0％-2％
for2 53552 / s 0％--2％
而54564 / s 2％2％-

虽然循环也是这里的赢家。

在带有perl 5.14.1的FreeBSD 8.2 i386上：

         为for评分
而24311 / s--1％-1％
持续24481 / s 1％--1％
for2 24637 / s 1％1％-

令人惊讶的是，带有额外空间的for循环是这里最快的选择！

我的结论是，如果程序员针对速度进行了优化，则应在x86_64平台上使用while循环。显然，在优化空间时应使用for循环。不幸的是，对于其他平台，我的结果尚无定论。

从理论上讲，一个完全天真的编译器可以将文字“ 1”存储在二进制文件中（浪费空间），并检查每次迭代是否1 == 0（浪费时间和更多空间）。

但是，实际上，即使不进行“优化”，编译器仍会将两者简化为相同的形式。他们还可能发出警告，因为它可能指示逻辑错误。例如，的参数while可能在其他地方定义，而您没有意识到它是恒定的。

令我惊讶的是，没有人提供与所需组装相对应的更直接形式：

forever:
     do stuff;
     goto forever;

while(1)是for(;;)大多数编译器都认可的惯用法。

我很高兴看到perl也认识到until(0)。

总结一下for (;;)vs while (1)辩论，很明显，在较旧的非优化编译器时代，前者速度更快，这就是为什么您倾向于在较旧的代码库（例如Lions Unix源代码评论）中看到它的原因，但是在Badass优化时代编译器将这些收益进行了优化，并结合了后者比前者更易于理解的事实，我认为这将是更可取的。

只是碰到了这个线程（尽管已经晚了很多年）。

我想我发现了“ for（;;）”比“ while（1）”更好的实际原因。

根据“ Barr编码标准2018”

Kernighan & Ritchie long ago recommended for (;;) , which has the additional benefit
of insuring against the visually-confusing defect of a while (l); referencing a variable ‘l’.

基本上，这不是速度问题，而是可读性问题。取决于代码的字体/打印方式，一段时间内的数字one（1）可能看起来像小写字母l。

即1对l。（在某些字体中，这些看起来相同）。

因此while（1）可能看起来像一些while循环，取决于变量字母L。

while（true）也可能有效，但在某些较旧的C和嵌入式C情况下，除非包含stdbool.h，否则尚未定义true / false。

我认为两者在性能方面是相同的。但是我更喜欢while（1）的可读性，但是我质疑为什么需要无限循环。

他们是一样的。还有更多重要的问题需要思考。