Articles précédents : Logiciel
- [97] FreeBSD 4.9 est sortie
- [214] KDE : On ferme ! (les bugs)
- [15] ASLR pour le noyau 2.6
- [7] Sortie de Swish-e 2.4
- [31] Première version packagée de CPS3
- [22] Premiers firmwares Ogg Vorbis
- [45] Sortie de RTAI 24.1.12
- [180] Entente tumultueuse entre Linux et lecteurs LG
- [56] PHP-GTK en v1.0.0
- [60] La commission européenne et les logiciels libres
Liens connexes
- Article d'Onversity (2939 hits)
- PDF du sommet GCC (599 hits)
- Annonce de GCC 3.3.2 (DLFP) (652 hits)
Dépêche modérée par
Logiciel : Le futur de GCC se dévoile !
Posté par patrick_g (page perso, ). Modéré le 29 octobre 2003.
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).
![[fr]](../../../images/fr.png)
Article d'Onversity (2939 hits)![[en]](../../../images/en.png)
PDF du sommet GCC (599 hits)-
Annonce de GCC 3.3.2 (DLFP) (652 hits)
> Lire la suite (67 commentaires, moyenne: 2). [dépêche : 224 caractères]
1) en anglais
2) un pdf d'1.4 Mo
3) sacrément technique).
Re: Le futur de GCC se dévoile !
Rien vu sur 'export' pour le C++ (mais je n'ai lu que l'article d'Onversity, et encore en diagonale). Peut être dans GCC-4.0 ?
-
[^]Re: Le futur de GCC se dévoile !
Posté par Ice Lion (page perso, ) le 29/10/2003 à 14:29. (lien). Évalué à 4.quel compilo supporte "export" ? Comeau je crois, et encore, pas complètement (et pour cause :).
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 () le 29/10/2003 à 14:55. (lien). Évalué à 3.non pas retiré, proposé comme une extension, pas imposé.
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 (page perso, ) le 29/10/2003 à 15:54. (lien). Évalué à 0.Euh c'est quoi export ? c'est comme extern ?
-
[^]Re: Le futur de GCC se dévoile !
Posté par TazForEver () le 29/10/2003 à 16:13. (lien). Évalué à 1.un mot clef pour séparé définition et déclaration de template. c'est un problème volumineux. documente toi, apprends le C++. rien à voir avec extern
-
[^]Re: Le futur de GCC se dévoile !
Posté par arnaudus () le 30/10/2003 à 08:05. (lien). Évalué à 1.un mot clef pour séparé définition et déclaration de template
... ça marche pour les fonctions inline aussi.-
[^]Re: Le futur de GCC se dévoile !
Posté par TazForEver () le 30/10/2003 à 10:28. (lien). Évalué à 5.non, pas que je sache. la sémantique d'une fonction inline est très précise. Pour pouvoir faire l'insertion sur place, le compilateur a besoin du code (sauf certains compilo, mais là ça coute tres cher ce genre de bidule) j'ai pas vocation à faire un cours ici, mais contrairement, la compilation d'une unité de traduction qui utilise un template n'a nullement besoin de sa définition. export est là pour que l'on puisse séparer définition et déclaration en s'affranchissant du problème d'instanciation
-
-
-
-
-
Re: Le futur de GCC se dévoile !
"GCC est le compilateur libre utilisé par GNU/Linux et la quasi-totalité des logiciels libres."
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++.
-
[^]Re: Le futur de GCC se dévoile !
Posté par Fred (page perso, ) le 29/10/2003 à 14:31. (lien). Évalué à 8.Je ne suis certainement pas le mieux placé pour répondre, mais il me semble que GCC n'est pas qu'un compilateur c et c++ mais gère bien d'autres languages de programmation tel pascal, ada, etc...
-
[^]Re: Le futur de GCC se dévoile !
Posté par TazForEver () le 29/10/2003 à 16:15. (lien). Évalué à 5.suffit de regarder le premier lien pour constater que la partie arrière de gcc s'interface avec une multitude de parties avants
-
-
[+] [^]Re: Le futur de GCC se dévoile !
Posté par xsnipe () le 29/10/2003 à 14:43. (lien). Évalué à -2.Peut-etre mais les langages dont tu veux parler sont eux-meme écrit en C...
--
Debian ... gentoo moi ça et vite :)-
[^]Re: Le futur de GCC se dévoile !
Posté par Lionel Draghi (page perso, ) le 29/10/2003 à 21:58. (lien). Évalué à 1.| Peut-etre mais les langages dont tu veux parler sont eux-meme écrit en C...
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 () le 29/10/2003 à 14:44. (lien). Évalué à 1.Certes, tous les logiciels libres ne sont pas en C ou C++, mais la plupart des logiciels libres utilisant un langage compilé, donc un compilateur, sont en C ou C++. Enfin, je pense...
-
[^]Re: Le futur de GCC se dévoile !
-
[^]Re: Le futur de GCC se dévoile !
Posté par TazForEver () le 29/10/2003 à 15:02. (lien). Évalué à 3.bah si tu utilises un langage non compilé, ton interpréteur il faut bien qu'il soit codé en quelque chose. si bien que tout le monde en profite.
-
[^]Re: Le futur de GCC se dévoile !
Posté par Moby-Dik () le 29/10/2003 à 15:21. (lien). Évalué à 3.« Mono Status :
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 (Jabber id, ) le 29/10/2003 à 16:41. (lien). Évalué à 6.A ce sujet, on trouve la position officielle de Ximian sur son site :
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 (page perso, ) le 29/10/2003 à 14:47. (lien). Évalué à 1.certes, mais même parmi ceux-ci, une large majorité repose in fine sur la libc
-
[^]Re: Le futur de GCC se dévoile !
Posté par Adrien Bourdet () le 29/10/2003 à 15:08. (lien). Évalué à 0.c'est GNU Compiler Collection, et plus GNU C Compiler,
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 (page perso, ) le 29/10/2003 à 16:09. (lien). Évalué à 0.Beaucoup de projets libres sont en Java, PHP, Delphi, Python... et ce n'est pas du GCC !
-
[+] [^]Re: Le futur de GCC se dévoile !
Posté par TazForEver () le 29/10/2003 à 16:14. (lien). Évalué à -3.elle écrite en quoi la VM java ? en quoi l'interpréteur Python ? le moteur de PHP ? faut sortir mon gars
-
[^]Re: Le futur de GCC se dévoile !
Posté par Stéphane TRAUMAT (page perso, ) le 29/10/2003 à 16:28. (lien). Évalué à 2.Ok, il s'agit donc d'un autre débat mais un programme Java, Delphi, Php ou python n'est pas compilé avec GCC ( certains sont même interprétés)
Si la JVM java est écrit avec GCC, je serais surpris-
[^]Re: Le futur de GCC se dévoile !
Posté par Ice Lion (page perso, ) le 29/10/2003 à 16:43. (lien). Évalué à 2.Je sais pas chez toi, mais chez moi java repose sur la libc, fournie par GCC.
$ 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 (page perso, ) le 29/10/2003 à 16:47. (lien). Évalué à 1.Ok d'accord, alors, si la question est de savoir si l'interpreteur ou quoique ce soit qui permet de faire marcher un soft est lié à quelque chose qui est compilé avec GCC... dans ce cas la, je retire ma remarque.
-
[^]Re: Le futur de GCC se dévoile !
Posté par patrick_g (page perso, ) le 29/10/2003 à 17:37. (lien). Évalué à 6.j'ai trouvé dans le pdf en quoi est écrit GCC :
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 () le 29/10/2003 à 17:46. (lien). Évalué à 1.t'as du te planter ou alors tu parle de l'intégralité, toutes parties avant confondues
-
[^]Re: Le futur de GCC se dévoile !
Posté par patrick_g (page perso, ) le 29/10/2003 à 17:59. (lien). Évalué à 2.oui oui c'est l'intégralité du soft.
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 () le 29/10/2003 à 18:03. (lien). Évalué à -1.non pas franchement. regarde Linux, tu tapes > 4Millions pour les 2.4
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 (page perso, ) le 29/10/2003 à 18:20. (lien). Évalué à 1.ben.... j'ai rien compté du tout moi !
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 Gwenole Beauchesne (page perso, ) le 29/10/2003 à 18:42. (lien). Évalué à 4.La JVM de Sun (HotSpot) est écrite en C++. Ils compilent maintenant les versions Linux avec GCC 3.2.
-
-
[^]Re: Le futur de GCC se dévoile !
Posté par iouri () le 29/10/2003 à 19:16. (lien). Évalué à 1.N'importe comment, si le compilo C ou C++ de gcc est bien fait, le fait de l'améliorer/modifier/étendre ne devrait pas changer les binaires obtenus aves un compilateur FOO, lui même compilé avec gcc.
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 () le 29/10/2003 à 19:27. (lien). Évalué à 3.tu n'as pas compris grand chose. GCC est une partie arrière et plusieurs parties avants. L'effort de l'équipe de développement porte sur la partie arrière, donc tous les compilateurs basé sur la partie arrière de GCC seront plus performants, en exécution et en code objet généré.
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 () le 29/10/2003 à 20:10. (lien). Évalué à 2.si le compilo C ou C++ de gcc est bien fait, le fait de l'améliorer/modifier/étendre ne devrait pas changer les binaires obtenus
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 () le 29/10/2003 à 20:14. (lien). Évalué à 8.pas en général, tout le temps. ça s'appelle le bootstraping, ou auto-compilation.
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 () le 30/10/2003 à 00:25. (lien). Évalué à 3.>> si le compilo C ou C++ de gcc est bien fait, le fait de l'améliorer/modifier/étendre ne devrait pas changer les binaires obtenus
> 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 () le 30/10/2003 à 10:30. (lien). Évalué à 1.ben oui, mais on parle de compilateur à base de gcc ici. le cas que tu évoques est idiot, le compilateur dont tu parles est alors un logiciel comme les autres
-
[^]Re: Le futur de GCC se dévoile !
-
-
[^]Re: Le futur de GCC se dévoile !
-
-
-
-
-
[+] Re: Le futur de GCC se dévoile !
moi je veux une 3.6.x qui regroupe tout!!!
-
[^]Re: Le futur de GCC se dévoile !
Posté par patrick_g (page perso, ) le 29/10/2003 à 15:41. (lien). Évalué à 2.heu.....d'après ce que j'ai compris c'est pas exclusif !
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 !
je me permets d'émettre quelques doutes sur l'association "précompilation d'entêtes C++" <-> "template"
à 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 (page perso, ) le 29/10/2003 à 17:29. (lien). Évalué à 2.MSVC sait precompiler les headers C++ depuis longtemps, pourquoi gcc ne pourrait pas ? Vu que 90% de la lib standard C++ repose sur des templates, faut esperer que ça marche :-).
-
[+] [^]Re: Le futur de GCC se dévoile !
Posté par TazForEver () le 29/10/2003 à 18:05. (lien). Évalué à -1.par le pas de VS, c'est loin d'être la référence. y a une différence entre précompilé les stdio etc du C, et les iostream template. sans export ou truc du même genre, je ne pense pas que ça soit possible
-
[^]Re: Le futur de GCC se dévoile !
Posté par Tennis Prono (page perso, ) le 29/10/2003 à 18:44. (lien). Évalué à 2.L'inconvénient avec le système de Visual C++, c'est que ça incite à faire un header "all.h" dans lequel tu vas mettre tout (API Windows, header standards...) et qu'il va falloir inclure partout.
Je trouve ça un peu laid, mais c'est mieux que rien et personne ne l'oblige à l'utiliser.--
Pas de bureau 3d libre sans drivers libres!-
[^]Re: Le futur de GCC se dévoile !
Posté par TazForEver () le 29/10/2003 à 18:52. (lien). Évalué à 4.et même avec un linker performant, tu fais péter la taille des exécutables. la précompilation, c'est bien mais c'est loin de tout résoudre. ceux qui se plaignent du C++ et notemment des ses templates qui font péter le temps de compilation n'ont rien compris aux template et à la nécessité d'avoir une vrai politique d'instanciation
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 (page perso, ) le 29/10/2003 à 21:10. (lien). Évalué à 1.> la nécessité d'avoir une vrai politique d'instanciation
Tu peux détailler un petit peu ?-
[^]Re: Le futur de GCC se dévoile !
Posté par TazForEver () le 29/10/2003 à 21:28. (lien). Évalué à 7.bah si tu utilises le mécanisme de l'inclusion de la définition pour tes templates (sur le modèle communément utilisé par STL) dans un gros projet, tu va vite tout faire exploser. g++ avec -frepo permet de gérer ça un peu mieux. mais tu peux le faire à la main dans une moindre mesure, mais avec beaucoup d'efficacité.
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 () le 29/10/2003 à 21:48. (lien). Évalué à 4.Malheureusement, pour utiliser les templates depuis un an ou deux maintenant, ça n'est pas aussi simple !
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 () le 29/10/2003 à 21:55. (lien). Évalué à 1.certes. je n'ai jamais dit que c'était là solution. prendre conscience de la nature du problème c'est déjà faire un grand pas en avant. comme toi j'attends des solutions. tu as essayé -frepo ? à grande échelle ?
-
[^]Re: Le futur de GCC se dévoile !
Posté par Troy McClure (page perso, ) le 29/10/2003 à 23:20. (lien). Évalué à 1.Bon je vais répondre un peu à côté de la plaque puisque je n'ai jamais utilisé -frepo avec gcc, mais j'ai utilisé l'équivalent (contre mon gré) avec le compilateur DEC, et mon souvenir c'est que c'était une horreur à gèrer, particulièrement avec autoconf et cie pour contruire une bibliothèque partagée: le truc se cassait régulièrement et le repository contenait quelques dizaines de milliers de fichiers du coup les accès devenaient débilement lents :-/
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 () le 29/10/2003 à 23:27. (lien). Évalué à 1.puisque ce sont les optimisations qui prennent le plus de temps ...
-
[^]Re: Le futur de GCC se dévoile !
Posté par Philippe Fremy (page perso, ) le 30/10/2003 à 08:29. (lien). Évalué à 2.Oui mais non: je compile un projet boost.python en debug (donc pas d'optimisation) de 50 lignes et la compilation du fameux fichier .cpp prend au bas mot une minute. Et ca bouffe enormement en memoire. Sous Visual, j'ai du augmenter comme un malade la taille de la pile du compilateur.
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 () le 30/10/2003 à 10:31. (lien). Évalué à 0.tu fous quoi avec visual ? t'as essayé avec g++ ? c'est bien connu que VS est une daube avec les templates et incapables d'optimisations les plus triviales
-
[^]Re: Le futur de GCC se dévoile !
Posté par Philippe Fremy (page perso, ) le 30/10/2003 à 12:06. (lien). Évalué à 6.Bien sur que j'ai essaye g++, je compile mon projet en meme temps sous linux, sous windows et sous cygwin. Si on fait la comparaison, j'ai pas eu de problemes de stack sous g++, p'tet qu'il gere ca differamment.
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 () le 30/10/2003 à 12:12. (lien). Évalué à 1.il est disponible ton projet pour faire des tests ?
-
-
[^]Re: Le futur de GCC se dévoile !
-
-
-
-
-
[^]Re: Le futur de GCC se dévoile !
Posté par harbort () le 31/10/2003 à 18:19. (lien). Évalué à 3.alors oui, j'ai essayé -frepo, mais ça n'a pas été concluant ! J'ai jamais réussi à compiler mon programme correctement avec ... peut-être que je n'ai pas les bonnes choses, mais la compilation des templates eux-même n'a jamais marchée !
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 (page perso, ) le 01/11/2003 à 12:51. (lien). Évalué à 1.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 !!!!
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 () le 01/11/2003 à 13:17. (lien). Évalué à 1.oui et non.
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 () le 03/11/2003 à 10:47. (lien). Évalué à 1.si ton linker est intelligent, il supprime les doublons. donc au final on ne sent rien
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 (page perso, ) le 30/10/2003 à 19:58. (lien). Évalué à 1.si tu t'amuses à faire des #include <collection.hpp> dans chaque fichier : ton temps de compilation explose, la taille de ton binaire aussi.
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 !
Je suis un peu surpris dans l'article d'onversity que SSA soit considéré comme un développment récent des compilateurs, si je me souviens bien en 95, c'etait deja largement utilisé dans la recherche sur les compilateurs..
Alors récent? Euh, pas tant que ça..
-
[^]Re: Le futur de GCC se dévoile !
Posté par patrick_g (page perso, ) le 30/10/2003 à 15:16. (lien). Évalué à 3.8 ans pour passer de la recherche fondamentale universitaire à la production c'est pas si long que ça.....non ?
-
[^]Re: Le futur de GCC se dévoile !
-
Cette page a été générée par Templeet en 0.2548s (dont 0.0507 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.