Optimiser l'élimination d'un "while(1) ;" en C++0x

Question

Mis à jour, voir ci-dessous !

J'ai entendu et lu que C++0x permet au compilateur d'imprimer "Hello" pour le snippet suivant

#include <iostream>

int main() {
  while(1) 
    ;
  std::cout << "Hello" << std::endl;
}

Cela a apparemment quelque chose à voir avec les fils et les capacités d'optimisation. Il me semble que cela peut surprendre beaucoup de gens cependant.

Quelqu'un a-t-il une bonne explication de la raison pour laquelle il était nécessaire d'autoriser cela ? Pour référence, le projet C++0x le plus récent dit à 6.5/5

Une boucle qui, en dehors de l'instruction for-init dans le cas d'une instruction for,

• ne fait aucun appel aux fonctions d'E/S de la bibliothèque, et
• n'accède pas aux objets volatils et ne les modifie pas, et
• n'effectue pas d'opérations de synchronisation (1.10) ou d'opérations atomiques (Clause 29)

peut être supposé par l'implémentation se terminer. [Note : Ceci a pour but de permettre des transformations du compilateur, telles que la suppression des boucles vides, même lorsque l'implémentation se termine. mations du compilateur, telles que la suppression des boucles vides, même lorsque la terminaison ne peut être prouvée. - note de fin ]

Editar:

Cet article perspicace dit à propos de ce texte sur les normes

Malheureusement, les mots "comportement indéfini" ne sont pas utilisés. Cependant, chaque fois que la norme dit "le compilateur peut supposer P", il est sous-entendu qu'un programme qui a la propriété not-P a une sémantique indéfinie.

Est-ce correct, et le compilateur est-il autorisé à imprimer "Bye" pour le programme ci-dessus ?

---

Il y a un encore plus perspicace fil ici qui traite d'un changement analogue au C, lancé par le type de l'article ci-dessus. Entre autres faits utiles, ils présentent une solution qui semble s'appliquer également à C++0x ( Mise à jour : Cela ne fonctionnera plus avec n3225 - voir plus bas !)

endless:
  goto endless;

Il semble qu'un compilateur ne soit pas autorisé à optimiser cela, car il ne s'agit pas d'une boucle, mais d'un saut. Un autre type résume le changement proposé dans C++0x et C201X

En écrivant une boucle, le programmeur affirme soit que la boucle fait quelque chose avec un comportement visible (effectuer des E/S, accéder à des objets volatils, ou effectue des opérations de synchronisation ou atomiques), o qu'il finit par se terminer. Si je viole cette hypothèse en écrivant une boucle infinie sans effet secondaire, je mens au compilateur et compilateur, et le comportement de mon programme est indéfini. (Si j'ai de la chance, le compilateur pourrait m'avertir à ce sujet). Le langage ne fournit pas (ne fournit plus ?) un moyen d'exprimer une boucle infinie sans comportement visible. comportement visible.

---

Mise à jour le 3.1.2011 avec n3225 : Le comité a déplacé le texte à 1.10/24 et dit

L'implémentation peut supposer que tout thread fera finalement l'une des choses suivantes :

• résilier,
• faire un appel à une fonction d'E/S de la bibliothèque,
• accéder ou modifier un objet volatil, ou
• effectuer une opération de synchronisation ou une opération atomique.

El goto l'astuce sera no plus travailler !

Answer 1

Pour moi, la justification pertinente est :

Ceci est destiné à permettre des transformations du compilateur, telles que la suppression des boucles vides, même lorsque la terminaison ne peut être prouvée.

Vraisemblablement, c'est parce que prouver la terminaison mécaniquement est difficile De plus, l'impossibilité de prouver la terminaison entrave les compilateurs qui pourraient autrement effectuer des transformations utiles, telles que le déplacement d'opérations non dépendantes d'avant la boucle à après ou vice versa, l'exécution d'opérations post-boucle dans un thread pendant que la boucle s'exécute dans un autre, etc. Sans ces transformations, une boucle pourrait bloquer tous les autres threads pendant qu'ils attendent que le seul thread termine ladite boucle. (J'utilise le terme "thread" au sens large pour désigner toute forme de traitement parallèle, y compris les flux d'instructions VLIW séparés).

EDIT : Exemple idiot :

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

Ici, il serait plus rapide pour un seul thread de faire le complex_io_operation tandis que l'autre effectue tous les calculs complexes dans la boucle. Mais sans la clause que vous avez citée, le compilateur doit prouver deux choses avant de pouvoir effectuer l'optimisation : 1) que complex_io_operation() ne dépend pas des résultats de la boucle, et 2) que la boucle se termine . Prouver 1) est assez facile, prouver 2) est le problème de halting. Avec la clause, on peut supposer que la boucle se termine et obtenir une victoire de la parallélisation.

J'imagine également que les concepteurs ont considéré que les cas où les boucles infinies se produisent dans le code de production sont très rares et qu'il s'agit généralement de choses comme des boucles pilotées par des événements qui accèdent aux E/S d'une manière ou d'une autre. En conséquence, ils ont pessimisé le cas rare (boucles infinies) en faveur de l'optimisation du cas le plus courant (boucles non infinies, mais difficiles à prouver mécaniquement non infinies).

Cela signifie toutefois que les boucles infinies utilisées dans les exemples d'apprentissage en pâtiront et poseront des problèmes dans le code des débutants. Je ne peux pas dire que ce soit entièrement une bonne chose.

EDIT : en ce qui concerne l'article perspicace que vous mettez en lien, je dirais que "le compilateur peut supposer X à propos du programme" est logiquement équivalent à "si le programme ne satisfait pas X, le comportement est indéfini". Nous pouvons le montrer comme suit : supposons qu'il existe un programme qui ne satisfait pas la propriété X. Où le comportement de ce programme serait-il défini ? La norme ne définit le comportement que si la propriété X est vraie. Bien que la norme ne déclare pas explicitement le comportement non défini, elle l'a déclaré non défini par omission.

Considérons un argument similaire : "le compilateur peut supposer qu'une variable x n'est assignée qu'au maximum une fois entre deux points de séquence" est équivalent à "assigner à x plus d'une fois entre deux points de séquence est indéfini".

Answer 2

Je pense que l'interprétation correcte est celle de votre édition : les boucles infinies vides sont un comportement indéfini.

Je ne dirais pas que c'est un comportement particulièrement intuitif, mais cette interprétation a plus de sens que l'autre, selon laquelle le compilateur est arbitrairement autorisé à ignorer boucles infinies sans invoquer UB.

Si les boucles infinies sont UB, cela signifie simplement que les programmes non terminés ne sont pas considérés comme significatifs : selon C++0x, ils tienen pas de sémantique.

Cela a aussi un certain sens. Il s'agit d'un cas particulier, où un certain nombre d'effets secondaires ne se produisent plus (par exemple, rien n'est jamais retourné de la commande main ), et un certain nombre d'optimisations du compilateur sont entravées par la nécessité de préserver les boucles infinies. Par exemple, déplacer les calculs à travers la boucle est parfaitement valable si la boucle n'a pas d'effets secondaires, parce que finalement, le calcul sera effectué dans tous les cas. Mais si la boucle ne se termine jamais, nous ne pouvons pas réarranger le code à travers elle en toute sécurité, parce que nous avons besoin d'un code de base. pourrait il suffit de changer les opérations qui sont effectivement exécutées avant que le programme ne se bloque. À moins que nous ne considérions un programme suspendu comme un UB.

Answer 3

La question pertinente est que le compilateur est autorisé à réordonner le code dont les effets secondaires ne sont pas en conflit. L'ordre d'exécution surprenant pourrait se produire même si le compilateur produisait un code machine non terminal pour la boucle infinie.

Je pense que c'est la bonne approche. La spécification du langage définit les moyens de faire respecter l'ordre d'exécution. Si vous voulez une boucle infinie qui ne peut pas être réordonnée, écrivez ceci :

volatile int dummy_side_effect;

while (1) {
    dummy_side_effect = 0;
}

printf("Never prints.\n");

Answer 4

Je pense que c'est dans la lignée de ce type de question qui fait référence à un autre filetage . L'optimisation peut occasionnellement supprimer les boucles vides.

Answer 5

Je pense qu'il est utile de souligner que des boucles qui seraient infinies, à l'exception du fait qu'elles interagissent avec d'autres threads via des variables non volatiles et non synchronisées, peuvent maintenant donner un comportement incorrect avec un nouveau compilateur.

En d'autres termes, rendez vos globaux volatils, ainsi que les arguments passés dans une telle boucle par pointeur/référence.