Journal GCC 4.0 et les distributions sources

Posté par  (site web personnel) .
Étiquettes :
0
26
jan.
2005
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(...)

  • # Relativisons un peu ...

    Posté par  . Évalué à 10.

    Déjà, l'optimisation en assembleur des sources, c'est n'importe quoi. Presque plus personne ne le fait, et uniquement sur des portions de code bien précises. Pourquoi ? Simplement parce que les processeurs actuels sont devenus bien trop complexes. Pour optimiser un code, il faut tenir compte de la gestion des caches, de leur nombre et de leur taille, de la prédiction des branchements, des registres shadow (pour les processeurs Intel), ... C'est absolument impossible à faire.

    D'ailleurs souvent, les bouts d'assembleurs (notamment dans le noyau) sont là uniquement parce que ce qu'ils font n'est pas écrivable en C.

    Et en plus, si tu mets de l'assembleur dans tes sources, tu tues la portabilité.

    DONC c'est le compilo qui doit faire tout le travail d'optimisation du code, pas le développeur (je ne parle pas d'optimisation de l'algo sous-jacent).

    Ensuite, dans la plupart des cas, le goulot d'étranglement n'est pas le processeur, mais le disque, la mémoire, etc ... : Je ne pense pas que l'autovectorisation va changer grand chose aux perfs globales du système, mais uniquement à celles de certaines librairies. Et certaines distrib proposeront alors probablement un paquet par famille de proc, comme c'est déjà fait parfois.

    • [^] # Re: Relativisons un peu ...

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

      Déjà, l'optimisation en assembleur des sources, c'est n'importe quoi. Presque plus personne ne le fait, et uniquement sur des portions de code bien précises. Pourquoi ? Simplement parce que les processeurs actuels sont devenus bien trop complexes. Pour optimiser un code, il faut tenir compte de la gestion des caches, de leur nombre et de leur taille, de la prédiction des branchements, des registres shadow (pour les processeurs Intel), ... C'est absolument impossible à faire.
      c'est justement ce qui est marrant :)

      enfin bon les endroits ou la vectorisation est utile, en général ça a deja été fait (en asm ou avec les intrinsics[1])
      mais çà peut etre sympa pour le code a venir: plus besoin de se creuser la tete en assembleur si le compilateur peut generer et optimiser les versions x86/MMX/SSE de lui meme.

      [1] http://www.tuleriit.ee/progs/index.php?rexample=1(...)

      • [^] # Re: Relativisons un peu ...

        Posté par  . Évalué à 3.

        mais çà peut etre sympa pour le code a venir: plus besoin de se creuser la tete en assembleur si le compilateur peut generer et optimiser les versions x86/MMX/SSE de lui meme.

        Ce qui serait bien (je sais pas si c'est deja possible), serait de pouvoir dire au compilateur : cette fonction tu me l'optimise en x86/MMX/SSE puis de pouvoir appeler le code en utilisant par exemple la fonction suffixe de l'optimisation.

    • [^] # Re: Relativisons un peu ...

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

      Mince alors, l'argument qui venait en faveur des gentooistes pensant que compiler faisait grossir les perfs (et rien d'autre hein) de façon énorme est mort né :/

      J'imagine que ce genre de chose rajoute pas mal de traitement, et donc de temps à la compilation... Qui c'est qui va passer encore plus de temps à compiler?

      • [^] # Re: Relativisons un peu ...

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

        En même temps, gcc 4.0 n'est pas encore sorti et d'ici la, la puissance des machines évoluant, l'augmentation du temps de compilation sera absorbée par l'augmentation de puissance.
        De toute façon, gentoo stable utilise encore gcc 3.3 et à part à l'installation, les compilations sont rares.
        Personnellement, je n'ai pas de gentoo pour la performance, mais pour portage et le nombre d'ebuild disponibles ainsi que le travail des développeurs gentoo.

    • [^] # Re: Relativisons un peu ...

      Posté par  . Évalué à 6.

      D'ailleurs souvent, les bouts d'assembleurs (notamment dans le noyau) sont là uniquement parce que ce qu'ils font n'est pas écrivable en C.

      C'est souvent vrai, mais pas toujours...

      Un contre-exemple au hasard : /arch/i386/lib/strstr.c (qui contient de l'assembleur).
      Evidemment, la fonction strstr peut être codée en C sans difficulté, mais c'est assez inefficace.

      Donc, à mon avis, ces histoires d'optimisation du code source en assembleur, pour de gros projets, ça a encore un sens.

      • [^] # Re: Relativisons un peu ...

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

        Tous les codec video ont leur coeur en assembleur SSE ou altivec (DCT et certain teste).

        Cette vectorisation est surtout pour le code "évident" à vectorisé. Donc à moins d'une bonne surprise, il n'y aura rien de terrible par default.

        Par contre, avec qq règles de conception, il est possible d'utiliser ces instructions et là, cela peut changer beaucoup de chose sur la vitesse final du code.

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

        • [^] # Re: Relativisons un peu ...

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

          Tous les codec video ont leur coeur en assembleur SSE ou altivec (DCT et certain teste).

          et donc le mec qui télécharge un paquet i386 pour son beau Pentium 166 Mhz il n'a dans le cul car il n'a pas SSE ?

          Comment ça peut être possible d'avoir un coeur SSE quand tu sais pas si le CPU cible a :

          1) pas de SSE
          2) MMX
          3) SSE
          4) SSE2
          5) SSE3 ?

          • [^] # Re: Relativisons un peu ...

            Posté par  . Évalué à -2.

            Comment ça peut être possible d'avoir un coeur SSE quand tu sais pas si le CPU cible a :

            1) pas de SSE
            2) MMX
            3) SSE
            4) SSE2
            5) SSE3 ?


            J'imagine que de toutes façons, dans ce cas, ou bien tu oublies tout de suite parceque si des parties du programme ont été optimisées, c'est que globalement les traitements sont assez lourds (ex: compression MPEG-4), soit tu compiles toi-même le programme en C pur.

            Dans tous les cas, c'est un faux problème.

          • [^] # Re: Relativisons un peu ...

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

            oula...il faudra que tu regardes un peu de code de temps en temps.

            Soit c'est une option de compilation mais le plus souvent un teste au run time permet de choisir SSE ou mmx

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

            • [^] # Re: Relativisons un peu ...

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

              le plus souvent un teste au run time permet de choisir SSE ou mmx

              ok ça c'est une réponse interessante.
              donc la solution qui se dégage de toutes les réactions sur ce journal c'est :
              - beaucoups de paquets ne nécessitent pas de vectorisation car le facteur limitant est autre (disque dur...etc).
              - pour les paquets critiques (codecs) : ils sont optimisés à la main en assembleur avec des chemins differents choisis au run time (on va vers la branche vectorisé si on a une unité vectorielle et on va vers une autre branche si on a rien).

              très bien cela me semble rationnel !

              néanmoins maintenant je vais aller voir le code source des fameux paquets critiques (FFMPEG et autres) et je suis absolument certain que je ne vais pas du tout voir 213.645 chemins optimisés en fonction des 213.645 possibilités différentes de combinaisons de CPU et d'archis......

              • [^] # Re: Relativisons un peu ...

                Posté par  . Évalué à 2.

                néanmoins maintenant je vais aller voir le code source des fameux paquets critiques (FFMPEG et autres) et je suis absolument certain que je ne vais pas du tout voir 213.645 chemins optimisés en fonction des 213.645 possibilités différentes de combinaisons de CPU et d'archis......

                evidemment que seul les optimisations qui valent la peine (ie apporte un gain substantiel) sont faite. De plus il faut qu'un developpeur s'y soit coller : t'as moins de chance de trouver du code optimiser pour sparc que pour x86.

                Tant que tu y est t'as cas nous faire un benchmark avec les differentes version de gcc 2.x 3.x 4.x et differentes optimisations(cpu), on vraiement si le gain est si enorme que ca pour le code non critique...

              • [^] # Re: Relativisons un peu ...

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

                typiquement tu trouve MMX car cela vécu assez longtemps et SSE tout court car c'est maintenant commun athlon et intel.

                Tu trouve aussi du altivec pour ppc.

                Et c'est aussi pour ça que le x86_64 est pourris pour tout ce qui concerne les codecs. Compiler en mode 64 bits, ils n'utilisent pas les fonctions vectorisé, c'est donc lent.

                Mais j'image que des trucs comme le val_array de la STL devrait être accéléré assez facilement.

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

  • # Bof

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

    Rien n'empeche de compiler les paquets binaires des applis critiques (libc, libs multimedia...) avec les options pour en tirer partie.
    Il existe /lib/i686 avec des libs compilées pour i686 au lieu de i586. On peut aussi avoir des répertoires sse/mmx/... et ld chargera le bon.

    • [^] # Re: Bof

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

      En me relisant je vois que ce n'est pas clair que je répond à "de mettre à dispo pleins de paquets binaires différents". En effet, ce chemin différent permet que ce soit fourni par le même package.

      • [^] # Re: Bof

        Posté par  . Évalué à 2.

        et beurk le paquet de 20 Mo...

        C'est pas mal dans l'idée, mais si c'est juste pour les applis critiques ... autant avoir plusieur paquet.
        Genre glibc-686 et les ntpl

  • # Aie aie aie ! :)

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

    Je vais parler de ce que je connais :)
    Je suis sous gentoo, et j'utilise actuellement gcc 3.3.5.

    Quand je vois tous les problème que le passage vers gcc 3.4.x me pose, je préfère ne pas encore entendre parler de gcc 4.x ! :p
    D'ailleurs, je suis revenu sous gcc3.3.5, et je pense que je vais attendre encore pas mal de temps avant de franchir le pas.

    Cela dit, c'est bien évidement bon, toutes les optimisations sont les bienvenues, bien que je pense que l'on reste dans les moins de 5% de gains. Vu les bécanes qu'on a aujourd'hui, les distrib source n'auront pas un si grand avantage.

    • [^] # Re: Aie aie aie ! :)

      Posté par  . Évalué à 3.

      lwteotdEn même temps, sous Gentoo c'est un demi-problème: faire cohabiter deux (trois, quatre, ...) versions de gcc est absolument indolore, grâce à copain gcc-config.

      • [^] # Re: Aie aie aie ! :)

        Posté par  . Évalué à 4.

        lwteotd

        Ceci n'est pas un mot de passe échoué ici par hasard, mais un bout d'un autre de mes journaux. Si vous ne me croyez pas, vérifiez :)

        (tout ça, c'est la faute aux navigateurs qui filent le focus clavier à tout onglet qui vient de finir de se charger, fut-il au second plan)

      • [^] # Re: Aie aie aie ! :)

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

        En théorie, oui. Dans la pratique, j'ai eu énormément de problèmes de librairies linkées en hard, dépendances cassées, etc .... Je l'ai d'ailleurs lu dans dans de nombreux topics sur les forums de gentoo. Pour l'instant, ca marchotte. J'attend que les derniers bugs soit corrigés.

        De toute manière, gcc 3.4 est en ~x86, donc je ne peux m'en prendre qu'a moi lol !

    • [^] # Re: Aie aie aie ! :)

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

      C'est moi ou le gcc-3.4 il est pas dans la x86?
      Si tu veux l'utiliser il faut tout migrer vers la ~x86 pour que ca ait une chance de suivre ou je me trompe?
      A mois que tu soit en amd64 qui est le seul a avoir gcc3.4.

      • [^] # Re: Aie aie aie ! :)

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

        Oui gcc-3.4 est ~x86 ...
        Mais tu ne dois pas passer totalement en instable (~x86) pour avoir "une chance de suivre".
        Il ne faut passer que 2-3 packages en ~x86 (je ne sais plus lesquelles) et j'ai de temps en temps (rare quand même) un problème de complilation. Un rapport de bug et c'est corrigé.

    • [^] # Re: Aie aie aie ! :)

      Posté par  . Évalué à 4.

      bien que je pense que l'on reste dans les moins de 5% de gains.
      L'article
      http://linuxfr.org/2002/12/07/10578.html(...)
      montre que le changement de compilateur peut induire des gains bien plus élevés. Bon, d'accord, il s'agit d'un comparatif gcc/icc, mais cela montre bien que ces optimisations n'ont rien de négligeable.

      • [^] # Re: Aie aie aie ! :)

        Posté par  . Évalué à 5.

        Ya pas que le gain de perf du binaire, ya également le gain a la compile, et pour les applis c++ ya un énorme gain entre gcc 3.3 et 3.4
        regarder le temps de compile de kde, ou tout autre projet gros projet C++ (voir indépendant de qt, histoire de pas perdre de temps avec moc). Perso jai un gain de 10 à 30% (a voir avec genlop pour les gentoiste)

  • # Repository de plusieurs binaires

    Posté par  . Évalué à -1.


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


    Et pourquoi ça n'est pas jouable ? En fait c'est déjà joué: regardes la Debian. Tu a la maintenance en simultanée de plusieurs binaires pour différentes architectures. Résultat: peu importe ton archi, tu a accès aux mêmes packages, quelle que soit ton archi. Par ex., je viens de passer mon Zaurus (archi arm) sous Debian, et je peux installer exactement les mêmes logiciels que sur mon portable (archi i386). Donc si<\b> la différence entre deux archi est suffisante, il y aura deux distrib binaires différentes. Dernier exemple en date: amd64.

  • # Repository de plusieurs binaires

    Posté par  . Évalué à 2.


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


    Et pourquoi ça n'est pas jouable ? En fait c'est déjà joué: regardes la Debian. Tu a la maintenance en simultanée de plusieurs binaires pour différentes architectures. Résultat: peu importe ton archi, tu a accès aux mêmes packages, quelle que soit ton archi. Par ex., je viens de passer mon Zaurus (archi arm) sous Debian, et je peux installer exactement les mêmes logiciels que sur mon portable (archi i386). Donc si la différence entre deux archi est suffisante, il y aura deux distrib binaires différentes. Dernier exemple en date: amd64.

    • [^] # Re: Repository de plusieurs binaires

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

      déja que Debian peine a sortir la Sarge du fait de pleins d'archi maintenant tu veux en plus :

      - i386 sans rien
      - i386 MMX
      - i386 SSE
      - i386 SSE-2
      - i386 SSE-3

      - PPC32 sans rien
      - PPC32 altivec
      - PPC64 sans rien
      - PPC64 altivec

      c'est ça ta solution miracle ?
      le nombre de possibilités devient exponentiel....c'est grotesque !
      C'est la que les distribs sources prennent tout leur sens : je sais quel est exactement mon CPU donc je met les CFLAGS qui vont bien et hop je compile !
      exactement ce que je disais au début du journal : si GCC devient très bon à l'autovectorisation alors les distribs sources deviendront incontournables.

      • [^] # Re: Repository de plusieurs binaires

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

        Attention, les différentes archis supportées par Debian sont rééllement différentes, avec tous les problèmes de portabilité que ça pose.

        Avoir une "distrib" différente pour les différentes variantes de proc, ça veut juste dire un peu d'espace disque en plus sur les serveurs, mais les softs sont les mêmes !

        Quand a ta définition de l'exponentielle, faudra m'expliquer.

        > GCC devient très bon à l'autovectorisation alors les distribs sources deviendront incontournables.

        Je te rappelle que plus de 90% des ordinateurs de la planête tournent sur un OS et utilisent des logiciels disponibles sous forme binaire uniquement (pour le grand publique). Tu penses que les fabriquants de processeurs optimisent uniquement leurs puces pour les quelques pourcents d'utilisateurs de gentoo a l'intérieur des 5 ou 10 % qui restent ?

      • [^] # Re: Repository de plusieurs binaires

        Posté par  . Évalué à 2.

        > GCC devient très bon à l'autovectorisation alors les distribs sources deviendront incontournables.


        oui, mais bon vu que la majorite des applications standart sont limiter par d'autres facteurs comme les blocages io (reseau, clavier, ...), le gain risque d'etre tres faible en moyenne. Les optimisations seront visible que sur les grosses applis comme les codecs video, or soit ils sont deja optimiser en assembleur a la main et le meilleur code est choisi dynamiquement, soit il existe des paquets optimisees. C'est donc un faut probleme.

        De plus je doute fortement de ces optimisations miracle : icc n'est pas sense etre un compilo qui optimise super bien, pourtant j'ai pas vu grand monde tenter d'essaye de compiler toute une distrib avec pour beneficier des perf...

        Matthieu

    • [^] # Re: Repository de plusieurs binaires

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

      Oui mais tu n'as certainement pas un arbre apt par génération de processeur... t'imagine le boulo que ce serait?

      Entre les myriades de versions de P4 qui sont sorties, les P3, les K6, K7... il faudrait même déifférentes versions pour le AMD64 entre les actuels et ceux qui supporteront le SSE3

      Je ne pense pas qu'il soit possible de maintenir autant de versions différentes en même temps (et encore, je n'ai cité que les archi x86* là)

      • [^] # Re: Repository de plusieurs binaires

        Posté par  . Évalué à 3.

        Oui mais tu n'as certainement pas un arbre apt par génération de processeur... t'imagine le boulot que ce serait?

        Le boulot pour qui ? pour le mainteneur ou pour les autobuilders ?

        Debian supporte 11 architectures et c'est pas beaucoup plus de boulot que d'en supporter seulement 2. Surtout que les problèmes sont dûs aux différences petit/gros boutien ou 32/64 bits.

        Générer un paquet pour chaque version d'i386 de la terre en changant le CFLAGS est automatisable donc un coup humain nul. Le coup machine (temps de recompilation) est quasi négligeable de nos jours.

        • [^] # Re: Repository de plusieurs binaires

          Posté par  . Évalué à 2.

          sauf que chez debian, il teste les paquets....

          Et puis apres le mainteneur il doit supporter toutes les versions...

  • # GCC? What does it means?

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

    GCC comme dans :

    #./toto.c
    sh: Gros Couillon Compiles!

    ou alors comme dans :

    L'autre jour j'ai voulu installer ce <megalogicielaloriginedenombreuxtrolldanscaversioncvs> mais l'autre Gros Con de Compilateur à hurler dans tout les sens qu'ils ne trouvais pas les bonnes lib.

  • # man gcc

    Posté par  . Évalué à 2.

    -mtune=cpu-type
    Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are:

    ...

    While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used.


    Idem pour les autres processeurs. Sans parler de MMX/SSE ou d'Altived (un vrai jeu d'instruction SIMD, pas de la branlette intel), ça permet déjà de paufiner sans casser. Mais bon, Debian est pas chaud pour ça ... ils disent que 3% ça vaut pas le coup.

    • [^] # Re: man gcc

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

      ils disent que 3% ça vaut pas le coup.

      3% avec le GCC 3.x actuel...........mais si avec GCC 4.x on obtient beaucoup plus ça deviendra rentable non ?

      • [^] # Re: man gcc

        Posté par  . Évalué à 0.

        moi je trouve que 3% c'est rentable : une seule personne compile pour des milliers d'utilisateurs.

    • [^] # Re: man gcc

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

      C'est quoi un _VRAI_ jeu d'instruction SIMD ?

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

      • [^] # Re: man gcc

        Posté par  . Évalué à 3.

        Je pense que c'est un jeu d'instruction suffisemment répendu pour que les développeurs aient le courage de développer des branches spécifiques.

        Par exemple, le mmx en est un, contrairement au Altivec.

        Trève de plaisanterie, c'est vrai que l'avantage d'intégrer ces jeux d'instructions à GCC, c'est que même pour des jeux d'instructions peu répendues, le boulot sera fait pour en tirer partie. Parce que si il faut coder la version 32 bits, la version 64 bits, la version MMX, 3D Now, 3D now II, SSE, SSE2, SSE3, Altivec (y'en a plusieurs versions ?) alors les développeurs graphiques sont pas rendus.

        Et puis pourquoi pas la version cartère mère à mémoire double canal, la vesrion avec 2Mo de cache, la version avec 512 ko de cache.... on peut aller plus loin dans le délire encore, le jeu d'instructions n'est qu'un petit aspect de la chose. Style la verson spéciale 512 ko de cache SSE3 révisions D du core du CPU, avec une RAM double canal CAS 2, et puis la version.....

        • [^] # Re: man gcc

          Posté par  . Évalué à 3.

          A quand une version Just In Time Compiler de GCC ?

Suivre le flux des commentaires

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