c++ \- - Le niveau d'optimisation -O3 est-il dangereux en g ++?




3 Answers

Dans les premiers jours de gcc (2.8 etc.) et à l'époque de egcs, et redhat 2.96 -O3 était assez bogué parfois. Mais il y a plus d'une décennie, et -O3 n'est pas très différent des autres niveaux d'optimisations (en buggyness).

Il tend toutefois à révéler des cas où les gens se fient à un comportement indéfini, en raison du fait de s'appuyer plus strictement sur les règles, et en particulier les cas de coin, de la (des) langue (s).

À titre personnel, je cours depuis plusieurs années avec des logiciels de production dans le secteur financier avec -O3 et je n'ai pas encore rencontré un bug qui n'aurait pas existé si j'avais utilisé -O2.

À la demande générale, voici un ajout:

-O3 et surtout des drapeaux additionnels comme -funroll-loops (non activés par -O3) peuvent parfois conduire à générer plus de code machine. Dans certaines circonstances (par exemple sur un CPU avec un cache d'instructions L1 exceptionnellement petit) cela peut provoquer un ralentissement dû à tout le code de par exemple une boucle interne ne s'ajustant plus dans L1I. Généralement, gcc essaie assez fort de ne pas générer autant de code, mais comme cela optimise généralement le cas générique, cela peut arriver. Les options particulièrement sujettes à cela (comme le déroulement de la boucle) ne sont normalement pas incluses dans -O3 et sont marquées en conséquence dans la page de manuel. Il est donc généralement recommandé d'utiliser -O3 pour générer du code rapide et de ne retomber que -O2 ou -Os (qui essaie d'optimiser la taille du code) le cas échéant (par exemple lorsqu'un profileur indique que L1I manque).

Si vous voulez pousser l'optimisation à l'extrême, vous pouvez ajuster dans gcc via --param les coûts associés à certaines optimisations. De plus, notez que gcc a maintenant la possibilité de placer des attributs sur des fonctions qui contrôlent les paramètres d'optimisation uniquement pour ces fonctions, donc lorsque vous rencontrez un problème avec -O3 dans une fonction (ou que vous voulez essayer des indicateurs spéciaux pour cette fonction), vous n'avez pas besoin de compiler le fichier entier ou même le projet entier avec O2.

otoh il semble que des précautions doivent être prises lors de l'utilisation de -Ofast, qui stipule:

-Ofast active toutes les optimisations -O3. Il permet également des optimisations qui ne sont pas valables pour tous les programmes conformes standard.

ce qui me fait conclure que -O3 est destiné à être entièrement conforme aux normes.

gcc flags

J'ai entendu de diverses sources (mais la plupart du temps d'un de mes collègues), que compiler avec un niveau d'optimisation de -O3 en g++ est en quelque sorte «dangereux», et devrait être évité en général à moins que nécessaire.

Est-ce vrai, et si oui, pourquoi? Devrais-je juste coller à -O2 ?




L'option -O3 active des optimisations plus coûteuses, telles que la fonction Inline, en plus de toutes les optimisations des niveaux inférieurs '-O2' et '-O1'. Le niveau d'optimisation '-O3' peut augmenter la vitesse de l'exécutable résultant, mais peut également augmenter sa taille. Dans certaines circonstances, lorsque ces optimisations ne sont pas favorables, cette option peut ralentir un programme.




Oui, O3 est buggier. Je suis un développeur de compilateur et j'ai identifié des bugs gcc clairs et évidents causés par O3 générant des instructions d'assemblage buggy SIMD lors de la construction de mon propre logiciel. D'après ce que j'ai vu, la plupart des logiciels de production sont livrés avec O2, ce qui signifie que l'O3 sera moins sollicité par les tests et les corrections de bogues.

Pensez-y de cette façon: O3 ajoute plus de transformations à O2, ce qui ajoute plus de transformations à O1. Statistiquement parlant, plus de transformations signifie plus de bugs. C'est vrai pour tout compilateur.




Related

c++ optimization g++ compiler-flags