Lancement du projet GlobalGCC

Posté par (page perso) . Modéré par Jaimé Ragnagna.
Tags :
0
2
nov.
2006
Technologie
Un consortium d'entreprise européennes vient de se former afin d'améliorer radicalement le compilateur libre GCC.

Dans le cadre de l'initiative ITEA (Information Technology for European Advancement), qui est soutenue par l'Union Européenne par l'intermédiaire de son programme de recherche Eureka, il a été décidé d'améliorer les performances du code produit par GCC.

Le projet, nommé GlobalGCC durera 30 mois.
Il sera financé pour environ un tiers par les gouvernements français, espagnol et suédois et le solde sera financé par des entreprises et des universités. Parmi ces dernières on peut noter Airbus, le CEA, l'INRIA, Telefonica ou MySQL.

Le projet sera dirigé par l'entreprise Mandriva. Techniquement le projet GlobalGCC va se consacrer à l'analyse globale d'un programme source afin de trouver des optimisations qui seraient impossibles à déceler par une analyse locale. Une grande amélioration du code généré est attendue au prix toutefois d'un ralentissement sévère de la phase de compilation (10 fois plus lent).

Du fait de cette analyse en profondeur du code source il sera également possible d'envoyer des diagnostics (warnings) plus précis lors de la compilation du source.

Évidemment GGCC restera sous licence GPL et les avancées techniques seront proposées pour inclusion dans la branche principale de GCC.

L'annonce de GlobalGCC a été effectuée sur la liste de diffusion de GCC et le message semble avoir été bien accueilli.
La seule inquiétude qui pouvait subsister est le risque de doublon avec le projet d'optimisation globale déjà envisagé par les développeurs GCC. Afin de les rassurer une promesse de synchronisation régulière avec GCC a été faite ainsi que la volonté de travailler avec les acteurs du libre : The GGCC (ITEA) consortium is determined to work in close cooperation with the GCC community and the FSF.

Aller plus loin

  • # mouais

    Posté par . Évalué à 10.

    > L'annonce de GlobalGCC a été effectuée sur la liste de diffusion de GCC et le message semble avoir été bien accueilli.

    Mouais, enfin d'après URL d'annonce, il y a eu 1 message sur la mailing list. on ne va pas dire que c'est l'enthousiasme général :-)

    Sinon, bonne initiative, reste à voir de quoi tout ça va accoucher :-)
    • [^] # Re: mouais

      Posté par (page perso) . Évalué à 10.

      >> il y a eu 1 message sur la mailing list. on ne va pas dire que c'est l'enthousiasme général

      Devant cette annonce sortie de nulle part et annonçant un projet pouvant être vu comme "concurrent" il aurait pu y avoir une avalanche de trolls. Cela n'a pas été le cas et c'est déjà très bien.
      J'attends quand même de voir comment va s'effectuer la synchro périodique avec GCC mainline avant de crier victoire.

      En tous cas cette annonce consacre vraiment la prééminence de GCC et ça c'est une excellente nouvelle.
  • # Une petite coquille ...

    Posté par . Évalué à 2.

    Une petite faute d'accord, sur la dernière ligne de l'encart :

    " Parmi ces dernières on peut noter ... "

    C'est peuT et non peuX.
  • # pilotage uniquement par mandriva ?

    Posté par . Évalué à 3.

    Bravo à Mandriva pour le pilotage, par contre, le développement se fera t'il de façon "libre", c'est à dire qu'il y aura une (ml|forum|bug tracker...) et un svn pour suivre presque en temps réel le développement et ce qu'il se dit ou décide, ou ils vont faire ça dans leur coin et donner le code à la fin ?

    J'imagine que c'est la 1° solution, mais si quelqu'un a une info sur ça, ça m'intéresse.
    • [^] # Re: pilotage uniquement par mandriva ?

      Posté par (page perso) . Évalué à 9.

      Bah la seule info c'est la phrase sur la mailing list qui annonce que :Sebastian volunteered to regularly sync from both mainline and the lto-branch.

      Donc je pense que ce ne sera pas un gros paquet de code qu'on écrit dans son coin et qu'on amène sous son bras 30 mois plus tard (qui à dit compiz ?). Les merge seront réguliers.
      Par contre je ne sais pas si le boulot se fera de façon ouverte en permanence (svn et autre).
    • [^] # Re: pilotage uniquement par mandriva ?

      Posté par (page perso) . Évalué à 10.

      Après NEPOMUK qui semble t'il a réellement démarré ( le développeur de k3b a été embauché par mandriva pour ce projet ) il semblerait que plusieurs projet européen de recherche sur les logiciels libres soient lancés et que mandriva ait la confiance des gouvernements pour mener ces projets.
      C'est une bonne chose il me semble. Espérons que ces projets arrivent a terme et ne soit pas que de simples annonces suivi de recherches fondamentales poussée ne débouchant sur rien de concret.
      • [^] # Re: pilotage uniquement par mandriva ?

        Posté par . Évalué à -4.

        Moi j'ai du mal à comprendre comment mandriva qui a du mal à ficeler une release en temps et en heure va pouvoir mettre des gens sur un projet aussi important... Je m'interroge vraiment et je me demande si ce n'est pas juste pour récupérer des crédits...
        • [^] # Re: pilotage uniquement par mandriva ?

          Posté par . Évalué à 2.

          FUD... Méconnaissance du sujet, etc...
          • [^] # Re: pilotage uniquement par mandriva ?

            Posté par . Évalué à 3.

            J'aimerais bien des explications alors si c'est possible comme ça il n'y aura plus de FUD...
            • [^] # Re: pilotage uniquement par mandriva ?

              Posté par . Évalué à 4.

              Ben justement, la 2007 est sortie à la date prévue, malgré une certaine inquiétude (il me semble) de la part des utilisateurs quant à son niveau de maturité.
              Il y a eu quelques soucis, mais dans l'ensemble ce lancement me parait bien plus réussi que celui de la 2006.

              Cette obstination à tenir le calendrier trouve peut-être là son explication....

              Quant au choix de mandriva, je ne vois pas d'autre société "européenne" qui fasse de la R&D sous linux et qui soit mieux placée...
              Il y avait Suse, mais elle appartient à novell maintenant.
            • [^] # Re: pilotage uniquement par mandriva ?

              Posté par . Évalué à -1.

              Ben justement, la 2007 est sortie à la date prévue, malgré une certaine inquiétude (il me semble) de la part des utilisateurs quant à son niveau de maturité.
              Il y a eu quelques soucis, mais dans l'ensemble ce lancement me parait bien plus réussi que celui de la 2006.

              Cette obstination à tenir le calendrier trouve peut-être là son explication....

              Quant au choix de mandriva, je ne vois pas d'autre société "européenne" qui fasse de la R&D sous linux et qui soit mieux placée...
              Il y avait Suse, mais elle appartient à novell maintenant.
        • [^] # Re: pilotage uniquement par mandriva ?

          Posté par (page perso) . Évalué à -1.

          tu dois être ubuntiste pour être aussi médisant..
          • [^] # Re: pilotage uniquement par mandriva ?

            Posté par (page perso) . Évalué à 1.

            :) eh eh jle suis mais c'est pas pour ca que je suis d'accord avec lui.
            Sinon en dehors de ces propos trollesque je trouve que l'implication de mandriva dans de gros projets est trés bien pour ces projets novateurs et pour mandriva qui devient une vitrine des technologies européennes.

            désolé pour le chauvinisme....

            ps: d'ailleurs j'hésite a passer a mandriva depuis la derniére version simplement par pur chauvinisme.....
  • # J'aimerai bien y croire...

    Posté par . Évalué à 10.

    ...mais, j'ai peur qu'au niveau communication ca ne soit pas idéal.

    http://gcc.gnu.org/ml/gcc/2006-09/msg00000.html

    Morceau choisi

    GCC itself is gearing up to start doing program wide analysis and optimization, and I guarantee you that if you guys go off and do it on your own in seclusion you will
    1. duplicate work
    2. make it incredibly hard to get your work back into gcc.


    Moi ce qui m'inquiete c'est : et qu'est-ce qu'il va se passer dans 30 mois ? dans le cas ou c'est fini ? (gcc integrera t'il ces modifs) et si c'est pas fini ?

    ne serait'il pas plus coherent de cooperer a l'actuel projet d'optimisation ?
  • # histoire de tiers...

    Posté par (page perso) . Évalué à 9.

    Il sera financé pour environ un tiers par les gouvernements français, espagnol et suédois et le solde sera financé par des entreprises et des universités. Parmi ces dernières on peux noter Airbus, le CEA, L'INRIA, Telefonica ou MySQL.


    On pourrait croire qu'il s'agit de financement 1/3 francais, 1/3 suédois, 1/3 espagnol, les entreprises financant des clopinettes.
    Dans la VO, c'est clair que c'est 30-40% part gouvernementale, et le solde par des entreprise. Donc pas des clopinettes.

    C'était juste pour la précision.

    Pour le commentaire : l'actionnaire militant que je suis est bien content de la dernière ligne de cette dépèche :-D
  • # Compilation lente

    Posté par . Évalué à 7.

    10 fois plus lent pour la compilation ! Il faudra un mois alors pour installer Gentoo?
    Plus sérieusement, j'espère que les optimisations seront à la hauteur du temps passé à les faire !
    • [^] # Re: Compilation lente

      Posté par . Évalué à 4.

      Justement, on avance une estimation du ralentissement de la compilation avant même que le projet ait commencé. C'est peut-être la limite qu'ils se sont fixés de ne pas dépasser.

      Et côté gain à l'exécution, des estimations ont-elles été faites ?

      --
      http://www.tessier-net.org
      • [^] # Re: Compilation lente

        Posté par (page perso) . Évalué à 2.

        si j'ai bien tout bien lu, l'objectif est finalement d'améliorer le temps d'éxécution, mais surtout de détecter des problèmes d'exécution dès la phase de compilation.
        du genre : une fonction F qui appelle une fonction G(x) = 1/f(x), ou on peut avoir f(x) qui vaut 0 à l'exécution. C'est l'exemple qui est donné, mais j'imagine qu'il doit y avoir pas mal de choses au niveau détection de failles potentielles à faire.

        L'amélioration de l'exécution, c'est plus mieux du point de vue affichage, mais l'amélioration de la qualité, ce sera plus mieux pour les geeks que nous sommes ;-)
        • [^] # Re: Compilation lente

          Posté par . Évalué à 2.

          Il y a des chances que les performances ne soient pas améliorées dans l'histoire, c'est sûr : les algorithmes de détections de ce type de propriétés ne se font pas forcément, du point de vue de la complexité algorithmique, aussi rapidement que les autres, sauf peut-être à rechercher des propriétés relativement triviales.

          Ils vont peut-être devoir changer d'ordre de grandeur l'algorithme, ce qui n'est à priori pas bon pour le temps d'exécution. Je pense pas que le "10x" soit significatif, ils donnent ça comme un vague ordre de grandeur dans la description du projet.
    • [^] # Re: Compilation lente <=> Analyse de flot

      Posté par (page perso) . Évalué à 10.

      Il est écrit dans l'article que l'optimisation sera globale et non plus locale.
      De quoi s'agit - il ?

      D'analyse de flot, très probablement.

      L'analyse de flot consiste à analyser toutes les branches d'exécutions du code, de produire un graphe de dépendances des données afin de détecter ce qui sera exécuté et ce qui ne le sera pas (qu'on appelle code mort).

      Typiquement, un objet C hérite de A et B, or dans le code on exécute que C.méthode(), B.méthode(), mais jamais A.méthode()

      A.méthode() est donc du code mort à ne pas inclure dans le code finale et à ne pas tester à (l'eventuelle) résolution dynamique de branche.

      Une analyse de flot peut être plus ou moins profonde. Ainsi une analyse très profonde peut être munie d'un moteur logique qui va par exemple détecter qu'une variable n est forcément pair (n := n*2;) et 10 km plus loins que l'on teste sa parité.
      Le moteur logique vire le test, ayant déduit qu'il ne sert à rien.

      Tout ceci permet d'optimiser avec bonheure toute sorte de choses faisable jusqu'ici par un humain mais rendant le code très vite illisible et inmaintenable.

      Ce genre d'algorithme est passeblement exponenentielle et est surtout très gourmand en mémoire.
      Lisaac qui est pour le moment le seul compilateur objet à implémenter ce type d'algorithme (oui je sais, prosélytisme), utilise environ 256 à 512 Mo pour compiler 50 000 lignes (pour 90 secondes de compilation sur une bonne machine).

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Compilation lente <=> Analyse de flot

        Posté par . Évalué à 4.

        D'accord avec toi, sauf que l'analyse de flot ne permet pas seulement à mon avis de détecter du code mort, mais aussi de détecter les erreurs potentielles, cf l'exemple de la division par 0 donné plus haut.

        Question plus technique : c'est quoi qui bouffe de l'espace dans Lisaac ? les propriétés trouvées (genre n pair), qu'on est obligé de garder parce qu'on sait pas si elles serons utiles ou pas ? (question naïve sans doute, j'y connais pas grand chose) ? Je pense pas que le graphe de flot en lui même prenne autant de place ... ? Le moteur d'inférence ?
        • [^] # Re: Compilation lente <=> Analyse de flot

          Posté par (page perso) . Évalué à 6.

          c'est quoi qui bouffe de l'espace dans Lisaac ?
          D'après ce que j'ai compris de ce que m'a expliqué Benoit, c'est le graphe de dépendance, ou graphe de flot qui prend de la place en mémoire.

          Faut pas oublier que Lisaac est pas un compilateur procédural mais objet.
          En procédural, tu as deux dimensions : la variable globale et la variable locale.
          En objet tu as la variable globale, locale, et l'objet en question (on peut instancier autant de fois qu"on veut), ça monte donc très très vite (les sous graphes se dupliquent très vite...).
          Lisaac est un compilateur qui traduit ton code dans un langage élémentaire rassemblant , si je ne me trompe pas, les primitives suivantes :

          Read
          Write
          Switch (branchement)
          soustraction
          multiplication
          division
          and
          or
          test =
          >

          Avec ça, il optimise tout, et reconstitue du C...

          Sachant que la conditionnelle est défini dans la librairie pour être justement traduite dans ce mini langage, tu imagines bien que la granulité étant très fine, on arrive très vite à des graphes très volumineux. Prenons un simple

          a,b : STRING;
          a := STRING.create 64;
          b := STRING.create 64;
          a := "Esope reste ici".to_string;
          b := " et se repose\n".to_string;
          (a+b).print;

          Là dedans, à part la primitive print, et les chaînes qu'on retrouvera tels quels dans le source C produit, ca fait déjà un beau graphe quand tu utilises des primitives aussi fines que celles décrites plus haut...
          STRING est déjà un gros objet qui utilise lui même une cascade de code (gestion mémoire, initialisation, opération +, etc...).


          Ya la gestion des contrats qui prend énormément de place aussi, car les contrats sont propagés dans tout le code.

          Quand au moteur d'inférence, il fut implémenté (en 2001), mais mangeait 4 Go de mémoire pour 500 lignes de code (hors librairie), ils arrivaient à faire planter le calculateur du Loria avec, à l'époque (vers 2001).
          C'est en réduisant la profondeur de l'analyse de flot que Lisaac est devenu réalité.

          Un des principaux travaux de recherche des prochains mois de notre ami (maintenant qu'il a enfin un poste) va consister à réimplémenter une analyse profonde dans le compilateur, avec pour but d'améliorer la sécurité et la prise en charge des contrats, prouver le langage interne, etc...

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Compilation lente <=> Analyse de flot

            Posté par . Évalué à 3.

            Il doit me manquer un truc, parce là je comprends pas ce qui peut faire exploser la taille.

            Genre pourquoi il y a duplication des sous-graphes ? à priori il suffirait de faire un arc d'un graphe vers un autre pour un appel de fonction par exemple, sans rien dupliquer du tout. Un genre d'inlining dans le graphe ? Les boucles qui sont déroulées si possible ? Il y a peut être des trucs du genre SSA (Single assignment si je me trompe pas), création d'une variable à chaque affectation ?

            D'autre part, je vois pas pourquoi l'instanciation des objets ferait augmenter la taille du graphe, dans un langage classique à priori c'set juste l'instanciation de la mémoire et l'appel au constructeur (en simplifiant), pas de quoi exploser, donc. C'est en rapport avec le modèle par prototype, peut-être ? Comment les objets interviennent dans ce graphe ?

            Pour la granularité, l'assembleur par exemple à une granularité très fine, et pourtant on a pas des exécutables de 512 megs ?
            • [^] # Re: Compilation lente <=> Analyse de flot

              Posté par . Évalué à 4.

              Bon je ne connais pas Lissac, mais il me semble que dans un compilateur faisant des optimisations globales, tu prends en compte tous les chemins possible, donc a chaque *if* tu as deux possibilités, et la combinatoire des chemins possible explose.

              C'est pour la phase d'optimisation que l'utilisation mémoire explose, la taille des binaires générée n'est pas impactée.
            • [^] # Re: Compilation lente <=> Analyse de flot

              Posté par . Évalué à 4.

              Genre pourquoi il y a duplication des sous-graphes ? à priori il suffirait de faire un arc d'un graphe vers un autre pour un appel de fonction par exemple, sans rien dupliquer du tout.

              Normalement, le but de l'analyse de flot est d'annoter les variables avec des propriétés décrivant leurs valeurs possibles. Pour cela on déroule le programme de toutes les façons possibles. Il y a théoriquement un jeu complet d'annotations séparées par façon de dérouler le programme, même si on peut factoriser. De plus, les annotations doivent être le plus fines possibles (par exemple l'intervalle de valeurs que peut prendre un entier).

              Un noeud dans un tel graphe n'est pas une fonction, mais un bloc de code, ainsi l'intérieur d'un "if" est un noeud indépendant. Mettons que tu as le fragment de code suivant :

              /* bloc A */
              if (cond) {
              /* bloc B */
              }
              /* bloc C */

              Alors le fragment de graphe correspondant comprendra trois noeuds A, B, C, et des arcs A->B, B->C et A->C. L'arc A->B sera annoté avec "cond" et l'arc A->C avec "not cond".

              On comprend vite que sur un programme ou sous-programme non-trivial, la combinatoire est explosive.
              • [^] # Re: Compilation lente <=> Analyse de flot

                Posté par . Évalué à 2.

                On comprend vite que sur un programme ou sous-programme non-trivial, la combinatoire est explosive.


                Pas moi en tout cas : sur ton exemple, on a 3 blocs de codes, et 3 noeuds et 6 arcs, en O(2*n) en fonction du nombre de ligne de code au pire, linéaire donc.

                Si ce schéma est imbriquée dans d'autres structures, il ne sera pas reproduit dans mon idée des graphes de flots en tout cas.

                bloc A'
                while ( cond1) do
                /* Ton bloc if */
                done
                bloc B'

                ca rajoute deux noeuds, 3 arcs, c'est tout.

                Je vois donc pas ce qui peut êxploser de ce côté, sauf si il y a reproduction de ces structures quand ce sont des fonctions, genre inlining en C++.

                Donc je crois pas que le graphe en soit bouffe tant d'espace.

                L'analyse de flot, qui est censée traiter tous les chemins possibles c'est évidemment différent. Dites moi si (où sûrement ;) ) je me trompes.
                • [^] # Re: Compilation lente <=> Analyse de flot

                  Posté par (page perso) . Évalué à 3.

                  Dans une analyse de flot profonde, on étudie non pas le graphe du code, mais le graphe des exécutions possible du code, comme l'expliquait Antoine et Reno. La combinatoire explose donc très vite.

                  Avec un code du style

                  Bloc A
                  if (cond1)
                  _ if (cond2)
                  _ Bloc C
                  _ else
                  _ Bloc C'
                  else
                  _ Bloc A''
                  end if
                  Bloc B

                  Dans ce genre de cas (fréquent), tu cherches à analyser l'ensemble des intervales de valeur dans lesquels peuvent se trouver tes variables (n'oubli pas que ton code est réduit selon les primitives que j'ai donné plus haut), en effet, il faut faire des suppositions sur les chemins d'exécution pour détecter ceux qui ne seront jamais pris, malgré les apparences.

                  Avec deux boucles imbriqués, tu dois tester le devenir de toutes les variables du bloc A en fonction des branchements sur cond1,cond2.
                  En d'autres termes, à cause de ces deux if imbriqués, tu es obligé de représenter 4 évolutions possible des variables du bloc A, afin de détecter les intervals possibles, etc..
                  Posons par exemple que tu déclares une variable n := n*2+1 dans le bloc A...
                  Tu as 4 évolutions possible de cette variable n, qui peuvent avoir des conséquences dans le code. Ce qui signifie que tu dois (si n est modifié dans plus d'une des 4 branches de test) représenter toute la suite du graphe orienté en 4 versions (!).

                  Imagine quand tu as 5, 20, 50 niveau de test imbriqués avec des énormes blocs de code à l'intérieur... Ta combinatoire explose.

                  Ai-je été clair ? :)

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                  • [^] # Re: Compilation lente <=> Analyse de flot

                    Posté par . Évalué à 2.

                    Hum, je suis pas sûr de ça, le graphe en lui même à pas nécessairement besoin d'être changé AMHA, seules les valeurs des variables (des intervalles si c'est traîté comme ça) ont besoin d'être modifiées en fonction des cas rencontrés.

                    Bon, ok il reste clairement une exponentielle là dedans, mais je comprends pas pourquoi elle est nécessairement dans le graphe lui même.
                    D'ailleurs, ici on a pris le cas des conditionelles, qui est simple, mais on fait comment dans le cas des boucles ? on déroule tout au fur et à mesure ? on peux pas savoir "à priori" combien on devra en dérouler, si on construit au fur et à mesure, ni même si l'algo se termine dans le cas de boucles potentiellement infinies.
                    • [^] # Re: Compilation lente <=> Analyse de flot

                      Posté par (page perso) . Évalué à 2.

                      Ne pas oublier l'implications de changement de valeur de variable sur quelques centaines de lignes de code. Ne pas oublier non plus que ce n'est pas tellement le graphe du code qui bouffe de la mémoire, mais toutes les informations sur celui-ci (graphe de dépendances, intervales possibles de valeurs de variables, etc...)

                      Quand au boucle, elles reviennent à un if avec un goto.

                      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Compilation lente

      Posté par . Évalué à -1.

      Il fera pas bon d'être un p'tit pentium III...
  • # On est vendredi ou bien ?????

    Posté par (page perso) . Évalué à -10.

    Mandriva... Vu ce que j'ai comme barre de marques pages sur Firefox, je croyais qu'ils compilaient tout avec le compilateur d'Intel :)

Suivre le flux des commentaires

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