Liens connexes

Dépêche modérée par

Dépêche éditée par

: Sortie de la version 4.4 du compilateur GCC

Posté par patrick_g (page perso, ). Modéré le 21 avril 2009.
42
Aujourd'hui la sortie de la version 4.4 du compilateur GCC a été annoncée sur la liste de diffusion du projet.
Écrit à l'origine par Richard Stallman, le logiciel GCC (GNU Compiler Collection) est le compilateur de référence du monde du logiciel libre. Il accepte des codes source écrits en C, C++, Objective-C, Fortran, Java et Ada et fonctionne sur une multitude d'architectures.

La sortie de GCC 4.4 a été grandement retardée par des questions d'ordre juridiques. En effet la FSF a dû se prononcer sur la nouvelle "Runtime Library Exception" qui autorise le passage des diverses bibliothèques sous licence GPLv3 ainsi que l'arrivée prochaine des greffons dans l'architecture de GCC. La FSF étant connue pour sa hâte toute relative sur les questions juridiques il a fallu patienter ce qui a provoqué un certain mécontentement chez plusieurs développeurs. Néanmoins le comité directeur de GCC a préféré jouer la prudence (better safe than fast) et attendre d'avoir l'aval des juristes de la FSF avant d'autoriser la sortie tant attendue.

Dans la suite de la dépêche, vous pourrez découvrir les nouveautés et les optimisations mises en œuvre dans cette version 4.4 de GCC.

NdM : pour l'anecdote, cette dépêche a été initialement soumise le 18 décembre 2008, a attendu la sortie officielle de GCC 4.4, et à ce titre remporte le titre de dépêche restée le plus longtemps en modération (le record précédent étant de 70 jours).

> Lire la suite (96 commentaires, moyenne: 4).   [dépêche : 16403 caractères]

Nouvel allocateur de registres

Un nouvel allocateur de registres sophistiqué est incorporé dans la version 4.4 de GCC.

L'allocation de registres est une tâche très importante qu'effectue le compilateur. En effet il doit arriver à assigner aux variables du programme un « endroit » où elles seront stockées pour exécution. Ce sont les registres du processeur qui vont accueillir ces variables mais, petit problème, ces registres sont fort peu nombreux alors que les variables d'un programme sont souvent très nombreuses. Typiquement un processeur x86 possède seulement 8 registres, la variante x86-64 en possède 16 et un processeur PowerPC jouit de 32 registres.

Pour trouver la solution optimale afin de « masquer » ce faible nombre de registres le compilateur doit s'appuyer sur des algorithmes très complexes souvent liés à la théorie des graphes et notamment au coloriage de graphes.

Le compilateur GCC 4.4 propose l'allocateur IRA (Integrated Register Allocator) qui est le résultat de plusieurs d'années d'expérimentation avec la branche YARA (Yet Another Register Allocator) par le développeur Vladimir Makarov qui travaille pour Red Hat.

Cet allocateur intégré ultra-moderne permet de choisir entre plusieurs algorithmes et plusieurs paramètres (avec les options -fira-algorithm et -fira-region).

En ce qui concerne les choix de -fira-algorithm on peut opter pour "CB" qui est un allocateur basé sur l'algorithme de Chaitin-Briggs ou pour "Priority" qui utilise l'algorithme de Chow. "CB" est utilisé par défaut.

Pour la région il est possible de choisir entre "All", "One" et "Mixed". L'option "All" fonctionne bien avec les processeurs n'ayant que peu de registres alors que l'option "One" considère toute la fonction comme une seule région et est bien adaptée aux architectures dotées d'un grand nombre de registres. Le troisième choix est un mélange des deux précédents (ce qui explique son nom "Mixed") et c'est celui qui est utilisé par défaut puisqu'il propose les meilleures performances dans la plupart des cas et sur la plupart des architectures de processeurs.

Pour avoir une idée du gain en performances il est possible de consulter cet article au format pdf de Vladimir Makarov. Les considérations techniques sont extrêmement absconses mais le paragraphe 3 propose un graphe comparant les scores des allocateurs de "Chaitin-Briggs" (sans région), de "Callahan-Koblenz" et du nouvel allocateur de GCC 4.4 (nommé "Regional" dans l'article). Que ce soit en terme de rapidité ou de taille de code la victoire du nouvel allocateur IRA est sans appel.

Branche Graphite

Après IRA la seconde grande nouveauté de GCC 4.4 est l'intégration de la branche "Graphite" qui permet d'optimiser l'exécution des boucles de code.

Cette étape d'optimisation des boucles effectuée par le compilateur est une tâche importante puisque le bénéfice en terme de temps d'exécution est souvent très visible. Du fait de ces optimisations savantes effectuées par le compilateur la pression sur la mémoire cache peut être réduite et le travail peut être mieux distribué entre les processeurs.

L'orientation choisie par la branche Graphite relève de la méthode des polytopes qui est une approche très mathématisée de la théorie des compilateurs. Pour résumer ce soubassement théorique on peut dire que cela consiste à transformer les boucles de code en figures géométriques complexes afin de trouver des optimisations puis à transformer à nouveau les figures en code optimisé.

Plus techniquement : un polygone est une figure fermée sur le plan et qui est délimitée par des segments de droite, un polyèdre c'est la même chose en trois dimensions et un polytope c'est la même chose en dimension n.

La méthode des polytopes consiste à transformer les boucles des programmes en polytopes (les itérations d'une boucle de code sont représentées comme des points à la "surface" de la figure multidimensionnelle), appliquer diverses opérations mathématiques sur ces polytopes (des transfomations affines) puis à transformer à nouveau les polytopes en boucles sémantiquement équivalentes aux boucles initiales mais super-optimisées.

On voit bien que le sujet est complexe et on ne s'étonnera donc pas que cette méthode ait surtout été développée par des universitaires dans diverses bibliothèques de programmes. Ainsi la bibliothèque Graphite qui est intégré dans GCC 4.4 est décrite en détail dans ce fichier pdf par des chercheurs de l'École des mines de Paris, de L'INRIA et de l'université d'Orsay. Selon ce document, GCC 4.4 est le tout premier compilateur de production au monde qui intègre une optimisation par la méthode des polytopes.

Les passes d'optimisation qui sont prises en charge par Graphite se déroulent quand le code source a été transformé dans la représentation générique GIMPLE. On fait ainsi une transformation GIMPLE -> Graphite -> GIMPLE pour optimiser toutes les boucles avec la méthode des polytopes ce qui explique le nom choisi pour Graphite (GIMPLE Represented as Polyhedra with Interchangeable Envelopes).

Actuellement ces passes d'optimisations sont mises en œuvre à l'aide des commandes "-floop-block", "-floop-interchange", "-floop-stripmine" et "-fgraphite" mais la discussion a été vive afin de trouver les conventions de nommages les plus explicites.

Le résultat brut est très impressionnant puisque selon Sebastian Pop (premier auteur de l'article sur Graphite et auteur de plusieurs autres présentations) le gain apporté par cette optimisation est inégalé (test effectué sur le benchmark spécifique swim du comparatif standard SPEC2000) : "Comparé aux performances du meilleur compilateur disponible, PathScale EKOPath (V2.1) avec l'option d'optimisation peak-SPEC, notre outil permet d'obtenir un gain de vitesse de 32% sur Athlon XP et de 38% sur Athlon 64. Nous ne sommes pas au courant d'un autre projet d'optimisation - manuel ou automatique - qui permettrait au benchmark swim d'atteindre ce niveau de performance sur processeur x86".

D'autres nouveautés en bref...


L'infrastructure du projet...

La ferme de compilation du projet GCC a grandement augmenté ces derniers mois sa couverture des architectures supportées par le compilateur libre. Ce sont maintenant 12 architectures différentes qui sont représentées et on peut noter la présence de plusieurs bêtes de guerre (serveurs x86-64 bi-quad-cores avec 16 Go de mémoire vive).

Laurent Guerby est très impliqué dans la mise en place et l'organisation de cette ferme de compilation alors n'hésitez pas à prendre contact avec lui si vous pouvez faire un don de matériel ou obtenir des rabais auprès de vendeurs. Des machines puissantes en architecture mips, arm, powerpc64 ou sparc64 sont recherchées.

Pour finir...

Le compte rendu complet du sommet annuel GCC 2008 permet d'avoir une bonne idée du travail en cours sur le compilateur libre et de connaître à l'avance les nouveautés qui rentreront dans les futures versions. Les articles (très techniques) au format PDF sont disponibles sur le site du projet Fedora.

On y trouve notamment l'utilisation de GCC en tant qu'outil de vérification statique du code par les développeurs de Mozilla (Using GCC Instead of Grep and Sed), le travail sur la compilation incrémentale afin d'accélérer le cycle de développement (Incremental Compilation for GCC) ou encore l'inclusion de règles de codage directement dans le compilateur afin d'interdire la compilation de code non conforme aux normes édictées par un projet (Adding Coding Rule Checking Capabilities to the GCC Toolchain).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Bravo

Posté par med (page perso, ) le 21/04/2009 à 17:42. (lien). Évalué à 9.

Aux développeurs de gcc pour tout le travail accompli et à patrick_g pour cette magnifique dépêche. Comme quoi tout vient à point à qui sait attendre. ;)

POISSON D'AVRIL !!!!!!

Posté par Moun's (page perso, ) le 21/04/2009 à 17:43. (lien). Évalué à 5.

en fait, c'est une blague que l'on a faite à patrick_g parmi les AMR ... GCC 4.4 n'est toujours pas sorti.

Gains de performance

Posté par seginus () le 21/04/2009 à 17:47. (lien). Évalué à 4.

Je n'ai que peu de connaissances en compilation, utilisant surtout des languages interprétés. Cependant, ayant utilisé longtemps Gentoo, cela compense un peu.

Les gains de performances de 32 et 38% annoncé pour les athlons sont bien des temps de « rapidité » à l'exécution des programmes ? Cela me semble énorme. Cela veut-il dire qu'en recompilant par exemple une distribution source avec le nouveau compilateur, le gain de vitesse se fera vraiment ressentir au niveau du système ? ou est-ce des optimisations qui sont à utiliser lors de la programmation.

Record

Posté par patrick_g (page perso, ) le 21/04/2009 à 18:28. (lien). Évalué à 10.

>>> cette dépêche a été initialement soumise le 18 décembre 2008, a attendu la sortie officielle de GCC 4.4, et à ce titre remporte le titre de dépêche restée le plus longtemps en modération

Ahahaha ! Avec une performance aussi titanesque que celle-là je ne risque pas d'être battu et j'emporterai le record dans ma tombe !

PS : Interdiction aux petits malins de poster dès demain une news sur la sortie de Debian Squeeze...ce serait de la triche pure et simple ;-)

Polyhèdre vs Polytope

Posté par ribwund () le 21/04/2009 à 19:14. (lien). Évalué à 3.

Pour la différence entre polyèdre et polytope ça dépend des écoles. On peut considérer les polytopes comme étant les polyhèdres bornés.

Par exemple: http://en.wikipedia.org/wiki/Polyhedron#General_polyhedra

Optimisations...

Posté par Christophe Merlet (page perso, ) le 21/04/2009 à 19:21. (lien). Évalué à 2.

Donc si je comprends bien, les optimisations ne sont pas activés par défauts :(

L'allocateur IRA utilise l'algorithme de Chaitin-Briggs au lieu Callahan-Koblenz ou Regional. J'ai pas bien compris :/

Et l'optimiseur de boucle GRAPHITE n'est pas non plus activé par défaut :(

En plus de ça, il me semble que la vectorisation du code n'est toujours pas automatique...

Jamais content

Posté par Sytoka Modon (page perso, ) le 21/04/2009 à 23:42. (lien). Évalué à 9.

Lorsque tu fait des grosses modifs comme cela, tu ne les mets pas obligatoire au début puis tu les rends pas défaut lorsqu'il y a du recul dessus.

Si tu commences à péter des gros projets parce que les options pas défaut ont trop changé, tu fait fuir les gens de ton projet. Si tu obliges les gens à modifier leur chaine de compilation car le compilateur merde car optimise trop, tu es mal. J'ai vu des codes de calcul qui donnent des résultats faux selon les paramêtres d'optimisation. Trop vouloir optimiser ne donnent pas toujours un résultat juste.

Je penses que tu n'as aucune conscience de la responsabilité et du stress que prennent les développeur de GCC a chaque version...

Distribs

Posté par Aurélien Bompard (Jabber id, page perso, ) le 22/04/2009 à 11:57. (lien). Évalué à 1.

Savez-vous quelles sont les distribs qui vont en disposer ?
Je ne suis au courant que pour Fedora, qui va bien avoir GCC 4.4 pour la prochaine version (F11).

BRAVO

Posté par Mehdi Saada (Jabber id, ) le 22/04/2009 à 15:16. (lien). Évalué à 1.

Pour tous le travail qu'ils ont fournis, merci beaucoup ;)
Ca a l'air balèze Graphite, franchement.
Espérons que cela ne va pas couler LLVM :-P, espérons qu'ils pourront réutiliser ce travail :-(.

Revenir en haut de page