Journal Comparatif entre Debian compilé contre Debian générique.

Posté par  .
Étiquettes :
0
11
avr.
2007
Attention aux trolls. J'ai réalisé un comparatif de performances entre un système générique et un précompilé à la main.

L'avantage, c'est qu'avec Debian, on peut recompiler à la main tout ou une partie du système pour tenter d'optimiser tout ça, le comparatif a d'ailleurs été réalité avec le même système (je teste d'abord avec le générique, je compile et je re-teste).

Puisque j'ai fais ça pour le site jeuvinux, ça concerne uniquement l'affichage en 3D.

Si vous voulez un résumé, oui on gagne un peu, mais vraiment pas grand chose.
Par contre, peut être que si il était possible de recompiler comme il faut les pilotes graphiques, la différence serait plus marquée.

Pour les amateurs:
http://www.jeuvinux.net/article-125.html

  • # Même en 32bits pas de quoi fouetter un chat

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

    il y a fort à parier que la différence serait plus grande entre un système générique 32 bits (i386) sur une machine i686 (ce qui est le cas de la majorité de nos machines).


    Bah nan, la pluaprt des distribs (même Debian) ne supportent plus que i486 voire i586 :)

  • # ...

    Posté par  . Évalué à 2.

    C'est quoi les options que tu utilise pour recompiler les paquets (quel est la difference avec celle que debian utilise pour ses paquets binaires), quel compilo utilises tu, ...

    Bref, ca serait pas mal de mettre quelques details question de pouvoir reproduire la chose.


    Par contre, peut être que si il était possible de recompiler comme il faut les pilotes graphiques, la différence serait plus marquée.
    J'en suis pas si certains :
    - les parties critiques des drivers sont souvent optimisées a la main en assembleur (cf mesa, ou encore le support SSE, ... du driver proprio nvidia).

    • [^] # Re: ...

      Posté par  . Évalué à 4.

      Les options sont configurés dans apt-build, voici une partie du fichier de conf:


      mtune = -mtune=athlon64
      options = "-march=athlon64 -O2 -pipe"

      C'est pas faux, je vais ajouter ça dans le comparatif.

      Mais si c'est juste pour pouvoir recompiler toi même sur ta machine, pour ton proco, il n'y a qu'une bible, la doc de Gentoo, dont c'est la spécialité:
      http://fr.gentoo-wiki.com/HOWTO_CFLAGS

      Après il te suffit de lire le manuel de apt-build

      (Perso, j'ai mis une liste de paquets dans le fichier /etc/apt/apt-build.list, je tape "apt-build world", je re dans 2-3 heures et c'est bon :)

      Pour info, ça marche aussi pour le noyau, mais pour ma part ça n'a rien changé du tout, sauf que ça a pris 1 heure de mon temps.

      • [^] # Re: ...

        Posté par  . Évalué à 2.

        mtune = -mtune=athlon64
        options = "-march=athlon64 -O2 -pipe"
        Ben mon but, c'etait de comprendre quel est la difference avec les paquets generiques vu que pour le moment en 64 il n'y a pas beacoup d'architecture (athlon64 ou nocona).

        Donc les gains viennent :
        - du -O2 (c'est etrange que les paquageurs n'utilise pas cette option) ?
        - d'une version différente de gcc ?
        - des flags athlon64 (mais j'ai du mal a voir ce qu'il pourrait mettre d'autre) ?
        - ???

        • [^] # Re: ...

          Posté par  . Évalué à 4.

          L'AMD64 (athlon64, opteron, etc.) "gobe" aussi bien du code optimisé pour -march=nocona que pour -march=athlon64. Certaines distributions préféraient alors compiler en -mtune=nocona (affecte le scheduling uniquement), où les gains étaient plutôt sensibles sur les flottants (SSE) sur des processeurs EM64T. De nos jours, tout le monde utilise -mtune=generic qui représente un compromis intéressant pour les deux parties.

          Donc il n'est pas étonnant que les gains éventuels obtenus dans ses tests soient très marginaux (< 2%). En plus, soyons clairs, ça représente 3 fps sur 222. i.e. rien du tout pour ton oeil...

  • # .

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

    Les détracteurs de distributions sources telles que Gentoo parlent de gains de performances comparés aux distributions précompilées de façon générique telles que Debian.

    C'est pas un contresens, ça ?

    • [^] # Re: .

      Posté par  . Évalué à 2.

      Je pense aussi.

      Je pense que le monsieur ne connaît pas la définition de "détracteur" :)

  • # Les améliorations techniques des processeurs.

    Posté par  . Évalué à 3.

    C'est une question qui revient assez souvent, surtout en ce moment avec l'emergence des processeurs 64bits.

    Il y a eu une discussion ici au sujet de l'optimisation ou je demandais l'avantages d'une distribution comme Ubuntu de distribuer sa distribution en 386 et non en 686, sachant que Ubuntu étant orienté clairement « desktop », je la voie mal tourner sur un vrai 386.
    Pour Debian, c'est différent, vu que le but de cette distribution est de fonctionner sur tout ce qui existe.
    J'ai été très longtemps sous Gentoo, j'ai passé beaucoup de temps sur Ubuntu et là, après avoir voulu retesté debian pour me faire une idée, je suis retourné sur Arch qui me plait vraiment beaucoup, mais pour des raisons qui n'ont pas trop d'intérêts dans ce journal.

    Dans mon cas, je n'ai pas trouvé Gentoo plus rapide que Ubuntu. Mais j'ai été très longtemps attaché à cette distribution car pour moi (comme en fait je crois pour beaucoup de Gentoïste, l'intérêt est ailleurs).
    Par contre, j'ai été étonnemment surpris par Arch que j'ai trouvé bien plus réative. Le problème, c'est que ce n'est pas quelque chose de mesurable et même si j'avais fait des benchs, ça ne m'aurais pas dit si c'était du à l'optimisation en 686 de Arch ou l'architecture en elle-même.
    D'où l'intérêt d'avoir fait ton test avec le même système.

    Donc pour en revenir au optimisation (et c'est dur d'avoir des réponses, c'est toujours resté flou pour moi), ça ne me semble pas évident de voir les vrais innovations et les innovations (coup de pub).

    Tu as pris le choix de recompiler ton système amd64 pour l'optimiser. Un test que j'aimerai bien voir, c'est que tu refasses le même test, en installant les mêmes paquets, mais cette fois en 386.
    Je ne suis pas certains que les performances vont baisser énormément.

    Voilà, donc autant dans un sens, je ne vois pas pourquoi continuer à compiler des distributions comme gentoo en 386, autant, j'ai l'impression que les innovations sont maintenant plus déstiné à faire vendre (à moins que ce soit vraiment géré par le processeur en lui-même et qu'il n'y ai rien à optimisé au niveau du code).

    Il n'y a qu'à voir toutes les pubs pour les ordinateurs avec des processeurs 64 bits vendu le plus souvent avec un OS 32 bits.

    Voilà, donc si tu as la motivation de faire ton test aussi en 386 et 686, cela permettrai peut-être de mieux voir quand il y a eu le plus de changement et si il y a une différence notable entre deux.

    • [^] # Re: Les améliorations techniques des processeurs.

      Posté par  . Évalué à 3.

      seginus:

      C'est une bonne idée d'enrichir le comparatif avec la compilation pour i386. Je vais y réfléchir, mais dans un sens, c'est un peu masochiste :)

      En fait, j'ai fais ce comparatif sans arrière pensée, je suis Debianeu, mais je n'ai rien contre Gentoo, ce test a prouvé (à sa petite échelle) que le gain n'est pas énorme.

      C'est vrai que c'est pas une surprise, mais je suis jamais tombé sur de vrai chiffre, c'est ce qui m'a poussé à plancher sur la question.

      Après, comme tu dis, l'intérêt de Gentoo est sans doutes ailleurs, j'imagine qu'il y a une plus fort implications dans son système, ce qui doit être motivant pour certains.

      Un peut comme DFS, j'ai voulu m'y mettre rien que pour ça, mais la flème m'a vite gagnée.

      -------

      Sufflope:
      Je ne sais pas ce dont il en est dans les faits, puisque je suis en x86_64, mais quand tu télécharge l'iso de Etch, ils affichent i386:
      ftp://debian.mines.inpl-nancy.fr/debian-cd/4.0_r0/i386/iso-d(...)

      De plus, j'ai un chroot dans lequel je met des librairies 32 bits pour pouvoir lancer certaines programmes 32 bits.
      J'en prend une strictement au hasard:
      file /emul/ia32-linux/usr/lib/libmad.so.0.2.1
      /emul/ia32-linux/usr/lib/libmad.so.0.2.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped

      "Intel 80386"
      Je pense que l'on peut télécharger un noyau i686 dans le dépot Debian, mais les paquets binaires me semble être compilés pour i386...

      ----------

      ccomb:

      Non j'ai pas l'impression, me suis je mal exprimé ?

    • [^] # Re: Les améliorations techniques des processeurs.

      Posté par  . Évalué à 1.

      Je n'ai pas vu de bench entre le 32 bits et le 64 bits; mais c'est à mon avis la seule modification qui vaut le coup.

      Le mode amd64 dispose de bien plus de registres et lors des appels de fonction, les paramètres sont passés premièrement dans les registres; ce qui doit donner normalement une sérieuse accélération. Logiquement, l'espace d'adressage étant plus gros, une partie des instructions sont plus grosses et le cache du processeur est un poil moins bien utilisé.

      • [^] # Re: Les améliorations techniques des processeurs.

        Posté par  . Évalué à 1.

        Pour les jeux il n'en est rien:
        http://www.jeuvinux.net/article-111.html

        La différence se fait surtout lors de la compilation de logiciel ou de gros calculs, mais pour une utilisation courante, il faut bien admettre que l'X86_64 n'apporte pas grand chose.

        Ou alors il est sous exploité par manque d'optimisations.

        Je me souviens d'un comparatif (impossible de le retrouver) où un gars avait recompilé son noyau sur un système 64 puis 32 bits.
        Et oui, il y avait une différence, mais c'était pas énorme non plus

  • # En optimisant l'optimisation ?

    Posté par  . Évalué à 5.

    et en étant un peu plus 'agressif' ?
    style
    -mtune=athlon-xp -O3 -mfpmath=sse,387 -fomit-frame-pointer -funsafe-math-optimizations -funsafe-loop-optimizations -fdelete-null-pointer-checks -fdelayed-branch -ftree-vectorize -ftree-vect-loop-version -funroll-all-loops -freorder-function -foptimize-sibling-calls -fprefetch-loop-arrays

    Bon j'ai un peu fait mumuse avec le man de gcc donc il y a de forte chance que ca marche pas , mais c'est pour donner une idée. - ps ces options peuvent donner un code qui pourra fournir un résultat incorrect (ffast-math , funsafe-math-optimization).

    • [^] # Re: En optimisant l'optimisation ?

      Posté par  . Évalué à 6.

      Je tourne sous Gentoo, ceci est une partie de mon make.conf. Je vous épargne les USE flags que je met :)

      CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe -finline-functions -fno-ident -mfpmath=387 -falign-jumps=4 -falign-loops=4 -falign-functions=64 -frename-registers -fweb"
      CHOST="i686-pc-linux-gnu"
      CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

      cela fait disons 1 an / 1 ans (an ?) et demi que je tourne avec ces "optimisations". J'y comprend pas grand chose, c'est un ami qui me les a filer. Ca roule, ca plante quasiment pas, ni en compilation, ni en utilisation pour moi.

      Je dis quasiment, car j'ai du retirer une "optimisation" pour compiler un module de Xorg. (et les ebuilds en pratique filtre les optimisations trop agressives)

      La différence de performance en général ? Je pourrais pas vraiment dire. En revanche, je peux attester du gain *important* de performance à l'utilisation et au démarage entre la version OpenOffice-bin (i386) et la version compilée qui prend 10h de compilation au bas mot. (je suis sérieux, compiler OOo sur ma machine, c'est au moins 10h de compilation)

      Je suis relativement nouveau dans le monde de linux et je n'ai pas tester beaucoup de distribution.

      J'ai commencé utiliser mandriva (c'était mandrake 2005 je crois) pendant 2-3 mois, j'ai abandonné. Je comprennais rien de rien aux tutos à l'époque (bon maintenant ca va mieux). Puis j'ai rencontré un pote "pro-gentoo" à la fac, donc je me suis mis dessus, vu que j'avais quelqu'un "en vrai" pour m'aider.

      Je ne regrette absolument pas de mettre mis sur Gentoo. Cela ma permis d'apprendre énormément de choses que je n'aurai pas pu apprendre en passant par une autre distrib orienté "clic and go".

      Maintenant, c'est vrai que j'ai envie de passer à autre chose pour mes prochains PC car je n'ai plus 3 jours (j'exagere) à mettre pour avoir juste un Xorg / XFCE4 / Firefox qui tourne optimiser au petits oignions (pour peut etre pas grand chose).

      Bon c'était ma vie, tout ca pour dire que juste avec "-O2 -fomit-frame-pointer", c'est *tres* léger comme optimisation. sachant que les précompilés sont souvent optimisés déja eux meme pour l'architecture générique de destination. Il n'y aura forcément pas beaucoup de gain de perf en mettant une optimisation "passe partout" tel que celle que tu a utilisée.

      • [^] # Re: En optimisant l'optimisation ?

        Posté par  . Évalué à 5.

        Bon c'était ma vie, tout ca pour dire que juste avec "-O2 -fomit-frame-pointer", c'est *tres* léger comme optimisation.

        Non, sur x86_32, c'est l'essentiel du gain de performances: +15% en moyenne dans mon souvenir. Le reste est du pur "bruit": +1 ou +2.5% max.

        Au fait, -finline-functions par défaut n'est pas une bonne idée car la taille de ton code augmente pas mal. Autant laisser GCC choisir. Pour -frename-registers, outre le fait d'être potentiellement boguée, cette option n'apportera rien sur du x86.

        • [^] # Re: En optimisant l'optimisation ?

          Posté par  . Évalué à 1.

          Oui, je me suis un peu trop avancé.

          Je me coucherais moins bete ce soir avec un make.conf plus court.

          sinon je comprend pas en quoi -O2 -fomit-frame-pointer donne +15% par rapport à un binaire précompilé, je suppose que ces options sont mise par ceux qui préparent / compile les binaires des distro si c'est si efficace.

          Ca ne serait pas plutot -march=archi qui optimise autant par rapport à un précompilé générique ? (enfin meme si le test de cet article tend a prouver le contraire)

          ps : on peut parler en messages privés si tu preferes, j'ai pas mal de question et comme j'ai vu ton cv, je sais que tu as de tres bonnes connaissances en gcc :)

  • # Il n'y a pas que les options du compilateur

    Posté par  . Évalué à 3.

    Il y aussi les options de compilation des logiciels ou des bibliothèques.
    Les séries de --enable/--disable ou --with/--without selon les cas.
    Cela permet parfois de désactiver un certain nombre de dépendances.

    Par exemple à une époque mplayer était compilé avec toutes les options
    activées (smb, SDL, ...) et cela valait le coup de le recompiler en désactivant
    ce qui n'était pas utile sur un poste particulier.

    Autre exemple: Cairo qui par défaut est compilé sans le support de glitz.
    Cela dit je l'ai recompilé avec le support de glitz et je n'ai pas remarqué
    de d'amélioration fulgurante.

    • [^] # Re: Il n'y a pas que les options du compilateur

      Posté par  . Évalué à 6.

      Il y aussi les options de compilation des logiciels ou des bibliothèques.

      Il est clair aussi que ce n'est pas le compilateur qui va auto-améliorer les algorithmes inefficaces de certains développeurs. Par ailleurs, des optimisations à d'autres niveaux (e.g. glibc / DT_GNU_HASH) permettent aussi d'avoir des gains d'un autre ordre, par exemple réduction des temps de chargement des applications dans ce cas-là.

      D'une manière générale, sur du x86 par exemple, il n'est pas raisonnable d'attendre des gains de performances importants uniquement par de magiques incantations du compilateur. Y compris pour l'auto-vectorisation, actuellement.

      Cela dit, sur d'autres architectures type in-order (e.g. ia64, Cell) où la sélection et l'ordonnancement des instructions sont importants, le compilateur peut pas mal aider. e.g. sur Cell, -mtune=cell (+ -mno-gen-microcode, implicite sur certains compilateurs) permet des gains en moyenne de +10% et des peaks à +34%. En outre, ça aide les applications multithreadées.

  • # Un compilation de lien pas optimisé... :)

    Posté par  . Évalué à 6.

    Dans mes favoris, j'ai trouvé ça qui pourrait interesser les curieux.

    Pour ceux que ça interesse et qui ont une journée à perdre:
    http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcc/

    Une joli image vaut mille liens:
    http://www.linuxjournal.com/articles/lj/0131/7269/7269t1.png

    Pour ceux ayant 5mn à perdre, c'est tres interessant...!
    http://www.linuxjournal.com/article/7269

    et un tableau qui explique des trucs sur des machins:
    http://gentoo-wiki.com/CFLAGS_matrix

    Voila voila, n'hesitez pas à partager d'autre zoliiii liens qui
    feront chuter ma productivité...!

  • # Interessant ...

    Posté par  . Évalué à 1.

    Et qu'est ce que cela donne avec autre chose que des jeux ?
    Par exemple temps pour decompresser un gros fichier gzipé, ou pour compiler un noyau linux.

  • # kevin was here

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

    L'avantage, c'est qu'avec Debian, on peut recompiler à la main tout ou une partie du système pour tenter d'optimiser tout ça, le comparatif a d'ailleurs été réalité avec le même système (je teste d'abord avec le générique, je compile et je re-teste).


    <mauvaizesprit>
    waouh, il a l'air trop puissant ton linux, tu me le prêtes ? moi chuis sous oubountou et j'aimerais bien faire pareil...
    </mauvaizesprit>

Suivre le flux des commentaires

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