Comstackr GNU / Linux avec l'optimization -O3

On dit que la compilation des outils GNU et du kernel Linux avec l'option d'optimization -O3 gcc produira des bugs bizarres et funky. Est-ce vrai? Quelqu'un at-il essayé ou est-ce juste un canular?

Il est utilisé à Gentoo, et je n'ai rien remarqué d'inhabituel.

-O3 a plusieurs inconvénients:

  1. Tout d'abord, il produit souvent un code plus lent que -O2 ou -Os . Parfois, il produit un code plus long en raison du déroulement de la boucle, qui peut être en fait plus lent en raison de performances de cache plus faibles du code.
  2. Comme il a été dit, il produit parfois un mauvais code. Cela peut être dû à une erreur d'optimization ou à une erreur de code (comme ignorer un aliasing ssortingct). Comme le code du kernel est parfois et doit parfois être «intelligent», je dirais qu'il est possible que certains développeurs du kernel aient fait une erreur. J'ai rencontré divers problèmes étranges, comme l'écrasement des utilitaires de l'espace user, lorsque j'ai compilé le kernel avec gcc 4.5 qui était alors stable. J'utilise toujours gcc 4.4 pour le kernel et plusieurs utilitaires d'espace user sélectionnés en raison de divers bugs. La même chose peut s'appliquer pour -O3 .
  3. Je ne pense pas que cela offre beaucoup d'avantages pour le kernel Linux. Le kernel ne fait pas de calculs lourds et dans les endroits qu'il fait, il est optimisé avec l'assemblage. -O3 ne changera pas le coût de la commutation de context ou la vitesse des E / S. Je ne pense pas que quelque chose comme <0.1% d'accélération de la performance globale en vaut la peine.

Notez que les gros morceaux de la string d'outils (glibc en particulier) ne comstacknt pas si vous modifiez les niveaux d'optimization. Le système de construction est configuré pour ignorer vos preferences -O pour ces sections sur la plupart des dissortingbutions saines.

Autrement dit, certaines fonctions fondamentales de la librairie et du operating system dépendent du code qui fait ce qu'il dit, et non ce qui serait plus rapide dans de nombreux cas. -fgcse-after-reload en particulier (activé par -O3) peut provoquer des problèmes étranges.

Au cours des 10 dernières années, j'ai couru plusieurs systèmes Gentoo avec plus de 1000 packages en utilisant -O3 -march=native globalement et je n'ai pas encore rencontré ces problèmes de stabilité mythiques que -O3 est censé avoir. Les benchmarks des applications gourmandes en CPU (comme les applications mathématiques / scientifiques) montrent systématiquement -O3 pour produire du code plus rapide, après tout, ce serait inutile si ce n'était pas le cas. Pour la majorité des applications de bureau, les CFLAGS n'ont pas beaucoup d'importance puisqu'elles sont liées par des inputs-sorties, mais cela importe beaucoup pour les trucs côté server qui sont liés au processeur.

-O3 utilise des optimizations agressives qui ne sont sûres que si certaines hypothèses concernant l'utilisation du registre, la façon dont les frameworks de stack interagissent et la réentrance de la fonction sont vraies et ces hypothèses ne sont pas garanties dans certains codes comme le kernel utilisé (comme c'est le cas dans certaines parties du kernel et du pilote).

Bien que vous puissiez utiliser l'option -O3 et d'autres buttons d'optimization sur la plupart des applications (et cela peut entraîner des améliorations de vitesse), j'hésiterais à utiliser de tels réglages, le kernel lui-même ou la string d'outils nécessaire pour le comstackr (compilateur, binutils, etc.).

Pensez-y: un gain de performance de 5% des sous-systèmes raid et ext3 vaut-il la peine d'un système ou d'une perte potentielle de données et / ou d'une corruption?

Tweak tous les buttons à vouloir pour ce port Quake que vous jouez ou les codecs audio / video que vous utilisez pour extraire votre collection de DVD vers des files DivX. Vous verrez probablement une amélioration. Il suffit de ne pas gâcher avec le kernel, sauf si vous avez le time de perdre et datatables que vous pouvez supporter de perdre.