Un nouveau niveau d’optimisation fait son apparition aux côtés des traditionnels « -Os », « -O1 », « -O2 » et « -O3 ». La nouvelle option « -Ofast » permet d’activer toutes les optimisations du niveau « -O3 » et d’ajouter en plus des options spécifiques, comme « -ffast-math », qui peuvent ne pas se conformer strictement aux standards. Si votre code n’a pas besoin de respecter religieusement la norme IEEE sur les opérations à virgule flottante, alors le niveau d’optimisation « -Ofast » est à considérer sérieusement.
Si vous avez reniflé de mépris en lisant le texte de la nouveauté précédente, parce que votre code exige la plus exquise précision de calcul possible, sachez que les développeurs de GCC 4.6 ont entendu votre appel. En effet, la bibliothèque LGPL libquadmath a été intégrée à cette version du compilateur libre, et elle permet de calculer avec une précision de 128 bits. Le type « __float128 » est maintenant accessible sur les architectures x86, x86-64 et Itanium, via le compilateur GNU Fortran. Bien entendu, un tel calcul en quad‑precision est beaucoup plus lent, puisqu’il repose sur une bibliothèque logicielle et ne s’appuie pas sur un correspondance avec les registres du processeur sous‑jacent.
Le support du langage de programmation Go, développé par Google, a été accepté par le comité technique de GCC. Il est donc maintenant possible, si GCC a été lui‑même compilé avec l’option « --enable-languages=go » configurée, d’utiliser le frontal gccgo pour compiler votre source et l’envoyer vers le back‑end commun de GCC.
Nul doute que cette intégration va permettre d’augmenter la popularité de ce langage moderne et innovant.
Comme d’habitude, GCC améliore son support des nouvelles générations de langage de programmation. Un gros travail a été effectué sur Objective-C et son nouveau standard 2.0 qui est maintenant supporté. Du côté de FORTRAN, la norme 2003 est étendue et le travail sur la version 2008 continue, avec notamment, Coarray FORTRAN qui permet de faciliter la programmation parallèle. En ce qui concerne la future norme C++0x (ne devrait-elle pas s’appeler « C++1x » maintenant ?) le tableau récapitulatif permet de se faire une idée des progrès réalisés. Enfin, le vénérable langage C n’est pas oublié, puisque le travail a déjà commencé sur le successeur de C99 ; GCC 4.6 apporte, grâce à l’option « -std=c1x », les tout premiers éléments du futur C1X.
On se souvient que la précédente version de GCC avait apporté la technique LTO (pour Link Time Optimization) qui permet des passes d’optimisations supplémentaires lors de l’édition des liens. Par défaut, dans la version 4.6, c’est maintenant l’architecture WHOPR (WHOle Program OptimiseR) qui est utilisée. Le graphe des appels de fonctions est d’abord analysé, puis partitionné pour pouvoir être distribué entre les différents processeurs. Ce partage entre les cœurs de calcul se fait grâce à l’option « -flto=n », n étant le nombre de compilations en parallèle à exécuter lors de l’édition des liens.
En plus de l’architecture WHOPR par défaut, c’est toute la fonction de Link Time Optimization qui a été largement optimisée dans GCC 4.6. De nombreux bogues ont été corrigés, et il est maintenant possible de compiler de très gros projets avec l’option « -lto », par exemple, GCC lui-même, ou encore Mozilla Firefox (voir les échanges sur cette entrée Bugzilla et le fichier PDF du sommet GCC). Les passes d’optimisations sont plus agressives et l’occupation mémoire est réduite. L’« inlining » de fonction (c-à‑d le remplacement d’un appel de fonction par une copie de son corps) a été amélioré, ce qui peut réduire significativement le temps de démarrage des grosses applications en C++. Enfin, le temps de compilation a été amélioré et des gains de 10 % environ sont enregistrés sur architecture x86‑64.
La bibliothèque Bionic écrite par Google est une alternative légère, sous licence BSD, de la glibc. Le compilateur GCC 4.6 supporte maintenant Bionic et l’option « -mandroid » permet de compiler du code compatible avec la plate-forme Android. Attention, toutefois, car cette option n’est actuellement utilisable que pour l’architecture ARM.
Sur les architectures x86 et x86-64, une nouvelle option « -fsplit-stack » permet d’utiliser une pile discontinue. Avant cette option, il était nécessaire, pour les programmes multithread, de penser à l’avance à la taille maximum que la pile pouvait atteindre. En utilisant « -fsplit-stack », la pile s’agrandira ou diminuera automatiquement en fonction des besoins réels de l’application, et non plus en fonction du pire des cas envisagé par le développeur. Cela permet d’économiser beaucoup de mémoire sur les programmes multithread. La documentation évoque même la possibilité de lancer des millions de threads NPTL depuis une machine 32 bits.
Les fonctions d’« inlining », c’est‑à‑dire la technique d’optimisation du code qui remplace l’appel d’une fonction par le code de la fonction lui‑même, ont été améliorées dans cette version du compilateur GCC. On trouve, par exemple, la nouvelle option « -fpartial-inlining » qui permet de découper une fonction en deux chemins (hot path et cold path) et d’« inliner » uniquement le hot path. Cet inlining partiel augmente les performances et réduit également l’occupation mémoire (pas de duplication du cold path dans le code).
Une nouvelle passe d’optimisation, nommée « -fipa-profile », a été ajoutée au vaste répertoire de GCC 4.6. Cette passe permet de marquer en « COLD » les fonctions qui sont appelées très rarement ou qui sont appelées seulement une fois (ayant, par exemple, l’attribut « noreturn »). Une fois ce marquage effectué, le compilateur prendra soin d’optimiser ces fonctions pour la taille (« -Os »), au lieu de les optimiser pour la vitesse (« -O3 »).
Deux autres passes d’optimisation intéressantes concernant les boucles de code sont intégrées dans cette version de GCC. L’option « -ftree-loop-if-convert » tente de transformer les sauts conditionnels qui se trouvent à l’intérieur de la boucle, pour éviter d’avoir à choisir entre plusieurs branches. Si l’on sort ce code de la boucle, on facilite la vectorisation et c’est ce qui explique pourquoi cette passe d’optimisation est activée si vous choisissez l’option de vectorisation automatique. La seconde passe se nomme « -ftree-loop-distribute-patterns » et s’occupe d’extraire les parties de la boucle qui peuvent être remplacées par des appels de fonctions.
GCC 4.6 permet maintenant d’optimiser spécifiquement le code pour les nouvelles générations de processeurs x86. L’option « -march=corei7 » optimise pour les processeurs de type Core i3 / i5 / i7, tandis que l’option « -march=corei7-avx » ajoute le support de l’unité vectorielle 256 bits AVX. En ce qui concerne AMD, c’est la puce « Bobcat » qui est maintenant supportée via « -march=btver1 ».
Du côté des processeurs ARM, très à la mode en ce moment, on trouve des améliorations de la génération du code vectoriel NEON, la réécriture de l’infrastructure de génération de code pour les instructions « load » et « store », ou encore le support amélioré des unités flottantes des puces Cortex-A9. Cette extension « vers le haut » des gammes de processeurs ARM se manifeste aussi par le support préliminaire du puissant Cortex-A15.
En ce qui concerne les processeurs un peu plus exotiques, on trouve les optimisations pour la dernière génération des représentants de l’architecture MIPS Loongson (« -march=loongson3a »), ou encore le support du z196 (« -march=z196 »), le tout dernier processeur mainframe d’IBM.
Enfin, si l’on s’interroge sur le futur de GCC, on peut se tourner vers les nombreux articles techniques publiés à l’occasion du sommet GCC 2010 d’Ottawa, qui s’est déroulé en octobre dernier (Summit2010.pdf).
Un autre point important à considérer est la décision du comité technique de GCC d’autoriser l’usage du langage C++ dans le code de GCC, alors que jusqu’à présent, seul le C était utilisé. L’usage de l’outil sémantique Coccinelle a également été évoqué pour faciliter les modifications et les restructurations du code, afin d’intégrer le C++. Ces décisions vont, bien entendu, changer beaucoup de choses dans les futures versions de GCC, même s’il est encore un peu tôt pour en évaluer l’impact. Est‑ce que le développement va s’accélerer ? Est‑ce que des nouveaux contributeurs vont se manifester ? Est‑ce que Linus Torvalds va avoir une attaque ?
