Journal Linux, Gentoo, et gcc dans un bateau...

Posté par .
Tags : aucun
20
5
nov.
2009
Tous les développeurs de la terre (dans l'espace, c'est parfois différent, surtout dans l'espace intersidéral, mais ce n'est le sujet de ce journal), ou presque, aime les performances.

Or, gcc permet beaucoup, même si il est parfois difficile de choisir quel type d'optimisation utiliser. Et c'est ainsi que le site [http://www.linux-mag.com/id/7574/1/] nous propose un beau comparatif de systèmes compilés utilisant des degrés d'optimisations divers pour identifier leurs performances.

Par forcement représentatif de la réalité, ce test grandeur nature nous permet de voir quelques petites choses assez intéressantes.

Ainsi, nous avons 3 systèmes gentoo tournant avec les mêmes logiciels, ainsi que sur le même matériel, mais compilé avec les options -Os (O2 + size optimisation), -O2 et -O3. A titre de comparaison pas forcement pertinent, nous avons un système Ubuntu 9.04 avec un kernel plus vieux (2.28 vs 2.30), un java différent, et X.org différent, et des drivers nvidia différents, mais utilisant gcc 4.3.3 comme gentoo.

Si certains résultats sont très proche, quelque soit le système ou l'optimisation, il est intéressant de noter que certains écarts sont véritablement important et significatif. Les résultats proche semblent (je n'en sait rien) être plus limité au niveau disque dur (les I/O sont plus importantes) que calculs.

mencoder par exemple, est presque deux fois plus rapide avec les optimisations core2 et le nouveau kernel alors que les optimisations de gcc ne lui apporte pas grand chose.

Ce qui, de mon coté, m'a le plus étonné, c'est que -O3 est souvent plus lent que -O2, et que ce même -O2, même si c'est le plus efficace, est parfois battu par un -Os, alors que ce dernier n'utilise pas toutes les optimisations (C'est un -O2 sans -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version).

Donc dans ce cas, est-ce le cache qui joue un rôle important? (Les différences sont en effet assez importante, lorsque -Os est efficace. D'ailleurs, dans ce cas, les optimisations en -O3 sont souvent les pire.

Bonne lecture à tous.
  • # Question

    Posté par . Évalué à 10.

    Mais qui tombe à l'eau ?

    Désolé.
    • [^] # Re: Question

      Posté par . Évalué à 0.

      A mon avis, GCC, parceque lorsqu'une optimisation rend le code plus lent, ce n'est guère pertinent.

      On remarque donc que gcc n'arrive pas à faire correctement son travail d'analyse de code, et se rendre compte que ce dernier, trop gros, amputera les performances.

      Ce n'est que mon avis.
      • [^] # Re: Question

        Posté par (page perso) . Évalué à 7.

        Rend plus lent... Pas vraiment... Il n'y a pas de comparaison avec des versions sans aucune optimisation...
      • [^] # Re: Question

        Posté par . Évalué à 2.

        A mon avis, GCC, parceque lorsqu'une optimisation rend le code plus lent, ce n'est guère pertinent.
        Ben le pb, c'est que gcc a tendance a inline a fond en -O3 et qui est nefaste pour les caches.
        • [^] # Re: Question

          Posté par . Évalué à 2.

          Cette analyse est beaucoup trop légère. La plus part du temps, l'inling _réduit_ la taille du code. Une fois le code inliné, il y a la passe de simplification de code qui vire l'inutile.

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

  • # A chaud.

    Posté par (page perso) . Évalué à 2.

    > A titre de comparaison pas forcement pertinent, nous avons un système Ubuntu 9.04 avec
    > un kernel plus vieux (2.28 vs 2.30), un java différent, et X.org différent, et des drivers
    > nvidia différents, mais utilisant gcc 4.3.3 comme gentoo.
    >
    C'est fait sur la même machine au moins ? :)
    • [^] # Re: A chaud.

      Posté par (page perso) . Évalué à 2.

      De toute façon Ubuntu n'étant pas recompilé spécialement pour la machine de test les benchs à ce niveau ne montrent qu'une seule chose. Quand on compile pour la machine les performances sont meilleurs, ce qui est une évidence en soit. Faudrait aussi savoir si d'un côté c'est bourré de symboles de debuggage et pas de l'autre. C'est facile de descendre les perfs avec des `-g` en parallèle à des `-O2`. Ce qui est sûrement le cas chez Ubuntu. A vérifier..
      • [^] # Re: A chaud.

        Posté par . Évalué à 5.

        C'est facile de descendre les perfs avec des `-g` en parallèle à des `-O2`.
        Tu as des sources ?
        Au dernière nouvelle -g n'ajoute que des symboles de debug, et ne modifie pas les optimisation.

        Par contre ubuntu on tendance a compiler avec -fstack-protector qui n'est pas transparent.
        • [^] # Re: A chaud.

          Posté par (page perso) . Évalué à 2.

          Ma dernière source date de longtemps.. j'avais réécrit le script Perl ndiswrapper en C pour le projet GeeXboX (car on intègre pas l'interpréteur Perl). Et comme un con je testais les différences de vitesse pour parser les fichiers .ini entre le script Perl et mon code en ayant gardé le flag -g et j'en revenais pas d'être à peine plus rapide. J'ai refais en le supprimant, et j'ai gagné bcp de temps à l'exécution.

          Quand je parle de temps c'est des ordres de grandeur dans les centaines de millisecondes. Ça date de longtemps (quelques années) je n'ai plus trop les valeurs en tête.

          Mais je n'ai pas de documents pour appuyer mes dires.
  • # dbench

    Posté par . Évalué à 2.

    Un des tests les plus impressionnant :

    +100% !
    http://s.linux-mag.com/i/articles/7574/14-gentoo-optimizatio(...)

    Ici, c'est 10% + rapide en -Os:
    http://s.linux-mag.com/i/articles/7574/31-gentoo-optimizatio(...)

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

    • [^] # Re: dbench

      Posté par (page perso) . Évalué à 6.

      J'avais déjà joué avec -Os sur des benchs en Lisaac (donc du C au bout), et j'avais remarqué que c'était souvent le plus rapide.

      Le débat porte donc sur le fait que code plus court = code tenant mieux dans le cache code du processeur, donc meilleur exécution...

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: dbench

        Posté par (page perso) . Évalué à 5.

        Quand on regarde les benchs, on est tenté de dire que ce sont dans les cas où la taille de code est importante que -Os donne de meilleur résultats, ce qui est logique.
        Si la boucle critique tiens dans le cache, alors -O3 peut être meilleur

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: dbench

        Posté par (page perso) . Évalué à 2.

        >> Le débat porte donc sur le fait que code plus court = code tenant mieux dans le cache code du processeur, donc meilleur exécution...

        Des générations entières de programmeurs Fortran à la belle époque te remercie d'avoir rappelé le lien fort entre optimisations et matériel, notamment taille des caches du processeur.


        -- 
        Axioplase, qui avait eu un TP sur l'optimisation de code fortran dans un cours orienté compilation et matériel ^^
        • [^] # Re: dbench

          Posté par . Évalué à 3.

          euh ?!

          C'est un peu évident, non ?

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

          • [^] # Re: dbench

            Posté par (page perso) . Évalué à 4.

            Ben, perso, moi qui ne suis pas *du tout* orienté matos, j'ai découvert ça avec le TP en question à l'époque. J'ai des préoccupations différentes quand je fais un programme, et du moment que mon algo est de même complexité que la solution optimale théorique, je suis content. La tenue des données en cache, c'est tellement rarement l'un de mes soucis que j'ai vite fait de n'en avoir plus rien à faire.

            Évidemment, ça dépend de l'industrie dans laquelle tu travailles (et pour avoir lu ton parcours, je me doute bien qu'à toi, ça te parait évident), mais c'est à mon avis une évidence et un critère de développement pour moins de la moité des programmeurs.

            D'autant plus que ce sont des optimisations qui ne sont pas forcément algorithmiques et qui ne sont valides que dans certains langages bas-niveau…
            • [^] # Re: dbench

              Posté par . Évalué à 4.

              En fait c'est exactement le problème que je rencontre parfois avec certaines personnes : on leur explique (par exemple) que le seul moyen de piger où se trouve le goulot d'étranglement dans leur programme n'est plus dans l'algo, mais dans le code asm lui-même (comprendre ce qu'a fait le compilateur, etc.), et ils préfèrent améliorer les constantes de leurs algos plutôt que de se dire « si on faisait ça mieux, ça tiendrait dans les caches d'instruction/de données »...
              • [^] # Re: dbench

                Posté par . Évalué à 4.

                C'est toujours la différence entre algorithmie et implémentation.

                Une fois que tu as le bon algo, tu peux optimiser. L'implémentation doit permettre un gain de x10 maximum, c'est moins que l'algo mais c'est tout de même à prendre :)

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

                • [^] # Re: dbench

                  Posté par . Évalué à 7.

                  En effet, voire plus.

                  Pour illustrer ça, voici deux codes qui calculent exactement la même chose (un crible d'Eratosthene, un des plus anciens algorithmes s'il en est :-) D'un point de vue algorithmique tout se passe de la même façon, d'un point de vue calculs ils sont très différents.

                  crible basique :
                  http://www.joux.biz/algcrypt/PROGRAMS/Sieve_4-1.html

                  crible par petits morceaux de 16ko tenant largement dans le cache L1
                  http://www.joux.biz/algcrypt/PROGRAMS/Sieve_4-2.html

                  Sur un intel atom N270 (1.6GHz), la différence est flagrante pour les tailles les plus grosses : (tous deux sont compilés avec gcc 4.3.4 -O3 ; avec gcc-4.4.2 on gagne à peu près 5 à 8 % dans les deux cas)
                  time ./cache_sieve > result
                  1234567890
                  real 0m53.146s
                  user 0m48.663s
                  sys 0m0.164

                  time ././basic_sieve > result
                  1234567890

                  real 2m43.930s
                  user 2m29.473s
                  sys 0m3.760s

                  (je vous recommande de rediriger la sortie vers un fichier pour bien mesurer le temps de calcul, sinon tout sera pollué par le temps d'affichage dans la console).

                  Notons que les accès mémoire du crible d'Eratosthene basique sont relativement simples, et sans doutes faciles à prédire et donc à optimiser par le compilateur et les mécanismes de prefetch du processeur. Dans des applications plus complexes, le gain d'une implémentation optimisée serait certainement encore plus important.
                  • [^] # Re: dbench

                    Posté par . Évalué à 5.

                    je vous recommande de rediriger la sortie vers un fichier

                    Comme fichier, /dev/null est une bonne idée (élimine les aléas des E/S).
  • # Interface graphique

    Posté par (page perso) . Évalué à -2.

    Et pour une interface graphique (avec plein de boite de dialogue, quelque traitement tache de fond) et une expérience utilisateur optimal quel sont les meilleurs options ?

    Y-a-t-il des benchs d'interface graphique?
  • # Le noyau fausse tout

    Posté par . Évalué à 9.

    Vu les performances variables des différents noyaux Linux, le simple fait de ne pas utiliser les mêmes version fausse complètement les comparatifs.

    Pour ne prendre que le noyau 2.6.31 comme exemple, les patchs de Mel Gorman (concernant l'allocation mémoire) ajouté au aurait amélioré les performances de 3 à 30%.

    Voir http://linuxfr.org/2009/09/10/25848.html

    Enfin, sur Gentoo, mencoder (distribué avec mplayer) bénéficie de plusieurs optimisation liées au CPU (MMX, SSE2 notamment) ou au GPU qu'Ubuntu ne propose probablement pas pour rester compatible avec la famille i386.

    P.S. : je n'ai pas vu passer la news sur Gentoo 10 (et 10.1), les dix ans de la distribution et la sortie d'un nouveau live DVD.
    • [^] # Re: Le noyau fausse tout

      Posté par . Évalué à 6.

      [ ...]A titre de comparaison pas forcement pertinent, nous avons un système Ubuntu 9.04 [...]

      C'est étrange tous ces commentaires sur ubuntu et cie alors que ce n'est pas le sujet.

      Là, c'est juste "pour comparaison", mais le vrai test/bench est dans les 3 versions de gentoo. Et c'est là qu'on voit des grosses disparités. Donc c'est bien le même noyau. C'est très bien précisé dans le journal.
      • [^] # Re: Le noyau fausse tout

        Posté par . Évalué à 1.

        Oui, mea maxima culpa. J'ai répondu beaucoup trop vite.

        Ils auraient mieux fait de ne pas inclure Ubuntu dans leurs tests pour empêcher l'ouverture de la boïte à trolls dans laquelle j'ai plongé à pieds joints.

        Un beau sac d' -Os, tout ça.
    • [^] # Re: Le noyau fausse tout

      Posté par . Évalué à 3.

      sur Gentoo, mencoder (distribué avec mplayer) bénéficie de plusieurs optimisation liées au CPU (MMX, SSE2 notamment) ou au GPU qu'Ubuntu ne propose probablement pas pour rester compatible avec la famille i386.

      Il me semblait que mplayer détectait justement le processeur à l'exécution et d'activer les opérations MMC SSE & Co à l'exécution ?
      • [^] # Re: Le noyau fausse tout

        Posté par . Évalué à 2.

        Oui et non. Pour obtenir ce comportement (lors de l'exécution du programme) sur Gentoo il faut activer l'option « cpudetection ».

        L'option « custom-cpuopts », quant à elle permet d'outrepasser la détection des caractéristiques du CPU lors de la compilation.
  • # Cela confirme ce que je pense

    Posté par (page perso) . Évalué à 10.

    Vu les résultat qui bien souvent se tienne dans un mouchoir de poche, tout le temps que je gagne parce que je ne compile pas toutes mes logiciels sur ma distribution orienté binaire, je ne le perd pas franchement a l'utilisation quotidienne. En gros pour une machine de monsieur et madame tout le monde la différence est largement négligeable.

    Bref si un jour je veux monter un cluster d'encodage vidéo je regarderai un peu mieux gentoo mais en attendant je reste avec mes bons vieux paquets binaire.
    • [^] # Re: Cela confirme ce que je pense

      Posté par (page perso) . Évalué à 2.

      Le journal ne parle pas de Gentoo mais des options de gcc et de leur impact. Gentoo n'est utilisé que comme plateforme technique.
      • [^] # Re: Cela confirme ce que je pense

        Posté par (page perso) . Évalué à 4.

        Je parle de Gentoo mais j'aurai pu citer Crux, LFS, FreeBSD ou autre pour dire : Sur un poste de travail traditionnel, l'apport du à la compilation est négligeable par rapport a du paquet binaire traditionnel !
        • [^] # Re: Cela confirme ce que je pense

          Posté par . Évalué à 5.

          Bon, ce que je dis n'est pas forcement juste, j'ai précisé précédemment que c'était juste pour voir, mais si tu avais regardé la comparaison pour de vrai, certaines différences sont tout bonnement énorme.

          Pour la lecture du x264, on passe d'une utilisation en pointe de 26% à 18%. C'est loin d'être négligeable pour l'utilisateur lambda.

          Sur un rendu PovRay, on passe de 1400 secondes (1/2 heures) à 900 secondes (20 minutes). La différence est énorme.

          Sur Graphic Magic, on passe de 79 itérations à 88 itérations par minutes. Si je veux redimensionner 500 images en déchargeant mon appareil photo, je gagne une petite minute.

          Avec gtkPerf, qui dessine un certains nombre de widget et calcul le temps total, on passe 600 secondes à 350 secondes, c'est énorme (plus de 1100 pour ubuntu). Donc c'est plus rapide à l'écran.

          De plus, comme expliqué plus bas (et plus haut), gentoo, ce n'est pas pour les performances qu'on l'utilise, mais pour sa souplesse. Et le sujet du journal n'était pas gentoo VS ubuntu, ou plus généralement, compilation contre binaire, mais les possibilités d'optimisations en utilisant uniquement le compilateur. Et c'est assez énorme.

          Il suffit de regarder les temps de compilation également. Passer de 34 secondes à 41 pour compiler le même programme, c'est une belle amélioration très visible.
          • [^] # Re: Cela confirme ce que je pense

            Posté par (page perso) . Évalué à 1.

            Quand je regarde une vidéo, qu'elle soit HD ou non j'ai rarement des truc qui consomme des ressources derrière donc je trouve l'impact négligeable.

            Je suis plus qu'un utilisateur type Madame Michou et pourtant j'ai jamais utilisé povray.

            Graphic Magic, je ne sais pas si ça a un rapport avec ImageMagik que j'utilise mais je suis sur que madame michou ne l'utilisera jamais.

            GTKPerf, pour avec des rendu de 600s, ils ont du en lancé des widget car sur un rendu classique la différence est négligeable encore une fois.

            Je ne doute pas des qualités de souplesse de gentoo : je fais juste un constat comme quoi une distribution binaire pour des besoins simple n'a finalement pas des performances trop ridicule en détournant un peu les résultat donné dans cette étude basé sur les gains de performance fait avec des optimisation gcc.
            • [^] # Re: Cela confirme ce que je pense

              Posté par . Évalué à 4.

              Graphic Magic, je ne sais pas si ça a un rapport avec ImageMagik que j'utilise mais je suis sur que madame michou ne l'utilisera jamais.


              Pas sûr qu'elle ne l'utilisera pas sans s'en rendre compte : les logiciels de gestion de photos à la Gwenview sous Kde permettent des traitements par lot d'opérations simples (comme le redimensionement justement) avec une interface clickodrome sympa et tout. Ça n'utilise sans doutes pas graphic magic ni imagemagik, mais des programmes similaires. On peut donc s'attendre à ce qu'elle bénéficie du même genre d'amélioration des performances.
          • [^] # Re: Cela confirme ce que je pense

            Posté par . Évalué à 8.

            1400 secondes (1/2 heures) à 900 secondes (20 minutes)

            Hum, tu as des heures de 2750 secondes ?
            Les rapports sont les mêmes (36 % de moins) mais c’est quand même mieux avec des heures de 3600 secondes, et des minutes de 60 secondes ; ça donne 1400 s = 23 min, 900 s = 15 min.
      • [^] # Re: Cela confirme ce que je pense

        Posté par (page perso) . Évalué à 5.

        Le journal ne parle pas de Gentoo mais des options de gcc et de leur impact. Gentoo n'est utilisé que comme plateforme technique.

        Mais je ne suis pas certain que compiler toute la distribution avec les mêmes options soit très pertinent. Je ne connais absolument rien aux options des compilateurs. Je peux néanmoins m'imaginer que certaines options seront plus efficaces que d'autres sur un code donné et que ça sera l'inverse sur un autre. Il faudrait connaître les options logiciel par logiciel.
        • [^] # Re: Cela confirme ce que je pense

          Posté par . Évalué à 3.

          Le mieux c'est en fait d'utiliser les outils de profilage de code à la gcov.
          Selon le manuel de gcc lui-même (si jamais vous l'avez installé à partir des sources), ils annoncent tout de go une augmentation de la vitesse de compilation de 7% rien qu'en activant ce switch.
          Par contre ça a l"inconvénient de nécessiter une passe de compilation supplémentaire dans le cas de gcc, et des tests représentatifs dans les autres cas.

          Quand on développe un code on réalise toujours quelques tests pour s'assurer des gains de performance quand on optimise une partie critique, il ne doit pas falloir beaucoup de travail pour les fournir proprement et ainsi être en mesure d'optimiser à fond grâce à gcov les parties du code les plus sensibles.
    • [^] # Re: Cela confirme ce que je pense

      Posté par (page perso) . Évalué à 2.

      Oui, est en plus, tous ces processeurs qui passent des heures à compiler, c'est pas écologique... :)

      Dommage qu'on ne puisse pas avoir une estimation de la consommation électrique moyenne annuelle de chaque distro.
      • [^] # Re: Cela confirme ce que je pense

        Posté par (page perso) . Évalué à 3.

        Plus sérieusement, l'impact de l'optimisation sur la consommation électrique eut été plus intéressant. Ex: si ça va plus vite, est-ce que ça consomme plus ou moins ?
        • [^] # Re: Cela confirme ce que je pense

          Posté par (page perso) . Évalué à 2.

          D'un autre coté, hormis quelques contextes bien particulier ...
          Nos machines passent leurs temps à nous attendre ... et donc, le niveau d'optimisation ne change pas grand chose ...

          Une chose et dommage, c'est qu'ils n'ont testé que gcc. Je sais bien que c'est le compilateur libre mais je me dis que cela pourrait être intéressant de voir si un compilateur comme Icc ne permet pas de gagné un peu plus de performance. Après je dis cela comme cela, je n'ai jamais essayé de compiler un kernel avec Icc ...

          ++ Beleys
          • [^] # Re: Cela confirme ce que je pense

            Posté par . Évalué à 6.

            Nos machines passent leurs temps à nous attendre ... et donc, le niveau d'optimisation ne change pas grand chose ...

            Ben si, parce qu'elles consomment moins quand elles attendent.
        • [^] # Re: Cela confirme ce que je pense

          Posté par . Évalué à 2.

          En général (c’est-à-dire à moins de l’empêcher), quand un programme utilise ton CPU, il l’utilise à fond. Donc si ça va plus vite, le CPU est moins longtemps à fond. Le CPU aurait donc la possibilité de rester plus longtemps en mode économique (fréquence et tension réduites).
          Après, il faut voir si c’est vraiment le cas ; p.ex. si le CPU est utilisé trop régulièrement à fond et qu’il n’a pas le temps de vraiment descendre en mode économique, ça ne sert à rien.
          • [^] # Re: Cela confirme ce que je pense

            Posté par . Évalué à 2.

            Sauf que si ton programme a été optimisé et que du coup il utilise plus d'unités fonctionnelles à la fois (et donc rend le temps de calcul plus court), est-ce qu'il ne fera pas monter la consommation électrique du CPU ? :)
            • [^] # Re: Cela confirme ce que je pense

              Posté par . Évalué à 3.

              Peu : vu tout le marketing qu'on fait les fabricants de CPU pour expliquer que maintenant, les cores pouvaient être désactivés indépendamment s'ils n'étaient pas utilisés (id est un calcul monothread ne fera pas activer l'ensemble des 4 cœurs si 4 cœurs il y a), à mon avis s'ils réussissaient à désactiver carrément certaines unités à l'intérieur de chaque core ils en feraient une publicité monstre.

              En plus ça doit être extrèmement difficile de désactiver certaines unités pendant un calcul, car les transitions entre activité et inactivité donc réduction d'énergie possible sont très très courtes ! Quand on voit qu'un CPU met selon powertop quelques centaines de µs à changer d'état, on se dit que ce n'est pas gagné : en 100 µs un CPU a calculé 100 000 instructions, ce qui est énorme.
              • [^] # Re: Cela confirme ce que je pense

                Posté par (page perso) . Évalué à 5.

                Ça me rappelle cet article de Matthew Garrett, qui disait que la bonne politique de gestion de la fréquence CPU était d'aller le plus vite possible quand il y avait un peu de boulot, plutôt que d'aller à une fréquence moyenne et rallonger le temps de calcul. En gros c'est du tout ou rien : tu te donnes à fond ou tu glandes.
                http://mjg59.livejournal.com/88608.html
            • [^] # Re: Cela confirme ce que je pense

              Posté par . Évalué à 5.

              Tu es entrain de mélanger la puissance et l'énergie.

              En gros, un code optimisé pourra demander une puissance crête plus forte, mais la consommation pour une opération donnée sera plus faible (énergie total).

              De toute façon sur les process modernes, la conso statique est la plus forte. Donc, la consommation est directement proportionnel à la taille du chip x tension d'alim.

              Donc, le but est d'aller le plus vite possible pour diminuer la tension et couper l'horloge.

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

  • # « gentoo is not about performance »

    Posté par . Évalué à 10.

    gentoo is not about performance
    http://lwn.net/Articles/359617/

    Voir les commentaires sur cette même nouvelle sur lwn. Les utilisateurs de gentoo ne cherchent pas à gagner un demi-pourcent en vitesse. On rappelle que le système de gestion de paquets de gentoo est basé sur celui de BSD et personne ne se moque des gens de BSD en disant qu'ils cherchent à gagner en vitesse.

    L'objectif d'un utilisateur de gentoo au hasard (ceux qui commentent sur lwn ; moi...) :
    * contrôler les dépendances, ce qu'on installe ou pas. P.ex. mon back-end pour phonon est xine, alors qu'une autre distribution aurait pu m'« imposer » gstreamer ; j'utilise uniquement mysql, je n'ai pas besoin que mes logiciels supportent postgres, etc.
    * contrôler les versions des bibliothèques installées ; possibilités d'upgrade et downgrade de n'importe quelle bibliothèque si une fonctionnalité manque ou un problème se présente
    * avoir un outil pour résoudre les bugs : j'ai la source de mon système, je peux trivialement le modifier et le recompiler [oui, c'est aussi très facile sous Debian, mais Debian me limite aux versions des bibliothèques livrées avec la distribution.]

    * une ligne et un framework d'administration sans comparaison ;
    * documentation web excellente. Vraiment.

    Certaines personnes ont suggéré qu'il n'y avait pas de valeur ajoutée par rapport à d'autres distributions déjà existantes :
    * Slackware : « sa politique est de n'inclure que des applications stables. » (WIkipédia). Bon, pas pour moi.
    * Fedora Rawhide : Je ne veux pas être victime des expérimentations de Red Hat
    * Debian : soit distribution versionée soit une branche instable. Gentoo permet de choisir son dosage entre les deux : combiner les avantages d'une distribution rolling et d'une distribution stable (90 de ma machine est sur la branche stable, les 10 % restant sont les versions les plus récentes des logiciels et bibliothèques dont je veux profiter des nouvelles fonctionnalités)
    • [^] # Re: « gentoo is not about performance »

      Posté par . Évalué à 5.

      Pertinentage pour ce commentaire.

      J'ai utilisé Gentoo comme distrib principale pendant plusieurs années. C'est pas le fait d'avoir une distrib optimisé (sous entendu "pour la vitesse") qui me l'a fait essayer ou y rester, mais :

      1. Mieux comprendre comment fonctionne Linux (GNU/Linux), cay bien
      2. Avoir une distrib optimisé, pas pour la vitesse, mais pour mes besoins (viva portage)
      3. L'efficacité des outils d'administration
      4. La documentation
      5. Si on oubli les Roxx0r, la communauté
      6. La création d'ebuild perso, vraiment simple

      Je pense que la majorité des utilisateurs de Gentoo le sont pour ces raisons, pas pour la fausse idée des Kevin/Rebelz/Haxx0r/etc... que Gentoo==Distrib de "l33t qui kiff trop la vitesse"
    • [^] # Re: « gentoo is not about performance »

      Posté par (page perso) . Évalué à 0.

      Voir les commentaires sur cette même nouvelle sur lwn. Les utilisateurs de gentoo ne cherchent pas à gagner un demi-pourcent en vitesse. On rappelle que le système de gestion de paquets de gentoo est basé sur celui de BSD et personne ne se moque des gens de BSD en disant qu'ils cherchent à gagner en vitesse.

      Emerge basé sur pkgsrc ? Tu es bien sur de ce que tu avances ?

      pkgsrc est codé en C et emerge en python. Déjà deux bonnes grosses différences. Ensuite les ebuild sont 100% incompatible avec pkgsrc et les makefiles sont 100% incompatible avec emerge.
      Et pour finir il suffit de voir la FAQ d'OpenBSD qui conseil d'utiliser les paquet binaire via les pkg_tools ou NetBSD qui intègre pkgin qui est un apt-like version pkg_tools.

      Emerge est une écriture from scratch s'inspirant de concept venant du pkgsrc forké par FreeBSD (oui FreeBSD tout comme OpenBSD maintiennent leur propre version de pkgsrc avec quelques différences dans le fonctionnement de l'outils). Personnellement je préfère pkgsrc pour sa simplicité mais d'autre préfère Emerge qui embarque plein d'option permettant aussi de faire le café.

Suivre le flux des commentaires

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