Journal Intel contribuera à GCC

Posté par  .
Étiquettes : aucune
12
16
avr.
2009
Cher journal,

Aujourd'hui, je te fait pas d'une très bonne nouvelle pour tous les utilisateurs de logiciels libres, et plus particulièrement les développeurs: la société Intel à décidé de s'impliquer activement dans le développement du compilateur libre le plus célèbre, GCC.

C'est en effet, le 10 avril qu'un message de Melanie Blower¹, collaboratrice d’Intel, sur la liste de diffusion de GCC à révélé leurs intentions de collaboration plus profonde, et notamment sur le gcc, les binutils, gdb et la glibc. Ces modifications seront assez importante pour nécessiter une signature d’un contrat de cession de droit².

Cela fait suite aux récentes implication de Intel dans le domaine du libre, tel que la création de pilotes pour X.org où encore, la création de la distribution Moblin. Néamoins, Intel c'était, jusque ici, toujours concentré sur son compilateur maison ICC.
On peut donc espérer voir très prochainement des améliorations substantiel de vitesse de compilation et de qualité de code et d'optimisations (bien que GCC faisait déjà du bon travail).

[¹] Annonce sur la liste: http://gcc.gnu.org/ml/gcc/2009-04/msg00336.html
[²] Cession de droit FSF: http://www.gnu.org/licenses/why-assign.fr.html

Site de GCC: http://gcc.gnu.org/

  • # Informations sur ICC

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

    Le lien wikipedia futé serait Intel_C++_Compiler voire la version anglaise plus fournie et disponible à l'adresse suivante : http://en.wikipedia.org/wiki/Intel_C++_Compiler

    • [^] # Re: Informations sur ICC

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

      En même temps, c'était tout aussi simple de rajouter le lien sur le wikipedia...

    • [^] # Re: Informations sur ICC

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

      Que deviens le projet de compilation du noyau linux avec le compilo ICC ?

      Ils sont arrivés à terme, en fait, puisqu' ils produisent maintenant un noyau avec un gain annoncé de perfs de l' ordre de 20% (boost de 40% de perfs sur certaines parties du noyau parait il). Enfin ceci doit être bémolé dans la mesure où c' est avec la version 8 de ICC, la version 11 nécessitant encore un "joli bordel" pour pouvoir compiler Linux. (ce dernier étant très étroitement lié à GCC)

      C' est une excellente nouvelle, dans tout les cas, pour GCC !!!! Enfin, ne nous réjouissons pas trop vite quant même....

      référence :
      http://www.linuxdna.com/

      ( à lire aussi ? http://cache-www.intel.com/cd/00/00/28/47/284736_284736.pdf )




      A ce rythme là, de potentiels futurs Windows seront compilés avec GCC. Mouarf :p

  • # monde de merde !

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

    patrick_g va criser :(

    la dépêche GCC 4.4 va encore trainé dans la file d'attente de modération ...

    sont couillons chez intel, ils attendent la sortie de la 4.4 pour faire leur annonce, maintenant tout le monde attend des patchs de INTeL alors que la RC1 de la 4.4 est seulement en approche.

    pfff ... monde de merde.

    • [^] # Re: monde de merde !

      Posté par  . Évalué à 1.

      En même temps la version RC est sorti il y a à peine 2 jours...

      http://gcc.gnu.org/ml/gcc/2009-04/msg00404.html

      D'ailleurs je me demande comment Fedora a pu mettre cela comme version final, d'après les dires de Iznotgood, alors que le projet en est encore a une RC...

      • [^] # Re: monde de merde !

        Posté par  . Évalué à 9.

        man IsNotGood

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: monde de merde !

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

        le propos etait de rappeler que cela va faire 4 mois que la dépeche sur la sortie de GCC 4.4 traine dans la file de modération ;)

        • [^] # Re: monde de merde !

          Posté par  . Évalué à 1.

          je sais mais ma remarque fait suite à une réponse de Iznotgood à patrick_g sur le sujet il y a quelques jours :)

        • [^] # Re: monde de merde !

          Posté par  . Évalué à 1.

          oups d'ailleurs j'avais mis des balises troll mais elles ont été suprimés :)

      • [^] # Re: monde de merde !

        Posté par  . Évalué à 10.

        > D'ailleurs je me demande comment Fedora a pu mettre cela comme version final,

        Comme d'habitude, avec talent.

  • # Architecture naze

    Posté par  . Évalué à -5.

    « On peut donc espérer voir très prochainement des améliorations substantiel de vitesse de compilation et de qualité de code et d'optimisations (bien que GCC faisait déjà du bon travail). »
    Ouais enfin ça reste du x86 hein... quand on cherche des perfs et du code de qualité on se tourne vers autre chose. :)

    • [^] # Re: Architecture naze

      Posté par  . Évalué à 2.

      Ah ouais ? Rigolo, quand on prend le dernier recensement des 500 machines les plus puissantes au monde* et qu'on compte le nombre de machines x86 et x86-64 (entrant dans le cadre des futures contributions d'Intel à GCC), on trouve 429 machines, soit environ 85%.

      * : http://www.top500.org/stats/list/32/procfam

      • [^] # Re: Architecture naze

        Posté par  . Évalué à 6.

        C'est que l'on utilise plus le x86, et donc plus de travail d'optimisation est fait pour cette plateforme. C'est moins cher aussi.

        Envoyé depuis mon lapin.

        • [^] # Re: Architecture naze

          Posté par  . Évalué à 0.

          Ouais, et MS Windows c'est ce qui est le plus utilisé dans le monde aussi, donc c'est mieux aussi ?
          Si le x86 est si répandu c'est parce que c'est moins cher et que beaucoup ont développé dessus (dont le Windows de MS, qui y a largement contribué). Ça n'empêche pas que c'est une architecture dépassée, du 8 bit patché 16 bit patché 32bit patché 64 bit, avec son lot d'instructions devenant inutiles voire insécures à chaque fois, le mode non protégé, etc.
          Il y a bien mieux conçu (je pense à Sparc et PowerPC), mais effectivement c'est plus cher donc moins intéressant pour certains. :)

          • [^] # Re: Architecture naze

            Posté par  . Évalué à 4.

            Je n'ai jamais dit que le x86 était bien (par contre le commentaire du dessus l'a insinué).
            Moi aussi j'ai un power pc, et c'est trop bien. Par contre, mon core2duo est plus puissant…

            Envoyé depuis mon lapin.

          • [^] # Re: Architecture naze

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

            Compte tenu de l'importance des économies d'échelle dans le coût d'un processeur on peut soutenir aussi que les autres architectures sont plus chères parce que plus rares.

          • [^] # Re: Architecture naze

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

            Tu ne considères uniquement que le design des instructions. Certe cela fait un décodeurs immonde en x86 et cela complique le compilateur. Mais le compilateur est lui-même plus simple que pour de l'IA64 (itanium) !

            Concernant la microarchitecture, il n'y a pas grand chose qui rivalise avec les x86. Le niveau qualité/prix est délirant, en perf brute, les POWER et les itaniums (surtout en flottant) ne sont pas mauvais ou équivalent (mais beaucoup plus chère avec beaucoup plus de transistors).

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

          • [^] # Re: Architecture naze

            Posté par  . Évalué à 2.

            En meme temps ca fait lontemps que le coeur des procs s'est fortement rapproche d'une architecture type RISC. Apres on peut discuter de l'interet d'avoir un decodeur d'instructions x86/x64/x87 et toute la logique qui va avec, mais ca n'a plus grand chose a voir avec l'architecture meme du processeur.

    • [^] # Re: Architecture naze

      Posté par  . Évalué à 2.

      Humour mis à part, on ne peut nier que les plateformes à base de processeur Intel couvrent largement le spectre des systèmes informatiques.

      l'IA-32 (et ses extensions 64 bits) couvrent de l'ultra portable au serveur, l'IA-64 pour les stations de travail et serveurs, et le XScale (à base ARM:) pour les terminaux mobiles.

      Par ailleurs, demander dès l'annonce la procédure pour céder des droits, ça sent pas franchement le patch de 15 lignes mais quelque-chose de plus conséquent.

      Bref, une initiative à saluer.

      PS : il n'y a plus qu'à voir si Sun va faire de même pour ses processeurs SPARC et OpenSPARC O:-)

    • [^] # Re: Architecture naze

      Posté par  . Évalué à 6.

      "on" c'est qui?

      - utilisateur final:
      Ben les perfs, c'est joli, mais le plus intéressant c'est le rapport puissance/(prix*consommation), et là à part les procs ARM, pour l'instant c'est un peu le néant, sauf applications spécifiques.

      - développeur de processeur:
      Y'en a qui ont essayé, ils ont eu des problèmes. Cela dit ils sont très rapides.
      On t'attend pour sortir l'opensparc qui va conquérir un large public (assez large pour rentabiliser des wafers de 300mm avec une techno de 60nm max, 45 préférable, le temps de finir le design la moitié des concurrents seront en 32, autant te prévenir...).
      Et encore, avec l'opensparc je te facilite la tâche: le coeur est déjà fait!

      Le x86, c'est peut-être pas la meilleure base, mais c'est de loin celle qui a concentré le plus d'efforts d'optimisation. D'ailleurs on se demande pourquoi Apple a renoncé au power pc, et pourquoi IBM ne vend pas que du G5 sur ses serveurs.

      • [^] # Re: Architecture naze

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

        et pourquoi IBM ne vend pas que du G5 sur ses serveurs.

        Parce que gcc sur les processeurs Power* est encore plus mauvais que sur x86 et que la plupart des applications ne sont pas assez portables pour être compilées par xlc ?

        Au passage, les serveurs IBM utilisent généralement directement des power4 (ou plus) plutôt que les versions bridées G5 etc.

        PS: on n'attend plus que la réponse de Laspalles !

        • [^] # Re: Architecture naze

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

          Pourquoi dire que Gcc est mauvais sur x86 ?

          Il n'est parfois pas le plus rapide (et encore, souvent les autres compilo "trichent") mais surtout il est moins bugué ! Combien de problème j'ai pu voir avec des compilo pour µcontroleur !

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

          • [^] # Re: Architecture naze

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

            Je parlais en termes de perfomances pures et pas mal de compilateurs font mieux ou aussi bien sur x86. Et aussi, qu'appelles-tu tricher pour un compilateur ?

            Je ne vois pas le rapport avec ta remarque sur les micro-controleurs par contre.

            • [^] # Re: Architecture naze

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

              Tu penses à quel compilateur Icc ? Concernant la triche, c'est tout ce qui tourne autour de la norme IEE754 et des options --fast-math, voir de transformation non légitime pour du C ansi.

              En général, quand on voit un autre compilateur que gcc, c'est pour la myriade de µcontroleur 8-16-32 bits du marché pour le marché de l'embarqué.

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

              • [^] # Re: Architecture naze

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

                Je pensais aussi à des compilateurs propriétaires comme PGI qui ont visiblement des optimisations beaucoup plus poussées et qui semblent mieux tirer parti de mots clés du C99 comme "restrict".

                Et le marché des "autres compilateurs" (= différent de gcc) est aussi assez dévéloppé du côté des gros calculateurs, surtout sur les architectures de types AMD64 qui sont assez populaires, notamment grâce à la famille Cray XT*.

  • # Intérêt d'Intel dans tout ça ?

    Posté par  . Évalué à 3.

    Quel est l'intérêt d'intel ici ? Est-ce qu'ils n'encouragent pas leur concurrence vu qu'ils vendent déjà leur compilateur maison ?

    • [^] # Re: Intérêt d'Intel dans tout ça ?

      Posté par  . Évalué à 1.

      Pas forcément. Il faudrait voir combien leur coûte et combien leur rapporte leur compilateur en pratique. Peut-être qu'en faisant les calculs ils se sont rendu compte que ça ne leur coûterait pas plus cher de contribuer plutôt à gcc que de tout faire par eux-mêmes. Enfin je dis ça je n'en sais absolument rien. On verra bien ce qu'ils contribueront.

    • [^] # Re: Intérêt d'Intel dans tout ça ?

      Posté par  . Évalué à 6.

      Peut être s'assurer que les utilisateurs de logiciels compilés avec gcc choisiront un processeur intel plutôt qu'un autre pour le gain en perf ? ;)

      • [^] # Re: Intérêt d'Intel dans tout ça ?

        Posté par  . Évalué à 3.

        C'est clairement du marketing. La raison que tu donnes est probablement bonne. Et une autre tout aussi importante: l'image de marque. Intel c'est bien car ils contribuent à la réduction du cholestérol GCC.

    • [^] # Re: Intérêt d'Intel dans tout ça ?

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

      Intel vend du hardware
      Toute leurs contribution dans les drivers et compilateur servent à donner plus de valeur à leur matériels.
      Et le modèle du logiciel libre est bon pour ce genre de situation.

      * Avantages :
      - On part avec de bonne base, plus simple que de partir from scratch.
      - Une grosse partie du travail peut être mutualisé avec d'autres.

      * Inconvénents :
      - Il faut savoir coopérer avec la "communauté"

  • # Compilation Linux AMD/Intel

    Posté par  . Évalué à -2.

    Perso:
    - Intel Pentium D dualcore 3.4 Ghz: 9 mins.
    - AMD Phenom quadcore 2 Ghz: 5 mins.

    Ok, c'est pas la même génération de CPUs... mais quand même... tant mieux pour Intel.

    • [^] # Re: Compilation Linux AMD/Intel

      Posté par  . Évalué à 2.

      Ouais enfin là c'est particulièrement incomparable comme test, il y a beaucoup trop de différences entre les deux architectures de chaque processeur.

      • [^] # Re: Compilation Linux AMD/Intel

        Posté par  . Évalué à -1.

        C'est ce que je disais.
        Pas la même génération, mais quasiment un facteur 2... ça sent pas bon.
        Tant mieux qu'Intel se mette à GCC.

        • [^] # Re: Compilation Linux AMD/Intel

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

          Quel est ton test au fait ?

          • [^] # Re: Compilation Linux AMD/Intel

            Posté par  . Évalué à 5.

            Je dirais compilation de Linux à tout hasard ..............

            • [^] # Re: Compilation Linux AMD/Intel

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

              Et à tout hasard c'est quoi "Linux" ? Quels sont les paramètres de compilation, de make ? Est-ce que les fichiers sont sur disques ou en mémoire ? Est-ce que le gcc a été lui-même compilé pour la machine, car le sujet ici était la génération de code optimisé, pas forcément la vitesse de compilation.

        • [^] # Re: Compilation Linux AMD/Intel

          Posté par  . Évalué à 2.

          D'un autre côté, c'est pas pour troller, mais qu'un quad-core de nouvelle génération mette strictement plus de 1/2 fois le temps mis par un dual-core d'ancienne génération, ça m'inquiète quand même un peu pour AMD. Rien qu'au rapport du nombre de coeurs, on s'attendrait à ce que le Phenom mette 5 minutes, du coup le fait d'utiliser une architecture récente devrait le faire mettre encore moins de temps !

          Surtout pour une tâche aussi parallélisable que la compilation du noyau. D'un autre côté, tu ne nous donnes pas les fréquences des processeurs, donc faut voir.

          • [^] # Re: Compilation Linux AMD/Intel

            Posté par  . Évalué à 3.

            D'un autre côté, tu ne nous donnes pas les fréquences des processeurs, donc faut voir.

            Ben si il les donne: 3.4GHz et 2GHz.

            • [^] # Re: Compilation Linux AMD/Intel

              Posté par  . Évalué à 1.

              Oups désolé, j'avais lu trop vite.
              Merci de la précision, ça donne donc bien un gain en faveur du Phenom, ouf le monde tourne bien à l'endroit :)

  • # ...

    Posté par  . Évalué à 2.

    Esperons qui ne fasse pas comme arm (via codesourcery) : ajout des fonctionnalités derniers cris, mais peu de support des procs un peu ancien.


    PS : je sais pas d'ou le [1] est deduit, mais le mail reste tres flous : on parle seulement de contribution future...


    [1]
    C'est en effet, le 10 avril qu'un message de Melanie Blower¹, collaboratrice d’Intel, sur la liste de diffusion de GCC à révélé leurs intentions de collaboration plus profonde, et notamment sur le gcc, les binutils, gdb et la glibc. Ces modifications seront assez importante pour nécessiter une signature d’un contrat de cession de droit².

    • [^] # Re: ...

      Posté par  . Évalué à 4.

      "le mail reste tres flous : on parle seulement de contribution future..."

      Intel attend Hurd !

Suivre le flux des commentaires

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