Editorial FreshMeat sur GCC

Posté par  (site web personnel) . Modéré par Xavier Antoviaque.
Étiquettes :
0
17
fév.
2003
GNU
On a dit tout et n'importe quoi sur GCC (GNU Compiler Collection), un des projets de logiciel libre les plus importants.

Développé depuis au moins 1987 (la v1.0 est sortie le 23 mai 1987, la v2.0 le 22 février 1992), le passage à GCC version 3.x (18 juin 2001) a apporté beaucoup de changements : optimisations diverses, améliorations du C++ et consorts, meilleure prise en compte des architectures non-x86, etc.

Voici donc un court article (ses commentaires et sa collection de liens) sur le vrai et le faux des optimisations GCC les plus courantes.

Aller plus loin

  • # Re: Editorial FreshMeat sur GCC

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

    Mouais, ca dit pas grand chose... il parle pas de -Os notamment... il dit pas tout ce que -ffast-math et autres peuvent impliquer... il ne parle pas non plus des flags que les differents -march= activent... mais sinon pour un machin de vulgarisation c plutot bien...

  • # gcc 3.2

    Posté par  . Évalué à 10.

    Le passage à gcc 3 est un problème épineux. Malgré une meilleure qualité du code, sa vitesse d'éxecution est jugée très décenvante. En effet, beaucoup de gens pensent que la rapidité de compilation est plus importante qu'un infime pourcentage en exécution, notement en ci qui concerne les développeurs.

    Cf. un thread sur les list openbsd. http://marc.theaimsgroup.com/?l=openbsd-tech&m=104453801914141&(...)
    http://marc.theaimsgroup.com/?l=openbsd-tech&m=104456745628909&(...)

    • [^] # Re: gcc 3.2

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

      Mais e ntout cas en C++ le code est plus propre avec gcc 3 qu'avec tout ceux precedants. par contre il est vrai que ca rame un peu plus a la compilation (mais bon sur mon athlon 2100 sa ce voit pas trops :))

      • [^] # Re: gcc 3.2

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

        Sans parler d'un meilleur support de la bibliothèque standard C++ (dont la STL) et des fonctionnalités avancées des templates.

        • [^] # Re: gcc 3.2

          Posté par  . Évalué à 5.

          A ce sujet j'ai vu des documents "qualité" qui sont censé donner les conventions de codage et qui précisaient des aberrations du genre, on n'utilise pas la derniere version ni la STL parce que ca induit des temps de compilation trop longs !!...

          Non sans dec' ! Le support de la STL est une bénédiction (même si les foncteurs ca vaut pas encore les langages fonctionnels), et les temps de compilation... ben il faut bien gérer ses #include et ses dépendances... et à moins de compiler sur un vieux sparc, ca vaut pas un meilleur compilo et un meilleur code.

          • [^] # Re: gcc 3.2

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

            Si ton code doit compiler sur des plateformes un tout petit peu anciennes, oui, clairement tu peux dire au revoir à la STL. Ça va en s'améliorant, mais faut pas être pressé.

            et les temps de compilation... ben il faut bien gérer ses #include et ses dépendances

            Justement, les templates font exploser ça, tu es obligés d'inclure plein de choses (en plus du temps de génération du code pour les templates instanciés).

    • [^] # Re: gcc 3.2

      Posté par  . Évalué à 8.

      Vivement la version avec le nouveau parseur et la compilation de header.

      Ca devrait accelerer pas mal les choses (ne serait-ce que la compilation des librairies STL)..

      • [^] # Re: gcc 3.2

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

        Le problème c'est que ca a un impact sur les sources. Ca implique d'avoir un fichier genre "all.h" avec tous les headers standards, qu'on n'aurait pas forcément envie d'inclure partout.
        Pour les mecs qui ont un parc de machines minimal, un programme comme distcc (lancement de compilation distribuée sur le LAN, j'ai jamais essayé) a un impact énorme. J'ai essayé IncrediBuild (propriétaire, Windows) qui marche sur le meme principe et c'est formidable. Je ne pense pas qu'on puisse avoir un meme gain de vitesse de compil du meme ordre avec des progrets de gcc.

        • [^] # Re: gcc 3.2

          Posté par  . Évalué à 1.

          Pas mal de personnes utilisant une gentoo et voulant en mettre une sur un "petit PC" (en dessous des 300Mhz avec moins de 128Mo de ram) font état du très grand intérêt pour distcc. Les personnes (pas forcément celles qui veulent une gentoo, là n'est pas mon propos) qui veulent compiler quelques gros packages sur ce type de machines se doivent d'utiliser distcc si elles en ont les moyens techniques amha !
          Sincèrement ça vaut le coup d'essayer !

          • [^] # Re: gcc 3.2

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

            Faudra que j'essaie, j'ai une gentoo sur un Cyrix MX200 (166 Mhz).
            Jusqu'ici, j'utilise un autre solution : Je monte le / de ma gentoo via NFS sur le /mnt/gentoo d'un PC plus puissant.
            Ensuite je vais un chroot, un source /etc/profile puis un env-update et zou, je retrouve ma gentoo et je peux compiler des gros trucs.
            Attention, genre pour compiler kde ça génére énormément de trafic via le réseau, de l'ordre du giga-octet.

    • [^] # Re: gcc 3.2

      Posté par  . Évalué à 10.

      "En effet, beaucoup de gens pensent que la rapidité de compilation est plus importante qu'un infime pourcentage en exécution, notement en ci qui concerne les développeurs. "

      Euh... à part les développeurs, qui se soucie de la vitesse de compilation?
      En tant qu'utilisateur je me moque bien de savoir combien de temps a duré la compilation des logiciels, ce qui m'intéresse c'est leur efficacité, et la vitesse d'éxécution en est un paramètre.

      En fait, la bonne technique c'est d'avoir un compilateur rapide pour le développeur, pendant la phase de développement, et un compilateur efficace (qui génère du code rapide) pendant la phase d'intégration.

      Au fait, je signale que dans ma boîte, on utilise gcc au service d'intégration (on vient de passer de 2.7 à 2.9 ; pour la 3.x attendez un peu ^_^)

      • [^] # Re: gcc 3.2

        Posté par  . Évalué à 0.

        La vitesse de compilation peut devenir importante pour le client si celle ci est vraiment trop lente. Si pour relivrer un soft avec une petite modif il faut 24h de compile au lieu de quelques heures ca peut rapidement devenir genant.

        --
        Chuchi
        PS: par client j'entends pas uniquement le client final qui achete le soft, mais aussi les equipes de tests, ...

        • [^] # Re: gcc 3.2

          Posté par  . Évalué à 4.

          Même si tu as un soft qui met plusieurs heures à compiler, pour une petite modif tu compiles juste le ou les quelques fichier .o nécessaires et tu fais le linkage. T pas obligé de tout recompiler complétement !

          • [^] # Re: gcc 3.2

            Posté par  . Évalué à 1.

            Si. À la livraison d'un produit, même u patch, tu as tout intérêt à refaire un build complet, histoire d'être sûr de pas avoir de surprises la fois suivante.

  • # Mauvaise nouvelle

    Posté par  . Évalué à -10.

    C'est plus avec une longue ligne d'options de gcc que certains pourront compenser ...
    Hein, non j'ai rien dit.

  • # Re: Editorial FreshMeat sur GCC

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

    Ma ligne de tueur
    -O3 -fomit-frame-pointer -funroll-all-loops (-ffast-math)
    C'est en moyenne le plus rapide.

    "La première sécurité est la liberté"

    • [^] # Re: Editorial FreshMeat sur GCC

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

      C'est pas en moyenne le plus rapide puisque comme le dit l'article cela peut poser des problèmes de gestion de cache...

      Je serais ravi de voir des stats de performance sur des codecs vidéos entre autres pour déterminer EN SITUATION quelle sont réellement les meilleures options de compilation.

      • [^] # Re: Editorial FreshMeat sur GCC

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

        C'est pas en moyenne le plus rapide puisque comme le dit l'article cela peut poser des problèmes de gestion de cache...

        Sauf que c'est complètement faux ! C'est une croyance type légende urbaine qui traine. Faite le test ! Un type (de suse ?) fait un test continue de qualité de gcc, -funroll-all-loops est même mieux que -funroll-loops alors que cela doit prendre plus de place en mémoire.

        La perte dans le cache est tout à fait minime en comparaison du gain du à la diminution du nombre de saut et des bulles dans le pipeline.

        (mais pourquoi mon poste précédent est à -3 ?)

        Je serais ravi de voir des stats de performance sur des codecs vidéos entre autres pour déterminer EN SITUATION quelle sont réellement les meilleures options de compilation.

        Leur boucle principal est souvent en assembleur, donc tu ne peux pas gagner grand chose.

        "La première sécurité est la liberté"

        • [^] # Re: Editorial FreshMeat sur GCC

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

          Sauf que c'est complètement faux ! C'est une croyance type légende urbaine qui traine. Faite le test ! Un type (de suse ?) fait un test continue de qualité de gcc, -funroll-all-loops est même mieux que -funroll-loops alors que cela doit prendre plus de place en mémoire.

          Sur quel type de code ? Si c'est sur un benchmark ou un truc hyper-spécialisé genre codec video, ça n'a pas vraiment de rapport avec une appli réelle.

          • [^] # Re: Editorial FreshMeat sur GCC

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

            Suse fait tourner spec je crois. C'est un ensemble d'application réelle.

            "La première sécurité est la liberté"

            • [^] # Re: Editorial FreshMeat sur GCC

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

              Non, c'est un benchmark comme tant d'autres. Je ne pense pas que tu puisses mesurer l'impact d'un flag comme -funroll-all-loops sur une appli comme KOffice ou OpenOffice à partir de ce benchmark.

              • [^] # Re: Editorial FreshMeat sur GCC

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

                C'est un benchmark composé d'une vingtaine d'application.

                De toute façon, je ne crois pas que des applications comme KOffice ou Oo compile avec autres choses que "-02 -g".

                "La première sécurité est la liberté"

                • [^] # Re: Editorial FreshMeat sur GCC

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

                  C'est un benchmark composé d'une vingtaine d'application.

                  Par "applications" je veux dire "vrais logiciels qui servent à quelque chose", genre Word, Excel, Photoshop, etc... pas "20 petits bouts de code qui font tourner un vague algo". Par ailleurs SPEC c'est pas juste un benchmark (mais dans le cas présent il doit s'agir de SPEC CPU).

                  http://www.spec.org/(...)

                  De toute façon, je ne crois pas que des applications comme KOffice ou Oo compile avec autres choses que "-02 -g".

                  Je ne comprends pas ce que tu veux dire. Que KOffice ou OpenOffice ne compilent pas avec -funroll-loops ? A quoi sert ce flag si il ne marche pas sur une vrai appli alors ? :-)

                • [^] # Re: Editorial FreshMeat sur GCC

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

                  > De toute façon, je ne crois pas que des applications comme KOffice ou Oo compile avec autres choses que "-02 -g".

                  Sur PowerPC TOUT se compile avec :
                  -pipe -O3 -fsigned-char -fomit-frame-pointer -march=750
                  sauf postgresql ou je doit mettre -O2 et guile ou je doit me contenter de -O0.
                  Le résultat fonctionne sur G3 et G4.

                  Pour les applis C++ j'essaie de rajouter autant que possible -fno-exceptions -fno-rtti mais beaucoup d'applis ont besoin des exceptions ou de rtti et on ne peut le savoir qu'à la compilation ou à l'exécution si ya des plantages...

                  J'ai décidé depuis peu de rajouter l'option -ffast-math à tout sauf les bibliothèques et applis scientifiques. Si yen a qui on des retours d'expérience avec cette option je suis preneur.

                  Suite à cette article je vais aussi rajouter -DNDEBUG -DG_DISABLE_ASSERT pour voir...

                  • [^] # Re: Editorial FreshMeat sur GCC

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

                    J'ai dis ça, car j'ai déjà essayer de recompiler gcc (avec lui-même) en changeant les options mais cela ne marche pas. Il me semble aussi que la Gentoo linux compile KDE avec -02 -g car les autres options ne passent pas.

                    "La première sécurité est la liberté"

                    • [^] # Re: Editorial FreshMeat sur GCC

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

                      > recompiler gcc (avec lui-même) en changeant les options mais cela ne marche pas

                      SI, ça marche ! Faut lire la doc !

                      > Gentoo linux compile KDE avec -02 -g

                      Comme quoi la Gentoo est loin d'etre aussi optimisé que beaucoup le prétende !
                      Je profite de la perche qui m'est tendu pour dire halte aux idées reçus. Non la gentoo n'optimise pas par défaut les softs qu'elle installe !!!
                      Gentoo a peut-etre fait ce choix car avec -O3 la compilation de KDE prend beaucoup plus de temps et nécessite beaucoup plus de mémoire...

    • [^] # Re: Editorial FreshMeat sur GCC

      Posté par  . Évalué à 0.

      Il manque le -m"tamachine" et les options pour sse(2) si tu veux generer du code souvent tres efficace.

      • [^] # Re: Editorial FreshMeat sur GCC

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

        -march=athlon/pentium4, c'est vrai que c'est mieux :) mais souvent c'est déjà inclue par ta distrib, il me semble. -msse, je crois que cela ne fait (encore) rien à cause d'un gros bug mais cela peut-être changer depuis.

        "La première sécurité est la liberté"

  • # Re: Editorial FreshMeat sur GCC

    Posté par  . Évalué à 3.

    c'est pas consistant comme article. Y a tellement de choses a dire sur les compilateur.

    • [^] # Re: Editorial FreshMeat sur GCC

      Posté par  . Évalué à 3.

      C'est vrai que je l'ai trouvé un peu léger cette article ...
      Je pensais que c'était une documentation plus consistante et pas seulement 3 ou 4 points qui se battent en duel ... dommage.
      Malgrès tout, on apprend des trucs ;)

      • [^] # Re: Editorial FreshMeat sur GCC

        Posté par  . Évalué à 3.

        Les éditos de Freshmeat sont souvent très léger comme ca.. c'est juste des Editos, pas des articles de références.
        Je me souviens meme avoir vu un edito sur le multimédia sous Linux qui était bourré d'erreurs

  • # OffTopic: cherche qq'un pour porter gcc

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

    J'en profite pour passer une petite annonce : je cherche actuellement quelqu'un pour porter gcc sur une architecture type carte a puce. Si ca vous interesse, contactez-moi : phil@freehackers.org . Je precise que c'est un travail remunere (non, c'est pas juste pour le fun).

  • # C++ et gcc-3.X.X

    Posté par  . Évalué à 2.

    En parlant de gcc, qq'un sait ce qui a changé dans l'implémentation de c++?
    Pleins d'applis qui passait très bien, sans warnings avec gcc-2.95 se vautrent comme des otaries bourrés à la bière avec gcc-3.(problème STL, string.h, etc..)
    Je précise que c'est vraiment l'implémentation qui a changé parce que j'ai les mêmes messages sur debian et OS X...

    • [^] # Re: C++ et gcc-3.X.X

      Posté par  . Évalué à 3.

      C'est comme pour le C. Le compilateur est plus exigant qu'avant. Les librairies ont un peu bougées etc...

      C'est un problème d'appli et non de gcc. Je n'ai trouvé que çà comme explication un peu détaillée :
      http://www.redhat.com/advice/speaks_gcc.html(...)

      • [^] # Re: C++ et gcc-3.X.X

        Posté par  . Évalué à 2.

        Disons que gcc-2.95 avait un terrible avantage a l'époque, qui était celui de pouvoir accepter toutes les bidouilles pas très catholiques dans ton code. (mais des trucs qui marchaient genre parce que tu savais comment ca fonctionnait derriere, [comme caster un void (maclass::*)() en void (*)(void*)], ou paske c'etait pas vraiment bien grave hein de preciser deux fois les parametres par defaut).

        C'etait aussi un gros desavantage lorsque tu voulais compiler ailleurs, (chez sun / intel / m$ / borland), ca compilait pas mais alors pas du tout...

        maintenant c'est très axé sur les standards et ça n'accepte plus certains petits écarts de rien du tout qui passaient avant comme une fleur... bon ça oblige a coder proprement, et finallement c'est pas plus mal.

        Y'a aussi les extensions a la STL qui sont bien séparées comme étant des extensions (comme on en parle un peu plus bas), mais ca choque au debut.

        Mais franchement faudrait un bon gros standard derriere tout ca avec au moins des hash_map de base ! Si vous en avez pas assez de la STL, y'a BOOST http://www.boost.org/(...) qui est un truc sympa (mais ca vaudra toujours pas les langages fonctionnels).

    • [^] # Re: C++ et gcc-3.X.X

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

      c normal, en fait toutes les implementations precedentes de gcc ne supportaient pas
      vraiment la norme C++, notamment les 'namespaces' qui sont des regroupement de classes, de fonctions etc ... (un:
      using namespace std;
      using namespace __gnu_ccx; //hash_map et certaines autres classes
      permet de corriger cela)
      deplus la norme ansi-c++ defini les entete de la librairie standard comme suit:
      #include <string> //pour classe string
      #include <sstream> // pour classe stringstream
      #include <iostream> // cout et cin notamment
      etc..
      et donc la libstdc++ a ete corrige en ce sens

Suivre le flux des commentaires

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