enquanto (1) vs. para (;;) Existe uma diferença de velocidade?

Versão longa...

Um colega de trabalho afirmou hoje depois de ver meu uso while (1)em um script Perl que for (;;)é mais rápido. Argumentei que eles deveriam ser os mesmos, esperando que o intérprete otimize quaisquer diferenças. Configurei um script que executaria 1.000.000.000 de iterações de loop e o mesmo número de loops while e registrei o tempo entre eles. Não pude encontrar nenhuma diferença apreciável. Meu colega de trabalho disse que um professor havia dito que ele while (1)estava fazendo uma comparação 1 == 1e que for (;;)não estava. Repetimos o mesmo teste com 100x o número de iterações com C ++ e a diferença foi insignificante. No entanto, foi um exemplo gráfico de quão rápido o código compilado pode ser em comparação com uma linguagem de script.

Versão curta...

Existe alguma razão para preferir um while (1)over a for (;;)se você precisar de um loop infinito para sair?

Nota: Se não estiver claro a partir da pergunta. Essa foi uma discussão acadêmica puramente divertida entre dois amigos. Estou ciente de que este não é um conceito super importante que todos os programadores deveriam agonizar. Obrigado por todas as ótimas respostas que eu (e tenho certeza que outros) aprendemos algumas coisas com essa discussão.

Atualização: O colega de trabalho acima mencionado pesou com uma resposta abaixo.

Citado aqui, caso seja enterrado.

Ele veio de um programador de montagem AMD. Ele afirmou que os programadores C (o povo) não percebem que seu código tem ineficiências. Ele disse hoje que os compiladores gcc são muito bons e colocam pessoas como ele fora do negócio. Ele disse, por exemplo, e me contou sobre o while 1vs for(;;). Eu o uso agora por hábito, mas o gcc e especialmente os intérpretes farão a mesma operação (um salto no processador) nos dois dias, pois eles são otimizados.

No perl, eles resultam nos mesmos opcodes:

$ 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

Da mesma forma no 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

Então, acho que a resposta é que são iguais em muitos compiladores. Obviamente, para alguns outros compiladores, isso pode não ser necessariamente o caso, mas é provável que o código dentro do loop seja alguns milhares de vezes mais caro do que o próprio loop, então quem se importa?

Usando o GCC, os dois parecem compilar para a mesma linguagem assembly:

L2:
        jmp     L2

Não há muitas razões para preferir um ao outro. Eu acho que, while(1)particularmente, while(true)são mais legíveis do que for(;;), mas essa é apenas a minha preferência.

Não há diferença de acordo com o padrão. 6.5.3 / 1 tem:

A declaração for

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

é equivalente a

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

E 6.5.3 / 2 tem:

Uma ou ambas as condições e a expressão podem ser omitidas. Uma condição ausente torna a cláusula implícita while equivalente a while (true).

Portanto, de acordo com o padrão C ++, o código:

for (;;);

é exatamente o mesmo que:

{
  while (true) {
    ;
    ;
  }
}

O compilador Visual C ++ usado para emitir um aviso para

while (1) 

(expressão constante), mas não para

for (;;)

Continuei a prática de preferir for (;;)por esse motivo, mas não sei se o compilador ainda faz isso atualmente.

for(;;) é um caractere a menos para digitar, se você quiser ir nessa direção para otimizar as coisas.

O Turbo C com esses compiladores antigos for(;;)resulta em um código mais rápido while(1).

Hoje, os compiladores gcc, Visual C (acho que quase todos) otimizam bem, e CPUs com 4,7 MHz raramente são usadas.

Naqueles dias, a for( i=10; i; i-- )era mais rápida do que for( i=1; i <=10; i++ ), porque a comparação ié 0, resulta em um salto condicional de CPU-Zero-Flag. E o Zero-Flag foi modificado com a última operação de decremento ( i-- ), nenhuma operação extra de cmp é necessária.

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

e aqui com for(i=1; i<=10; i++)cmpl extra:

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

Para todas as pessoas que discutem, você não deve usar indefinte enquanto faz loops e sugerir coisas idiotas, como usar goto aberto (sério, ai)

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

Realmente não pode ser representado efetivamente de nenhuma outra maneira. Não sem criar uma variável de saída e fazer magia negra para mantê-la sincronizada.

Se você tem uma inclinação para a sintaxe mais goto-esque, use algo sensato que limite o escopo.

flow: { 

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

Em última análise, a velocidade não é tão importante

Preocupar-se com a eficácia da velocidade das diferentes estruturas de loop é um enorme desperdício de tempo. Otimização prematura por completo. Não consigo pensar em nenhuma situação que já vi em que o código de perfil encontrou gargalos na minha escolha de construção de loop.

Geralmente é o como do loop e o quê do loop.

Você deve "otimizar" a legibilidade e a sucessão e escrever o que for melhor para explicar o problema ao próximo otário pobre que encontrar seu código.

Se você usar o truque "goto LABEL" que alguém mencionou, e eu tiver que usar seu código, esteja preparado para dormir com um olho aberto, especialmente se você fizer isso mais de uma vez, porque esse tipo de coisa cria um código espaguete horrível .

Só porque você pode criar código espaguete não significa que você deve

De Stroustrup, TC ++ PL (3a edição), §6.1.1:

A notação curiosa for (;;)é a maneira padrão de especificar um loop infinito; você poderia pronunciar "para sempre". [...] while (true)é uma alternativa.

Eu prefiro for (;;).

Se o compilador não fizer nenhuma otimização, for(;;)sempre será mais rápido que while(true). Isso ocorre porque a instrução while avalia a condição toda vez, mas a instrução for é um salto incondicional. Mas se o compilador otimizar o fluxo de controle, ele poderá gerar alguns códigos de operação. Você pode ler o código de desmontagem com muita facilidade.

PS, você pode escrever um loop infinito como este:

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

Eu ouvi sobre isso uma vez.

Ele veio de um programador de montagem AMD. Ele afirmou que os programadores C (as pessoas) não percebem que seu código tem ineficiências. Ele disse hoje que os compiladores gcc são muito bons e colocam pessoas como ele fora do negócio. Ele disse, por exemplo, e me contou sobre o while 1vs for(;;). Eu o uso agora por hábito, mas o gcc e especialmente os intérpretes farão a mesma operação (um salto no processador) nos dois dias, pois eles são otimizados.

Em uma construção otimizada de uma linguagem compilada, não deve haver diferença apreciável entre os dois. Nenhum deles deve terminar comparando em tempo de execução; eles apenas executarão o código do loop até você sair manualmente do loop (por exemplo, com a break).

Estou surpreso que ninguém testou corretamente for (;;)contra o while (1)perl!

Como o perl é uma linguagem interpretada, o tempo para executar um script perl não consiste apenas na fase de execução (que neste caso é a mesma), mas também na fase de interpretação antes da execução. Ambas as fases devem ser levadas em consideração ao fazer uma comparação de velocidade.

Felizmente, o perl possui um módulo Benchmark conveniente , que podemos usar para implementar um benchmark, como a seguir:

#!/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 });

Observe que estou testando duas versões diferentes do loop for infinito: uma que é mais curta que o loop while e outra que possui um espaço extra para torná-lo com o mesmo comprimento do loop while.

No Ubuntu 11.04 x86_64 com perl 5.10.1, recebo os seguintes resultados:

          Taxa para for2 enquanto
para 100588 / s - -0% -2%
for2 100937 / s 0% - -1%
enquanto 102147 / s 2% 1% -

O loop while é claramente o vencedor nesta plataforma.

No FreeBSD 8.2 x86_64 com perl 5.14.1:

         Taxa para for2 enquanto
para 53453 / s - -0% -2%
for2 53552 / s 0% - -2%
enquanto 54564 / s 2% 2% -

Enquanto loop é o vencedor aqui também.

No FreeBSD 8.2 i386 com perl 5.14.1:

         Avalie enquanto for2
enquanto 24311 / s - -1% -1%
para 24481 / s 1% - -1%
for2 24637 / s 1% 1% -

Surpreendentemente, o loop for com um espaço extra é a escolha mais rápida aqui!

Minha conclusão é que o loop while deve ser usado na plataforma x86_64 se o programador estiver otimizando a velocidade. Obviamente, um loop for deve ser usado ao otimizar espaço. Infelizmente, meus resultados são inconclusivos em relação a outras plataformas.

Em teoria, um compilador completamente ingênuo poderia armazenar o literal '1' no binário (desperdiçando espaço) e verificar se 1 == 0 a cada iteração (desperdiçando tempo e mais espaço).

Na realidade, no entanto, mesmo com otimizações "não", os compiladores ainda reduzirão os dois para o mesmo. Eles também podem emitir avisos porque podem indicar um erro lógico. Por exemplo, o argumento de whilepoderia ser definido em outro lugar e você não percebe que é constante.

Estou surpreso que ninguém tenha oferecido a forma mais direta, correspondente à montagem desejada:

forever:
     do stuff;
     goto forever;

while(1)é um idioma for(;;)reconhecido pela maioria dos compiladores.

Fiquei feliz em ver que perl também reconhece until(0).

Para resumir o for (;;)vswhile (1) debate Nos compiladores, esses ganhos são otimizados, pois, com o fato de que o último é mais fácil de entender do que o primeiro, acredito que seria mais preferível.

Acabei de encontrar esse tópico (apesar de alguns anos atrasado).

Acho que encontrei a verdadeira razão pela qual "para (;;)" é melhor que "enquanto (1)".

de acordo com o "padrão de codificação 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’.

Basicamente, esse não é um problema de velocidade, mas de legibilidade. Dependendo da fonte / impressão do código, o número um (1) em algum momento pode parecer uma letra minúscula l.

ie 1 vs l. (em algumas fontes, elas parecem idênticas).

Assim, while (1) pode parecer um loop while dependente da variável letra L.

while (true) também pode funcionar, mas em alguns casos mais antigos de C e C incorporados, true / false ainda não estão definidos, a menos que stdbool.h esteja incluído.

Eu pensaria que ambos são iguais em termos de desempenho. Mas eu preferiria o (1) para facilitar a leitura, mas questiono por que você precisa de um loop infinito.

Eles são os mesmos. Há questões muito mais importantes a serem ponderadas.