Sur le site d'Onversity on peut lire (en français !) un article très intéressant sur le futur de ce compilateur.
Trois branches de développement sont évoqués successivement : la branche 3.3.X qui est l'actuelle et qui se limitera à des corrections de bugs, la branche 3.4.X qui sortira dans quelques mois et qui est consacrée à la vitesse de compilation, et la branche 3.5.X qui verra une refonte majeure de l'architecture de GCC afin de rattraper le retard sur ICC (le compilateur Intel qui se limite aux architectures IA-32 et IA-64). En fin d'article on trouve sur Onversity un lien vers un document au format pdf qui regroupe l'ensembles des contributions du GCCsummit 2003 (attention car c'est :
1) en anglais
2) un pdf d'1.4 Mo
3) sacrément technique).
Aller plus loin
- Article d'Onversity (3 clics)
- PDF du sommet GCC (1 clic)
- Annonce de GCC 3.3.2 (DLFP) (2 clics)
# Re: Le futur de GCC se dévoile !
Posté par shbrol . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par Ice Lion . Évalué à 4.
je pense qu'à terme, "export" sera sûrement retiré de la norme : trop casse-tête.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 3.
cela dit export est assez polémique, non pas à cause de son coût de mise en oeuvre, mais à cause de son approche du problème
[^] # Re: Le futur de GCC se dévoile !
Posté par yoho (site web personnel) . Évalué à 0.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par arnaudus . Évalué à 1.
... ça marche pour les fonctions inline aussi.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 5.
# Re: Le futur de GCC se dévoile !
Posté par Stéphane Traumat (site web personnel) . Évalué à 5.
Au risque de me faire taper dessus, je trouve l'expression 'quasi-totalité' des logiciels libres un peu éxagérée
il existe quand même un paquet de logiciels libres qui sont ni en C, ni en C++.
http://about.me/straumat
[^] # Re: Le futur de GCC se dévoile !
Posté par Fred . Évalué à 8.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 5.
[^] # Re: Le futur de GCC se dévoile !
Posté par xsnipe . Évalué à -2.
[^] # Re: Le futur de GCC se dévoile !
Posté par Lionel Draghi (site web personnel) . Évalué à 1.
Pour être précis, "langage écrit en C" ne veut pas dire gand chose.
Si tu veux dire que le compilateur génère du C qui est ensuite compilé par gcc, je pense que c'est faux.
Si tu veux dire que le compilateur est en partie écrit en C, alors je dirai que c'est vrai au moins pour le backend de gcc, que tous partagent.
Mais notes que ce n'est pas forcément le cas de tout le compilateur : par exemple les frontend Ada ou VHDL sont écrit en Ada.
[^] # Re: Le futur de GCC se dévoile !
Posté par bmc . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par Larry Cow . Évalué à 1.
C'est oublier les projets en ObjC (bon ok, c'est gcc aussi)
Je sors, alors...
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 3.
[^] # Re: Le futur de GCC se dévoile !
Posté par Moby-Dik . Évalué à 3.
C# Compiler :
- Self hosting on Linux
- Self hosting on .NET. »
Donc voilà, Mono est self-hosting, c'est libre et ce n'est pas gcc ;)
http://www.go-mono.org/(...)
[^] # Re: Le futur de GCC se dévoile !
Posté par ndv . Évalué à 6.
en gros, ils aimeraient vraiment que le C# de Mono, écrit actuellement en C# de Microsoft, puisse être compilé par gcc (un peu comme gcj). Mais ils ont d'autres priorités actuellement (recoder une partie du framework .NET si j'ai bien compris), si bien qu'ils aideront au maximum ceux qui voudraient le faire à leur place, mais ils ne le feront pas seuls.
[^] # Re: Le futur de GCC se dévoile !
Posté par Ice Lion . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par Adrien Bourdet . Évalué à 0.
donc comme expliqué ci-dessus, il n'y a pas que C et C++...
Sinon, OpenOffice, c'est GCC ou VisualStudio ? ;)
[^] # Re: Le futur de GCC se dévoile !
Posté par Stéphane Traumat (site web personnel) . Évalué à 0.
http://about.me/straumat
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à -3.
[^] # Re: Le futur de GCC se dévoile !
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Si la JVM java est écrit avec GCC, je serais surpris
http://about.me/straumat
[^] # Re: Le futur de GCC se dévoile !
Posté par Ice Lion . Évalué à 2.
$ ldd /usr/lib/j2se/1.3/bin/i386/native_threads/java* | grep libc
libc.so.6 => /lib/libc.so.6 (0x40035000)
libc.so.6 => /lib/libc.so.6 (0x4015b000)
Donc, même si le compilo ou la MV Java est amorcée en Java, in fine la plupart du temps l'environnement est interfacé à l'OS via une libc, qui se trouve majoritairement être celle de GCC dans les projets LL.
[^] # Re: Le futur de GCC se dévoile !
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Le futur de GCC se dévoile !
Posté par patrick_g (site web personnel) . Évalué à 6.
By language
C 861,000 53%
Ada 298,000 18%
MD 170,000 10%
Java 127,000 8%
C++ 105,000 6%
Other 78,000 5%
vous aviez compris que c'est en nombre de ligne (ce qui permet de voir que GCC c'est gros !.
sinon c'est quoi MD ?
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par patrick_g (site web personnel) . Évalué à 2.
scuse.....
c'est quand même très très gros non ?
plus de 1.6 millions de lignes (sans compter les commentaires) !
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à -1.
cela dit t'es sur de tes stats ? tu as fais avec sloccount ?
[^] # Re: Le futur de GCC se dévoile !
Posté par patrick_g (site web personnel) . Évalué à 1.
j'ai trouvé ça dans le pdf du sommet GCC-2003 donné en lien plus haut (c'est dans le dernier article qui concerne la maintenance du code).
ce sont donc les chiffres officiels et moi je persiste à trouver ça gros....il n'est pas légitime de comparer avec un kernel monolithique comme linux !
maintenant c'est vrai que vu tout les algos d'optimisations+toutes les architectures cibles+tous les langages supportés ça ne peut qu'être massif.
[^] # Re: Le futur de GCC se dévoile !
Posté par Moby-Dik . Évalué à 1.
Machine Description peut-être ?
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à -2.
[^] # Re: Le futur de GCC se dévoile !
Posté par Moby-Dik . Évalué à 2.
[^] # Re: Le futur de GCC se dévoile !
Posté par Gwenole Beauchesne . Évalué à 4.
[^] # Re: Le futur de GCC se dévoile !
Posté par iouri . Évalué à 1.
Ou alors, c'est un bug, car les binaires finaux ne devraient dépendre que du source du programme en FOO et du source du compilo FOO.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 3.
Quand à tous les autres logiciels compilés à l'aide d'un compilateur avec une partie arrirèe gcc, ils seront sans doute plus performants car plus optimisés, à défaut, ils seront compilés en moins de temps
[^] # Re: Le futur de GCC se dévoile !
Posté par fabien . Évalué à 2.
Faux, en modifiant le compilo, tu modifies aussi les binaires : optimisation, implementation differente...
je me rappelle d'un prof qui racontait (en cours de compilation, oui j'ai eut un cours qui s'appellais "compilation") que une fois un compilo fait, en general on le recompile avec lui même... c'est donc que ca sert a qqchose...
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 8.
le terme de bootstraping est mieux, parce qu'il a une petite histoire. Le Baron de Munchausen était tombé dans des marais, il était empétré. Pour s'en sortir, il s'est tiré par sa queue de cheval, et par les languettes de ses bottes (bootstrap)
[^] # Re: Le futur de GCC se dévoile !
Posté par benja . Évalué à 3.
> Faux, en modifiant le compilo, tu modifies aussi les binaires : optimisation, implementation differente...
Je crois qu'il voulait dire que si gcc est bien fait, le fait de l'améliorer ne devrait pas changer le fonctionnement des binaires obtenus. Ainsi un compilateur écrit en C compilera toujours le même code de la même façon peu importe avec quel compilateur C il a été compilé.
Donc il n'y a pas de raison pour que les performances des autres languages soient boostés parceque la partie C de gcc s'améliore. Mais ils peuvent compiler plus vite en profitant de ces améliorations (gcc3 est très lent, les gars d'OpenBSD avait envisagé (envisagent toujours?) de passer à tendra qui est un compilo en licence bsd http://www.tendra.org/(...) )
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par benja . Évalué à 0.
Si je remonte de 2 posts, tu écris: "pas en général, tout le temps. ça s'appelle le bootstraping, ou auto-compilation." Il faudrait alors que tu m'explique en quoi mon exemple est "idiot"...
[^] # Re: Le futur de GCC se dévoile !
Posté par renoo . Évalué à 4.
# Re: Le futur de GCC se dévoile !
Posté par Johan Denoyer (site web personnel) . Évalué à -3.
[^] # Re: Le futur de GCC se dévoile !
Posté par patrick_g (site web personnel) . Évalué à 2.
la 3.4 aura les features de la 3.3 et la 3.5 aura celles de la 3.4.
les versions successives se basent sur le code des précédantes et il n'y à pas de raison de demander une 3.6 qui regroupe tout.
bien sûr ceci est AMHA.
# Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 1.
à moins que cela ne soit implicitement une réfrence à export, ou une facilité d'utilisation accrue de -frepo ...
[^] # Re: Le futur de GCC se dévoile !
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à -1.
[^] # Re: Le futur de GCC se dévoile !
Posté par Fabimaru (site web personnel) . Évalué à 2.
Je trouve ça un peu laid, mais c'est mieux que rien et personne ne l'oblige à l'utiliser.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 4.
moi je suis pour la précompilation, tant qu'on reste avec du code le plus standard possible. j'ai pas envie de me taper un "stdafx.h" magique. je veux que ça soit transparent
[^] # Re: Le futur de GCC se dévoile !
Posté par Troy McClure (site web personnel) . Évalué à 1.
Tu peux détailler un petit peu ?
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 7.
imagine que tu bosses sur un truc, ou tu manipules quasiment partout des My::collection, le long de tes 500 .cpp . si tu t'amuses à faire des #include <collection.hpp> dans chaque fichier : ton temps de compilation explose, la taille de ton binaire aussi. Sans compter que si tu modifies 1 octet de ton template, ton projet entier recompile (use scons d'ailleurs). il faut recourir à une instanciation explicite pour régler ce genre de problème. ça a l'air con, mais ce genre de bêtises, c'est typiquement le truc que font systématiquement les mecs qui te sortent « les templates ça pue, les temps de compilations explosent »
export permettraient de résoudre ce genre de problème, g++ -frepo est un début de solution, une instanciation explicite séparér à la main est envisageable de temps en temps, pour les types de bases au moins ... mais dans tous les cas il faut être conscient de ce qui se passe en fixer des limites
je te conseille l'excellent http://www.josuttis.com/tmplbook/index.html(...)
[^] # Re: Le futur de GCC se dévoile !
Posté par harbort . Évalué à 4.
Disons que si tu utilises tes propres templates, ce que tu dis fait sens, et c'est même assez raisonnable (même si du coup on perd un peu l'intérêt des templates mais bon).
Par contre, l'utilisation d'une bibliothèque externe en template interdit pratiquement ce que tu dis ! Si tu veux un exemple concret, prend boost (www.boost.org) et utilise-le un peu (c'est du logiciel libre alors te prive pas). Par exemple, avec Boost.Python, tu peux exporter des classes C++ en python, et c'est tout en template ! Ben tu verras que faire ce que tu dis (en fait c'est automatique : tu instancies un template pour chaque classe exportée, et donc chaque instance du template n'existe qu'une seule fois) n'arrange rien et les temps de compilation / édition des liens sont hallucinant ! Pour compiler mon 'petit' programme (ie. 20 000 lignes max) il me faut environ 40 min. et je passe tout mon temps dans l'édition des liens pour mes bibliothèques d'exportation de mes classes ... De plus (à cause d'un pb de gcc) la mémoire consommé, lors de la compilation cette fois, atteint régulièrement les 400-500 Mo et encore c'est après un découpage de mes fichiers objets en plusieurs fichiers ...
Enfin, tout ça pour dire qu'une amélioration de la gestion des templates est vraiment nécessaire ... et que j'espère vraiment qu'elle va arriver !
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par Troy McClure (site web personnel) . Évalué à 1.
Sinon (sans rapport) le compilo en question, même sans repository, est 4 ou 5 fois plus rapide que g++ pour les compilations (mais j'ai l'impression qu'il est moins performant pour les optimisations).
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par Philippe F (site web personnel) . Évalué à 2.
Finalement, je crois que je prefere des macros bien crades que des template. D'une part, c'est beaucoup plus portable. D'autre part, tu as beaucoup moins d'emmerdes de compilation. Surtout qu'une erreur de template te crache un lignes de 1000 caracteres minimum. Ca aide pas beaucoup pour s'y retrouver.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 0.
[^] # Re: Le futur de GCC se dévoile !
Posté par Philippe F (site web personnel) . Évalué à 6.
Sous cygwin, gcc et g++, c'est gentil mais c'est hyper lent. Multiplie environ par 10 le temps de compilation d'un projet. Probleme bien connu de cygwin, peut-etre a cause de la simulation des droits posix sur un systeme de fichier win32.
Meme en comparant ce qui parait comparable (linux/gcc et windows/visual), visual compile nettement plus vite, de l'ordre de x2 ou x3 (template ou pas template). Et je n'ai pas utilise des headers precompiles.
Sinon, c'est vrai que Visual est plutot pourri dans sa gestion des template. Cote compilateur lui-meme, ca a pas l'air trop genant dans mon projet modeste, mais il ne faut surtout pas oublier d'installer les service pack.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par renoo . Évalué à 1.
[^] # Re: Le futur de GCC se dévoile !
Posté par harbort . Évalué à 3.
Enfin bon ... je m'en passe ! Pour répondre à un autre post, pour l'explosion de la taille du binaire c'est essentiellement du au fait que le code est dupliqué pour chaque structure de donnée et, mine de rien, ça finit par être énorme !!!!
Par exemple, toujours pour mon projet de moins de 20.000 lignes de code, après compilation avec les options de débogage mon répertoire occupe plus de 300 Mo !!!! Les bibliothèques + exécutables occupent eux environ 100 Mo. Pour une version sans le debug, si je me souviens bien ça tournait quand même autour de 10 ou 20 Mo, ce qui est déjà énorme pour un programme de cette taille ! (mais ça serait à confirmer)
[^] # Re: Le futur de GCC se dévoile !
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Ah, tu veux dire que le code est instancié pour chaque type différent avec lequel tu l'utilises ? Oui, bien sur, c'est le but des templates :-). Il y a parfois des moyens pour limiter ça (par exemple en remplaçant le template par une classe manipulant des void*, et en ne gardant en template que l'interface qui ne fait que caster autour des methodes de la classe), mais il est vrai que cela reste un problème inhérent à la fonction des templates... Si tu veux les utiliser, tu payes, comme pour toute feature un peu évoluée.
[^] # Re: Le futur de GCC se dévoile !
Posté par TazForEver . Évalué à 1.
ok pour la classe d'implémentation générique
par contre, quand tu compiles avec un modèle d'inclusion, tes fichiers objets sont énormes parce qu'ils ont tous le code du template instancié. si ton linker est intelligent, il supprime les doublons. donc au final on ne sent rien. ce que je voulais dire précédemment, c'est que les tailles des objets binaires explose et que le linker en prends plein la tête ...
[^] # Re: Le futur de GCC se dévoile !
Posté par gourgou . Évalué à 1.
Tu veux dire, mis à part le temps de compil (1) en multiples exemplaires du code des fonctions templates et le temps de tri par le linker (qui sera généralement fait de façon simpliste et donc, à défaut d'être coûteux en temps, risque de laisser planer des erreurs) ?
(1) Enfin en même temps, tant qu'on a pas un compilo qui parse correctement les définitions de templates, je vois pas pourquoi on se prend la tête à causer des temps et modèles de compil ou d'organisation de code...
[^] # Re: Le futur de GCC se dévoile !
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Pourquoi la taille du binaire exploserait-elle ? Le linker fait le tri et ne mettra dedans qu'une seule instantiation. Et include la def de tes templates est la "bonne" façon de les utiliser, d'après la doc de gcc. Si je me souviens bien, '-frepo' est complètement obsolète.
# Re: Le futur de GCC se dévoile !
Posté par reno . Évalué à 3.
Alors récent? Euh, pas tant que ça..
[^] # Re: Le futur de GCC se dévoile !
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Le futur de GCC se dévoile !
Posté par Moby-Dik . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.