mientras que (1) vs. para (;;) ¿Hay una diferencia de velocidad?

Versión larga...

Un compañero de trabajo afirmó hoy después de ver mi uso while (1)en un script de Perl que for (;;)es más rápido. Argumenté que deberían ser los mismos con la esperanza de que el intérprete optimizara cualquier diferencia. Configuré un script que ejecutaría 1,000,000,000 para iteraciones de bucles y la misma cantidad de bucles while y registraría el tiempo entre ellos. No pude encontrar una diferencia apreciable. Mi compañero de trabajo dijo que un profesor le había dicho que while (1)estaba haciendo una comparación 1 == 1y que for (;;)no. Repetimos la misma prueba con 100x el número de iteraciones con C ++ y la diferencia fue insignificante. Sin embargo, fue un ejemplo gráfico de cuánto más rápido puede ser el código compilado frente a un lenguaje de script.

Version corta...

¿Hay alguna razón para preferir un while (1)sobre a for (;;)si necesita un bucle infinito para salir?

Nota: Si no está claro en la pregunta. Esta fue una discusión académica puramente divertida entre un par de amigos. Soy consciente de que este no es un concepto súper importante que todos los programadores deberían agonizar. Gracias por todas las excelentes respuestas que (y estoy seguro de que otros) he aprendido algunas cosas de esta discusión.

Actualización: el mencionado compañero de trabajo intervino con una respuesta a continuación.

Citado aquí en caso de que quede enterrado.

Provenía de un programador de ensamblaje de AMD. Afirmó que los programadores de C (la gente) no se dan cuenta de que su código tiene ineficiencias. Sin embargo, dijo hoy que los compiladores de gcc son muy buenos y dejan a personas como él fuera del negocio. Dijo por ejemplo, y me habló de la while 1frente for(;;). Lo uso ahora por costumbre, pero gcc y especialmente los intérpretes harán la misma operación (un salto de procesador) durante estos dos días, ya que están optimizados.

En perl, dan como resultado los mismos códigos de operación:

$ 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

Asimismo en 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

Así que supongo que la respuesta es que son los mismos en muchos compiladores. Por supuesto, para algunos otros compiladores esto puede no ser necesariamente el caso, pero es probable que el código dentro del bucle sea unos miles de veces más costoso que el bucle en sí mismo, entonces, ¿a quién le importa?

Usando GCC, ambos parecen compilarse en el mismo lenguaje ensamblador:

L2:
        jmp     L2

No hay muchas razones para preferir uno sobre el otro. Creo que, while(1)y particularmente, while(true)son más legibles que for(;;), pero esa es solo mi preferencia.

No hay diferencia según el estándar. 6.5.3 / 1 tiene:

La declaración for

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

es equivalente a

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

Y 6.5.3 / 2 tiene:

Cualquiera o ambas condiciones y la expresión pueden omitirse. Una condición faltante hace que la cláusula while implícita sea equivalente a while (verdadero).

Entonces, de acuerdo con el estándar C ++, el código:

for (;;);

es exactamente lo mismo que:

{
  while (true) {
    ;
    ;
  }
}

El compilador de Visual C ++ solía emitir una advertencia para

while (1) 

(expresión constante) pero no para

for (;;)

Continué con la práctica de preferir for (;;)por esa razón, pero no sé si el compilador todavía lo hace en estos días.

for(;;) es un personaje menos para escribir si quieres ir en esa dirección para optimizar las cosas.

Turbo C con estos viejos compiladores for(;;)resulta en un código más rápido entonces while(1).

Hoy en día, los compiladores gcc, Visual C (creo que casi todos) se optimizan bien, y las CPU con 4.7 MHz rara vez se usan.

En aquellos días, a for( i=10; i; i-- )era más rápido que for( i=1; i <=10; i++ ), porque comparar ies 0, resulta en un salto condicional CPU-Zero-Flag. Y la Bandera Cero se modificó con la última operación de disminución ( i-- ), no se necesita ninguna operación cmp adicional.

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

y aquí con 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 las personas que argumentan que no deberías usar bucles while indefinidos, y que sugieren cosas tontas como usar goto 's abiertos (en serio, ¡ay!)

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

Realmente no se puede representar efectivamente de otra manera. No sin crear una variable de salida y hacer magia negra para mantenerla sincronizada.

Si le gusta la sintaxis más goto-esque, use algo sensato que limite el alcance.

flow: { 

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

En última instancia, la velocidad no es tan importante

Preocuparse por cuán efectivas son las construcciones de bucle diferentes en cuanto a velocidad es una enorme pérdida de tiempo. Optimización prematura de principio a fin. No puedo pensar en ninguna situación que haya visto en la que el código de perfil encontró cuellos de botella en mi elección de construcción en bucle.

Generalmente es el cómo del bucle y el qué del bucle.

Debe "optimizar" la legibilidad y la concisión, y escribir lo que sea mejor para explicar el problema al próximo tonto que encuentre su código.

Si usa el truco "ir a LA ETIQUETA" que alguien mencionó, y tengo que usar su código, prepárese para dormir con un ojo abierto, especialmente si lo hace más de una vez, porque ese tipo de cosas crea un espantoso código de espagueti.

El hecho de que pueda crear código de espagueti no significa que deba

De Stroustrup, TC ++ PL (3a edición), §6.1.1:

La notación curiosa for (;;)es la forma estándar de especificar un bucle infinito; puedes pronunciarlo "para siempre". [...] while (true)es una alternativa.

Yo prefiero for (;;).

Si el compilador no realiza ninguna optimización, for(;;)siempre sería más rápido quewhile(true) . Esto se debe a que while-instrucción evalúa la condición cada vez, pero for-instrucción es un salto incondicional. Pero si el compilador optimiza el flujo de control, puede generar algunos códigos de operación. Puede leer el código de desmontaje muy fácilmente.

PD: podrías escribir un bucle infinito como este:

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

Escuché sobre esto una vez.

Provenía de un programador de ensamblaje de AMD. Dijo que los programadores de C (las personas) no se dan cuenta de que su código tiene ineficiencias. Sin embargo, dijo hoy que los compiladores de gcc son muy buenos y dejan a personas como él fuera del negocio. Dijo por ejemplo, y me habló de la while 1frente for(;;). Lo uso ahora por costumbre, pero gcc y especialmente los intérpretes harán la misma operación (un salto de procesador) durante estos dos días, ya que están optimizados.

En una compilación optimizada de un lenguaje compilado, no debería haber una diferencia apreciable entre los dos. Ninguno de los dos debe terminar realizando comparaciones en tiempo de ejecución, solo ejecutarán el código del bucle hasta que salga manualmente del bucle (por ejemplo, con a break).

¡Me sorprende que nadie haya probado adecuadamente en for (;;)comparación while (1)con Perl!

Debido a que perl es un lenguaje interpretado, el tiempo para ejecutar un script perl no solo consiste en la fase de ejecución (que en este caso es la misma) sino también en la fase de interpretación antes de la ejecución. Ambas fases deben tenerse en cuenta al hacer una comparación de velocidad.

Afortunadamente, Perl tiene un conveniente módulo de referencia que podemos usar para implementar una referencia como la siguiente:

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

Tenga en cuenta que estoy probando dos versiones diferentes del bucle infinito: una que es más corta que el bucle while y otra que tiene un espacio adicional para que tenga la misma longitud que el bucle while.

En Ubuntu 11.04 x86_64 con perl 5.10.1 obtengo los siguientes resultados:

          Tasa para for2 while
para 100588 / s - -0% -2%
para2 100937 / s 0% - -1%
mientras que 102147 / s 2% 1% -

El ciclo while es claramente el ganador en esta plataforma.

En FreeBSD 8.2 x86_64 con perl 5.14.1:

         Tasa para for2 while
para 53453 / s - -0% -2%
para2 53552 / s 0% - -2%
mientras 54564 / s 2% 2% -

Mientras que loop es el ganador aquí también.

En FreeBSD 8.2 i386 con perl 5.14.1:

         Califica mientras for2
mientras 24311 / s - -1% -1%
para 24481 / s 1% - -1%
para2 24637 / s 1% 1% -

¡Sorprendentemente, el bucle for con un espacio extra es la opción más rápida aquí!

Mi conclusión es que el ciclo while debe usarse en la plataforma x86_64 si el programador está optimizando la velocidad. Obviamente, se debe usar un bucle for al optimizar el espacio. Lamentablemente, mis resultados no son concluyentes con respecto a otras plataformas.

En teoría, un compilador completamente ingenuo podría almacenar el literal '1' en el binario (pérdida de espacio) y verificar si 1 == 0 en cada iteración (pérdida de tiempo y más espacio).

En realidad, sin embargo, incluso con optimizaciones "no", los compiladores seguirán reduciendo ambos a la misma. También pueden emitir advertencias porque podría indicar un error lógico. Por ejemplo, el argumento de whilepodría definirse en otro lugar y no te das cuenta de que es constante.

Me sorprende que nadie haya ofrecido la forma más directa, correspondiente al ensamblaje deseado:

forever:
     do stuff;
     goto forever;

while(1)es un idioma para el for(;;)cual es reconocido por la mayoría de los compiladores.

Me alegró ver que Perl también lo reconoce until(0).

Para resumir el debate for (;;)vs while (1)es obvio que el primero fue más rápido en los días de los compiladores no optimizadores más antiguos, es por eso que tiende a verlo en bases de código más antiguas, como los comentarios de código fuente de Lions Unix, sin embargo, en la era de la optimización rudo Los compiladores de esas ganancias se optimizan combinando eso con el hecho de que este último es más fácil de entender que el primero, creo que sería más preferible.

Acabo de encontrar este hilo (aunque algunos años tarde).

Creo que encontré la razón real por la cual "for (;;)" es mejor que "while (1)".

de acuerdo con el "barr coding standard 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’.

Básicamente, este no es un problema de velocidad, sino un problema de legibilidad. Dependiendo de la fuente / impresión del código, el número uno (1) en un momento puede parecer una letra minúscula l.

es decir, 1 vs l. (en algunas fuentes se ven idénticas).

Por lo tanto, while (1) puede parecer un ciclo while dependiente de la letra variable L.

while (verdadero) también puede funcionar, pero en algunos casos antiguos de C y C incrustados, verdadero / falso aún no están definidos a menos que se incluya stdbool.h.

Creo que ambos son iguales en términos de rendimiento. Pero preferiría while (1) para facilitar la lectura, pero me pregunto por qué necesita un bucle infinito.

Ellos son iguales. Hay preguntas mucho más importantes para reflexionar.