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.
# mouais
Posté par Putifuto . Évalué à 10.
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 patrick_g (site web personnel) . Évalué à 10.
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 Gédéon . Évalué à 2.
" Parmi ces dernières on peut noter ... "
C'est peuT et non peuX.
# pilotage uniquement par mandriva ?
Posté par Ludovic Gasc . Évalué à 3.
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 patrick_g (site web personnel) . Évalué à 9.
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 marseillais (site web personnel) . Évalué à 10.
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 rewind (Mastodon) . Évalué à -4.
[^] # Re: pilotage uniquement par mandriva ?
Posté par kowalsky . Évalué à 2.
[^] # Re: pilotage uniquement par mandriva ?
Posté par rewind (Mastodon) . Évalué à 3.
[^] # Re: pilotage uniquement par mandriva ?
Posté par Ant . Évalué à 4.
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 rewind (Mastodon) . Évalué à 3.
Initial date: 2006.09.15
Estimated date: 2006.10.02
15 jours de retard...
Et le problème que je soulève n'est pas un problème de choix, je suis très content qu'une société, française qui plus est, fasse ce choix là. Je me pose simplement la question des moyens qui seront réellement derrière.
[^] # Re: pilotage uniquement par mandriva ?
Posté par Juke (site web personnel) . Évalué à 0.
[^] # Re: pilotage uniquement par mandriva ?
Posté par Ant . Évalué à -1.
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 Troy McClure (site web personnel) . Évalué à -1.
[^] # Re: pilotage uniquement par mandriva ?
Posté par marseillais (site web personnel) . Évalué à 1.
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 fabien . Évalué à 10.
http://gcc.gnu.org/ml/gcc/2006-09/msg00000.html
Morceau choisi
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 Paul POULAIN (site web personnel) . Évalué à 9.
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 espace . Évalué à 7.
Plus sérieusement, j'espère que les optimisations seront à la hauteur du temps passé à les faire !
[^] # Re: Compilation lente
Posté par Gael Tessier . Évalué à 4.
Et côté gain à l'exécution, des estimations ont-elles été faites ?
--
http://www.tessier-net.org
[^] # Re: Compilation lente
Posté par Paul POULAIN (site web personnel) . Évalué à 2.
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 Thomas Douillard . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 10.
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 Thomas Douillard . Évalué à 4.
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 Ontologia (site web personnel) . Évalué à 6.
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 Thomas Douillard . Évalué à 3.
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 reno . Évalué à 4.
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 Antoine . Évalué à 4.
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 Thomas Douillard . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 3.
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 Thomas Douillard . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 2.
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 tuxsmouf . Évalué à -1.
# On est vendredi ou bien ?????
Posté par djibb (site web personnel) . Évalué à -10.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.