URL: https://linuxfr.org/users/patrick_g/journaux/gcc-40-et-les-distributions-sources
Title: GCC 4.0 et les distributions sources
Authors: patrick_g
Date: 2005年01月26日T14:03:34+01:00
Tags: debian
Score: 0
Hello,
Je me pose une question et j'aimerais des avis.
Dans le nouveau GCC 4.0 (encore en beta) il y a eu une refonte totale de l'architecture et l'ajout d'une fonction d'**autovectorisation**.
C'est une nouvelle option qui identifie automatiquement dans un code source les parties qui peuvent tirer avantage des unités vectorielles des CPU.
Les MMX/SSE des Pentium ou les Altivec des G4/G5 peuvent enfin êtres utilisées quand cela est utile.
Voila ou je veux en venir : Actuellement tout le monde s'accorde à dire qu'il n'existe pas vraiment de différence mesurable de performances entre les distribs binaires (Mandrake/Fedora/Debian/Ubuntu) et les distribs sources (Gentoo/Arch/Sorcerer/LFS).
Est-ce que GCC 4.0 ne va pas changer tout cela ?
Un paquet .rpm pour une Mandrake ou un .deb sur une Debian ne peuvent pas êtres compilés avec cette option de vectorisation (car le CPU cible n'est peut-être pas doté de l'unité vectorielle qui va bien) alors que pour les distribs sources il suffira d'un CFLAG idoine pour profiter de l'autovectorisation !
Jusqu'à maintenant il n'y avait pas de différences de performances mais, sachant que la vectorisation est un facteur majeur d'améliorations sur tout ce qui est multimedia et crypto, je pense que dans les mois à venir les distribs sources vont peut-être creuser un écart !
Réponses anticipés aux contre-arguments :
1) Il y a la solution pour les distribs binaires de mettre à dispo pleins de paquets binaires différents (avec ou sans vectorisation) => Mais AMHA ce n'est pas jouable sur le long terme a moins de se restreindre aux paquets vraiments importants pour le multimedia (codecs).
2) L'autovectorisation est peut-être très nulle et elle ne remplacera jamais l'optimisation en assembleur des sources (donc l'augmentation des perfos ne sera pas sensible) => C'est sans doute vrai en grande partie mais visiblement Apple et IBM y croient quand même très fort et contibuent à GCC.
3) Faire des gros binaires autovectorisés avec pleins de chemins dans le code (IF processeur_de_merde THEN code-pourri ELSE code-optimisé) => faut adapter les programmes et en plus c'est crade.
Les apports de GCC 4.0 => [http://gcc.gnu.org/gcc-4.0/changes.html(...)](http://gcc.gnu.org/gcc-4.0/changes.html)