Le futur de GCC se dévoile !

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
29
oct.
2003
Technologie
GCC est un ensemble de compilateurs libre utilisé par GNU/Linux et la quasi-totalité des logiciels libres.

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

  • # Re: Le futur de GCC se dévoile !

    Posté par  . Évalué à 1.

    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  . É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  . É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  (site web personnel) . Évalué à 0.

          Euh c'est quoi export ? c'est comme extern ?

          • [^] # Re: Le futur de GCC se dévoile !

            Posté par  . É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  . É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  . É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 !

    Posté par  (site web personnel) . Évalué à 5.

    "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++.

    http://about.me/straumat

    • [^] # Re: Le futur de GCC se dévoile !

      Posté par  . É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  . É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  . Évalué à -2.

      Peut-etre mais les langages dont tu veux parler sont eux-meme écrit en C...

      • [^] # Re: Le futur de GCC se dévoile !

        Posté par  (site web personnel) . É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  . É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 !

        Posté par  . Évalué à 1.

        C'est oublier les projets en Caml (bon ok, y'en a peu)

        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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . Évalué à 0.

      Beaucoup de projets libres sont en Java, PHP, Delphi, Python... et ce n'est pas du GCC !

      http://about.me/straumat

      • [^] # Re: Le futur de GCC se dévoile !

        Posté par  . É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  (site web personnel) . É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

          http://about.me/straumat

          • [^] # Re: Le futur de GCC se dévoile !

            Posté par  . É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  (site web personnel) . É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.

              http://about.me/straumat

              • [^] # Re: Le futur de GCC se dévoile !

                Posté par  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . Évalué à 1.

                  sinon c'est quoi MD ?

                  Machine Description peut-être ?

          • [^] # Re: Le futur de GCC se dévoile !

            Posté par  . É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  . É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  . É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  . É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  . É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  . É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  . É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 !

                  Posté par  . Évalué à 0.

                  Merci de ta politesse.

                  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  . Évalué à 4.

                Compiler le compilateur avec le compilateur tout frais compile, ca permet de tester partiellement la validite de ce compilateur. Il faut qu'il genere le meme code que lui meme.

  • # Re: Le futur de GCC se dévoile !

    Posté par  (site web personnel) . Évalué à -3.

    moi je veux une 3.6.x qui regroupe tout!!!

    • [^] # Re: Le futur de GCC se dévoile !

      Posté par  (site web personnel) . É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 !

    Posté par  . Évalué à 1.

    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  (site web personnel) . É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  . É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  (site web personnel) . É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.

        • [^] # Re: Le futur de GCC se dévoile !

          Posté par  . É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  (site web personnel) . É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  . É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  . É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  . É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  (site web personnel) . É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  . Évalué à 1.

                      puisque ce sont les optimisations qui prennent le plus de temps ...

                      • [^] # Re: Le futur de GCC se dévoile !

                        Posté par  (site web personnel) . É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  . É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  (site web personnel) . É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  . Évalué à 1.

                            C'etait vrai avec VS6 (incapable d'instancier des fonctions membres template correctement, ou des instanciations partielles de templates) mais depuis VS7.1 il est tres bon.

                  • [^] # Re: Le futur de GCC se dévoile !

                    Posté par  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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 !

    Posté par  . Évalué à 3.

    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..

Suivre le flux des commentaires

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