Optimizando un "while(1);" en C++0x

Para mí, la justificación relevante es:

Esto está destinado a permitir transfor - maciones del compilador, tales como la eliminación de bucles vacíos, incluso cuando la terminación no puede ser probada.

Presumiblemente, esto se debe a que probar la terminación mecánicamente es difícil, y la incapacidad de probar la terminación dificulta a los compiladores que de otra manera podrían hacer transformaciones útiles, como mover operaciones no dependientes desde antes del bucle a después o viceversa, operaciones post-bucle en un hilo mientras que el bucle se ejecuta en otro, y así sucesivamente. Sin estas transformaciones, un bucle podría bloquear todos los demás subprocesos mientras esperan que el único subproceso termine dicho bucle. (Uso "hilo" libremente para significar cualquier forma de procesamiento paralelo, incluyendo flujos de instrucción VLIW separados.)

EDITAR: Ejemplo tonto:

while (complicated_condition()) {
    x = complicated_but_externally_invisible_operation(x);
}
complex_io_operation();
cout << "Results:" << endl;
cout << x << endl;

Aquí, sería más rápido para un hilo hacer el complex_io_operation mientras que el otro está haciendo todos los cálculos complejos en el bucle. Pero sin la cláusula que has citado, el compilador tiene que probar dos cosas antes de poder hacer la optimización: 1) que complex_io_operation() no depende de los resultados del bucle, y 2) que el bucle terminará. Probar 1) es bastante fácil, probar 2) es el problema de detención. Con la cláusula, puede asumir que el bucle termina y obtener una ganancia de paralelización.

También imagino que los diseñadores consideraron que los casos en los que se producen bucles infinitos en el código de producción son muy raros y son por lo general, cosas como bucles impulsados por eventos que acceden a E/S de alguna manera. Como resultado, han pesimizado el caso raro (bucles infinitos) a favor de optimizar el caso más común (bucles no infinitos, pero difíciles de probar mecánicamente no infinitos).

Sin embargo, significa que los bucles infinitos utilizados en ejemplos de aprendizaje sufrirán como resultado, y aumentarán las gotchas en el código de principiante. No puedo decir que esto sea del todo bueno.

EDITAR: con respecto al artículo perspicaz ahora enlace, yo diría que "el compilador puede asumir X sobre el programa" es lógicamente equivalente a "si el programa no satisface X, el comportamiento es indefinido". Podemos mostrar esto de la siguiente manera: supongamos que existe un programa que no satisface la propiedad X. ¿Dónde se definiría el comportamiento de este programa? El Estándar solo define el comportamiento asumiendo que la propiedad X es verdadera. Aunque el Estándar no declara explícitamente el comportamiento indefinido, lo ha declarado indefinido por omisión.

Considere un argumento similar: "el compilador puede asumir que una variable x solo se asigna a lo sumo una vez entre puntos de secuencia" es equivalente a "asignar a x más de una vez entre puntos de secuencia es indefinido".

Creo que la interpretación correcta es la de su edición: los bucles infinitos vacíos son un comportamiento indefinido.

No diría que es un comportamiento particularmente intuitivo, pero esta interpretación tiene más sentido que la alternativa, que al compilador se le permite arbitrariamente ignorar bucles infinitos sin invocar UB.

Si los bucles infinitos son UB, solo significa que los programas no terminantes no se consideran significativos: de acuerdo con C++0x, tienen no semántica.

Eso también tiene cierto sentido. Son un caso especial, donde una serie de efectos secundarios simplemente ya no ocurren (por ejemplo, nunca se devuelve nada de main), y una serie de optimizaciones del compilador se ven obstaculizadas por tener que preservar bucles infinitos. Por ejemplo, mover cálculos a través del bucle es perfectamente válido si el bucle no tiene efectos secundarios, porque eventualmente, el cálculo se realizará en cualquier caso. Pero si el bucle nunca termina, no podemos reorganiza de forma segura el código a través de él, porque podríamos simplemente cambiar qué operaciones realmente se ejecutan antes de que el programa se cuelgue. A menos que tratemos un programa colgante como UB, eso es.

Creo que esto está en la línea de este tipo de pregunta , que hace referencia a otro hilo . La optimización puede ocasionalmente eliminar bucles vacíos.

El problema relevante es que al compilador se le permite reordenar código cuyos efectos secundarios no entran en conflicto. El sorprendente orden de ejecución podría ocurrir incluso si el compilador produjera código máquina no terminante para el bucle infinito.

Creo que este es el enfoque correcto. La especificación de lenguaje define formas de hacer cumplir el orden de ejecución. Si desea un bucle infinito que no se puede reordenar, escriba esto:

volatile int dummy_side_effect;

while (1) {
    dummy_side_effect = 0;
}

printf("Never prints.\n");

Creo que el problema podría ser mejor dicho, ya que "Si un fragmento de código posterior no depende de un fragmento de código anterior, y el fragmento de código anterior no tiene efectos secundarios en ninguna otra parte del sistema, la salida del compilador puede ejecutar el fragmento de código posterior antes, después o entremezclado con la ejecución del primero, incluso si el primero contiene bucles, sin tener en cuenta cuándo o si el código anterior realmente completaría . Por ejemplo, el compilador podría reescribir:

void testfermat(int n)
{
  int a=1,b=1,c=1;
  while(pow(a,n)+pow(b,n) != pow(c,n))
  {
    if (b > a) a++; else if (c > b) {a=1; b++}; else {a=1; b=1; c++};
  }
  printf("The result is ");
  printf("%d/%d/%d", a,b,c);
}

Como

void testfermat(int n)
{
  if (fork_is_first_thread())
  {
    int a=1,b=1,c=1;
    while(pow(a,n)+pow(b,n) != pow(c,n))
    {
      if (b > a) a++; else if (c > b) {a=1; b++}; else {a=1; b=1; c++};
    }
    signal_other_thread_and_die();
  }
  else // Second thread
  {
    printf("The result is ");
    wait_for_other_thread();
  }
  printf("%d/%d/%d", a,b,c);
}

Generalmente no es irrazonable, aunque podría preocuparme de que:

  int total=0;
  for (i=0; num_reps > i; i++)
  {
    update_progress_bar(i);
    total+=do_something_slow_with_no_side_effects(i);
  }
  show_result(total);

Se convertiría en

  int total=0;
  if (fork_is_first_thread())
  {
    for (i=0; num_reps > i; i++)
      total+=do_something_slow_with_no_side_effects(i);
    signal_other_thread_and_die();
  }
  else
  {
    for (i=0; num_reps > i; i++)
      update_progress_bar(i);
    wait_for_other_thread();
  }
  show_result(total);

Al hacer que una CPU maneje los cálculos y otra maneje las actualizaciones de la barra de progreso, la reescritura mejoraría la eficiencia. Desafortunadamente, haría que las actualizaciones de la barra de progreso fueran menos útiles de lo que deberían ser.

No es decidible para el compilador para casos no triviales si es un bucle infinito en absoluto.

En diferentes casos, puede suceder que su optimizador alcance una clase de complejidad mejor para su código (por ejemplo, era O(n^2) y obtiene O(n) u O(1) después de la optimización).

Por lo tanto, incluir tal regla que no permite eliminar un bucle infinito en el estándar de C++ haría que muchas optimizaciones fueran imposibles. Y la mayoría de la gente no quiere esto. Creo que esto responde bastante a su pregunta.

Otra cosa: Nunca he visto ningún ejemplo válido donde se necesita un bucle infinito que no hace nada.

El único ejemplo del que he oído hablar fue un truco feo que realmente debería resolverse de otra manera: Se trataba de sistemas embebidos donde la única manera de desencadenar un reinicio era congelar el dispositivo para que el perro guardián lo reinicie automáticamente.

Si conoces algún ejemplo válido/bueno en el que necesites un bucle infinito que no haga nada, por favor dímelo.

Creo que vale la pena señalar que los bucles que serían infinitos excepto por el hecho de que interactúan con otros hilos a través de variables no volátiles y no sincronizadas ahora pueden producir un comportamiento incorrecto con un nuevo compilador.

En otras palabras, haga que sus globales sean volátiles well así como los argumentos pasados a dicho bucle a través del puntero/referencia.