Entrevue avec Mark Mitchell, GCC's Release Engineer

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
10
mai
2002
GNU
Au moment où va sortir la nouvelle et première version "stable" de GCC version 3.1, OSNews nous propose une entrevue avec Mark Mitchel, GCC's Release Engineer (que l'on peut traduire par: ingénieur en charge de la réalisation de GCC).

On y parle de GCC 3.x, de son futur, de la compétition face aux autres compilateurs (Intel compiler v6 par ex.), des performances de la version 2.x comparées à celles de la nouvelle mouture...

Aller plus loin

  • # interview en bois

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

    c'est un peu décevant comme interview.

    À la moitié des questions qui sont du genre «est-ce que <tel bidule> va être implémenté ?», la réponse est ... «non.»
    Et pour ce qui est de la comparaison avec le compilo Intel, c'est : «I do not have enough information about that compiler to comment on it.»

    Super.

    • [^] # Re: interview en bois

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

      C'est vrai que l'interview est pourrie et ne nous apprend rien. Ils ne parlent absolument pas des nouveautés de gcc 3.1. Pour ça il vaut mieux allez voir ici : http://gcc.gnu.org/gcc-3.1/changes.html(...)

      Parmi les trucs sympa (en tout cas qui m'interressent) il y a l'ajout de rmi, jndi et jta dans libgcj. En gros il ne doit plus manquer grand chose pour recompiler jboss en natif :-)

  • # Complément d'information

    Posté par  . Évalué à 10.

    Etant donné que l'article ne nous apprend rien, il faut trouver les infos ailleurs.
    En l'occurence voici un benchmark entre GCC 3.0.4 et Intel Compiler v6:
    http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html(...)

    • [^] # Re: Complément d'information

      Posté par  . Évalué à 10.

      Mes excuses, l'URL n'est pas passée en entier:

      http://www.coyotegulch.com/reviews/intel_comp/(...)
      intel_gcc_bench2.html

      • [^] # Re: Complément d'information

        Posté par  . Évalué à 10.

        "I'm looking forward to Intel's C++ 6.0, which will, they tell me, support gcc extensions and Linux kernel compilation"

        à la vue des résultats des benchs, ca peut valoir le coup d'avoir un kernel compilé avec le compilo intel. Même si c'est "closed-source", si les augmentations de perf avoisinent (même à moité seulement) celles évoquées dans le bench, ça peut être plus que tentant...
        Donc, i'm looking forward moi aussi...

        Reste à voir que s'il faut payer une licence pour avoir droit de le compiler, tout le monde n'aurra peut être pas ni l'envie ni les moyens.

        • [^] # Re: Complément d'information

          Posté par  (Mastodon) . Évalué à 4.

          C'est closed-source et (forcément) pas portable. Intel aurait tout intérêt à donner toutes ses spécifications aux développeurs de GCC, plutôt que de faire leur compilo fermé dans leur coin.

          • [^] # Re: Complément d'information

            Posté par  . Évalué à 10.

            Les specs des CPU sont disponibles et _très_ détaillées. Simplement que faire des compilos qui les exploite c'est très difficile. Il suffit de voir quel compilateur sait faire quelque chose avec les instruction mmx, sse, ... Le compilateur d'intel apparemment est très bon, mais ils se limitent aussi à leur proc, alors que gcc compile pour bcp d'architectures. Mais bon, il faut pas cracher dans la soupe, j'aimerais bien trouver des apps comme kde compilées avec le compilo intel. Ce compilateur montre aussi à ceux qui développent gcc qu'il y a encore bcp d'améliorations possibles et ils pourront s'inspirer des optimisations faites en comparant par exemple le code assembleur généré par un gcc et un intel et voir ou intel à gagné du temps, sous quelle forme le code à été mis.

            • [^] # Re: Complément d'information

              Posté par  . Évalué à 10.

              Ce genres d'optimisations sont en expérimentations dans des branches annexes, c'est d'ailleurs à ça que sert les branches. Tester d'autres concepts. Je pense notament au nouvel allocateur de registres, les optimisations au niveau TREEs (AST) au lieu du niveau RTL.

          • [^] # Ca aurait du

            Posté par  . Évalué à 10.

            Selon un document interne a Intel (j'en ai fait partie), il y aurait du y avoir des contributions d'intel a GCC3 pour les itanium et les IA32 (le netburst).
            Maintenant ca date de plus d'un an, et je ne sais pas ce qu'il s'est passé depuis...

  • # OT ? Mandrake & GCC-3.1

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

    C'est un peu OT - mais grâce a notre superbe Gwe-Gwe Beauchesne, nous venons de passer à GCC-3.1 comme compilateur par défaut dans Cooker (la distribution "unstable" de Mandrake). Il a l'air de marcher très bien ma foi, l'essentiel des packages de base a déjà été recompilé avec succès par ses soins.

    Je voulais dire ça, car comme on s'est fait sévèrement chambrer avec GCC-2.96 (malgré tous les arguments), maintenant qu'on a un compilo "blessed", les gens vont être contents ? Hein... ? Comment ça, les gens ne sont jamais contents ? :-)

    • [^] # Re: OT ? Mandrake & GCC-3.1

      Posté par  . Évalué à 0.

      Comment ça, les gens ne sont jamais contents ? :-)

      Pas du tout, les gens pas contents sont par définition les plus bruyants, donc ils apparaissent toujours les plus nombreux. Jamais entendu parler de la majorité silencieuse?
      Personnellement, les seuls gens pas contents que je ne supportent pas sont ceux qui se plaignent du bruit.

    • [^] # Re: OT ? Mandrake & GCC-3.1

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

      Si moi chuis content ! je l'utilise depuis qu'il est dans cooker (deux-trois semaines ?) et j'ai eu aucun problème. C'est juste dommage qu'on ne puisse pas conserver gcc-3.0.4 en même temps, mais bon avec egcs, gcc-2.96 et gcc-3.1 ça commence déjà à faire une belle collection :P

    • [^] # Re: OT ? Mandrake & GCC-3.1

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

      tu as compilé KDE avec GCC 3.1 ? il y a une différence de perfs ? je crois que tous les développeurs KDE attendaient gcc 3.1 pour leur problème de linkage ou je sais plus trop koi.
      sinon, j'utilise la mandrake depuis la version 6.1 et j'en suis très content... et les problèmes de compilos me passent un peu au dessus, du temps que ca marche et que ca évolue dans le bon sens, je suis content.

      • [^] # Re: OT ? Mandrake & GCC-3.1

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

        copier-coller d'un commentaire sur la news de la RedHat 7.3 http://linuxfr.org/2002/05/06/8180,0,1,0,0.php3(...)


        KDE souffre jusqu'à maintenant d'une lenteur en partie du au linkage avec les librairies dynamiques C++
        En juillet dernier est donc sorti objprelink ( http://dot.kde.org/996240227/(...) ) dont le but était de vérifier que l'on pouvait réduire le temps de linkage
        résultat entre 30% à 50% de diminution du temps de lancement des logiciels KDE !
        Mais objprelink n'etait pas stable et constituait un galop d'essai

        Avec la glibc 2.2.5 et les derniers binutils qui contiennent ld, le linkage a été grandement amélioré :

        * optimizations in the dynamic linker. binaries created by recent binutils versions start up quicker due to reduced time spend on relocations.

        cf http://www.gnu.org/software/libc/NEWS(...)

        la version 2.2.5 de la glibc date du 21/01/2002
        binutils 2.12 date du 09/03/2002

        et ici un utilisateur rapporte cette accélération très importante de KDE grace à la glibc 2.2.5 :
        http://forum.hardware.fr/forum2.php3?post=9798&cat=11&confi(...)

        Si quelqu'un peu confirmer la chose...
        parceque moi je sens que je vais tester une gentoo recompilée :)
        un KDE 3.0 + glibc 2.2.5 ca doit être pas mal

        • [^] # Re: OT ? Mandrake & GCC-3.1

          Posté par  . Évalué à 5.

          A mon avis, si les gens de redhat sont assez malins, ils ont déjà compilé kde avec bcp d'optimisations. Avant je recompilais systèmatiquement le noyau par exemple, depuis 6 mois j'ai arrêté, j'avais remarqué que les noyaux redhat mandrake marchaient mieux que les noyaux que je recompilais des sources officielles. Le fait est que redhat et mandrake ajoutent une 50aine de patch au kernel officiel, dont les fameux préemptifs & co qui rendent l'utilisation nettement plus agréable.

          J'ai testé la redhat 7.3, j'ai un duron 700, je peux te dire que kde 3 est _très_ rapide avec tout les eye candy activé (et des trucs comme liquid ajoutés). Je me demande vraiment si tu y gagnerais avec une gentoo, mais essaye :-)

          • [^] # Re: OT ? Mandrake & GCC-3.1

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

            Rien ne t'empêche de recompiler le noyau fourni avec ta distrib (et donc celui qui contient les patchs).

            Sur la mandrake par exemple, tu installes les sources du noyau fournis sur les cd de mandrake et tu reprends le fichier /boot/config que tu copies dans /usr/src/linux/.config et tu as les mêmes options que le noyau qui est installé...
            Tu peux ainsi retirés ce qui ne te plait pas.

            Je suppose que RedHat doit avoir un moyen similaire.

            Mais c'est vrai que je recompilais aussi presque à chaque fois mes noyaux et là, je commence à arrêter car les options par défaut sont celles que je mettais... Bien évidemment, on peut toujours retirer les pilotes/modules en trop par une recompilation...

            • [^] # Re: OT ? Mandrake & GCC-3.1

              Posté par  . Évalué à 4.

              A ce propos, je suis obligé d'ajouter un truc: Je n'ai jamais réussi à recompiler le noyau mandrake à partir des sources fournies par mandrake... Alors bon, je faisais les classiques make config, make ... est-ce qu'il fallait utiliser une autre version de gcc, un kgcc comme chez redhat, j'en sais rien, mais j'avais tjs des erreurs de compils, ça aussi c'est un peu gros :-)

              • [^] # Re: OT ? Mandrake & GCC-3.1

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

                Moi aussi, j'ai eu quelques soucis...

                Généralement je solutionne le problème avec la commande make mrproper (qui efface mieux que make clean et plus de chose aussi).
                Mais ça dépend de la version (je sais que sur la 8.0 et le 2.4.3-mdk?? j'étais obligé de le faire).

                En résumé voilà les commandes qui réussissent (encore hier sur le PC d'un copain, mdk 8.2) :
                make mrproper
                cp /boot/config /usr/src/linux/.config
                make xconfig
                make deps
                make bzImage
                make modules
                make modules_install

                et après installation puis lilo...

              • [^] # Re: OT ? Mandrake & GCC-3.1

                Posté par  . Évalué à -3.

                Franchement, c'était vraiment le pompom...

                Impossible de compiler le noyau de la 8.0 patché, avec le fameux GCC 2.96... je crois que c'est ça qui m'a fait tourner vers la slack; et maintenant j'en suis même plutot content :))

  • # Pas super les modos !

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

    Mark Mitchel est le 'GCC's Release Manager' ce qui peut se traduire par le directeur (et pas ingenieur) des sorties (en bon franglais: des releases) de GCC.
    ou comme le dit si bien google:
    directeur du dégagement du GCC

    • [^] # Re: Pas super les modos !

      Posté par  . Évalué à 1.

      En effet, la nouvelle dit "GCC's Release Engineer (que l'on peut traduire par: ingénieur en charge de la réalisation de GCC).", ce qui n'est pas vraiment ça !

      "to release" dans ce sens veut dire "diffuser" (ou "sortir" ou "rendre public").

      "en charge de la réalisation" se dirait plutôt "implementation manager" (au fait "en charge de" est un léger anglicisme (in charge of), il vaut mieux dire "chargé de" ou "responsable de".) Et oui, "implementer" comme on le dit en français pour dire "programmer" est juste un anglicisme qui veut dire "réaliser", "mettre en oeuvre", "rendre effectif", "mettre à exécution".

Suivre le flux des commentaires

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