Journal FreeBSD 7.0 arrive...et il a les crocs !

Posté par  (site web personnel) .
Étiquettes :
0
30
oct.
2007
Kris Kennaway, un développeur FreeBSD, vient de publier un très intéressant document sur toutes les nouveautés qui seront présentes dans la version 7.0 (attendue avant la fin de l'année).

http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf

Des benchmarks de base de données sont proposés dans le pdf (PostgreSQL et MySQL).
Bien entendu il faut prendre ces benchmarks avec une pincée de sel car c'est un dev FreeBSD qui rapporte ces résultats. Il faudra attendre un peu pour que quelqu'un reproduise ces tests et confirmeles résultats.
La diapo 17 compare divers OS et notamment FreeBSD 7.0 et Linux 2.6.22. On voit que les performances de Linux se dégradent quand on dépasse les 8 threads (sur une machine octo-core) alors que FreeBSD reste complètement linéaire.
La synthèse proposée dans le document est que "2.6.22 is still 15% slower than FreeBSD 7.0".

Si on s'interroge sur les perfs du nouveau scheduler présent dans le noyau 2.6.23 on en a pour son argent question ironie : "The new CFS scheduler in 2.6.23 is “Completely Fair”...to FreeBSD"

Après la liste de toutes les nouveautés, Kris Kennaway termine ainsi :
"FreeBSD 7.0 brings FreeBSD back to the forefront of OS performance on modern hardware (it’s good to be back)."

C'est donc clairement un défi qui est lancé aux développeurs de Linux. On attend leur réponse avec impatience.
  • # Ouais mais ...

    Posté par  . Évalué à 2.

    Moi je me demande toujours à quel film fait référence cette affiche : http://www.openbsd.org/images/openbsd37_cover.gif (bon c'est open, pas free là mais ca reste BSD)
  • # Linux

    Posté par  . Évalué à 9.

    > La synthèse proposée dans le document est que "2.6.22 is still 15% slower than FreeBSD 7.0".

    La glibc avait un petit problème. Sinon Linux est équivalent à FreeBSD si on utilise malloc de Google (désolé, je ne connais pas le pourquoi du comment).
    Le "problème" n'est pas Linux mais la glibc (et pour certains benchs).
    Linux avec tcmalloc est même un poil plus rapide que FreeBSD ou NetBSD :
    http://www.netbsd.org/~ad/sysbench2/4cpu.png
    Je crois que le problème de la glibc a été corrigé.

    > Si on s'interroge sur les perfs du nouveau scheduler présent dans le noyau 2.6.23

    Premièrement, le scheduler est récent. Depuis combien de temps FreeBSD est en train de bichonner la version 7.0 en faisant une fixation sur un bench ?

    En parcourrant rapidement le pdf, il y a un comparatif avec le noyau Fedora 8. Fedora 8 qui n'est pas sorti ! Ce n'est pas un 2.6.23 final. Fedora a pour habitude d'avoir des options de debug dans les phases de test ! Ce qui est tout à fait normal.

    > La synthèse proposée dans le document est que "2.6.22 is still 15% slower than FreeBSD 7.0".

    On en connait pas exactement les conditions du bench.
    http://kerneltrap.org/Linux/Measuring_Process_Scheduler_Perf(...)

    > Si on s'interroge sur les perfs du nouveau scheduler présent dans le noyau 2.6.23

    Le 2.6.23 est plus rapide que le 2.6.22 (et le 2.6.22 est au moins aussi rapide que FreeBSD (voir le lien plus haut) :
    http://people.redhat.com/mingo/misc/sysbench-sched-devel.jpg

    Donc il n'y a pas de problème avec Linux ou CFS ou autre.

    Par contre, il faut bien regarder les conditions du test. Un développeur a un FreeBSD aux petits oignons et compare avec un Linux "stock" ou un Linux de debug de Fedora.
    Je ne crois pas qu'il y a malveillance, mais il faut bien avoir en tête les conditions du bench.

    Les écarts entre FreeBSD et Linux sont faibles. Chapeau à FreeBSD.
    • [^] # Re: Linux

      Posté par  . Évalué à 3.

      > Je crois que le problème de la glibc a été corrigé.

      Il a été corrigé dans glibc 2.6.
    • [^] # Re: Linux

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

      >>> Depuis combien de temps FreeBSD est en train de bichonner la version 7.0 en faisant une fixation sur un bench ?

      En plus il est marqué que FreeBSD 7.0 utilisera le vieux, l'antique, l'antédiluvien scheduler 4BSD et ne switchera vers le tout nouveau scheduler ULE qu'après (quand sortira FreeBSD 7.1).
      • [^] # Re: Linux

        Posté par  . Évalué à 2.

        Sysbench semble un bench très spécifique :
        http://kerneltrap.org/mailarchive/linux-kernel/2007/10/10/33(...)
        In any case, here are a few general comments about sysbench numbers:

        Sysbench is a pretty 'batched' workload: it benefits most from batchy
        scheduling: the client doing as much work as it can, then server doing
        as much work as it can - and so on. The longer the client can work the
        more cache-efficient the workload is. Any round-trip to the server due
        to pesky preemption only blows up the cache footprint of the workload
        and gives lower throughput.

        This kind of workload would probably run best on DOS or Windows 3.11,
        with no preemptive scheduling done at all.


        M'enfin, CFS doit marcher correctement avec ce type de bench. Avec la dernière version de CFS (et glibc) c'est le cas.
      • [^] # Re: Linux

        Posté par  . Évalué à 3.

        Alors dans la présentation, page 12:

        You can easily switch to ULE by recompiling your kernel
        • [^] # Re: Linux

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

          Si ULE n'est pas le scheduler par défaut de la version 7.0 c'est que les devs FreeBSD pensent qu'il est trop jeune et qu'il y a des risques. Je vois mal des admins de prod passer outre utiliser ULE quand même....
          • [^] # Re: Linux

            Posté par  . Évalué à 4.

            De même qu'on voit mal des admins mettre en prod des debian testing, n'est-ce pas ? :-)
    • [^] # Re: Linux

      Posté par  . Évalué à 4.

      En parcourrant rapidement le pdf, il y a un comparatif avec le noyau Fedora 8. Fedora 8 qui n'est pas sorti !


      Ça tombe bien, FreeBSD 7.0 n'est pas sorti non plus ;)
      Il compare donc deux systèmes en phase de finalisation.

      Ce n'est pas un 2.6.23 final. Fedora a pour habitude d'avoir des options de debug dans les phases de test ! Ce qui est tout à fait normal.

      Sauf que Fedora 8 n'est plus en phase de développement.
      Pour ceux qui ne sont pas au courant, la release est prévue pour le 8 novembre (soit bien avant celle de FreeBSD 7.0 qui est prévu pour mi-décembre), et on est passé à ce qui devrait être le noyau dévinitif, sans les options de débug, durant les RC. Cela c'est d'ailleurs vu puisque le rpm kernel.x86_64 est passé pour l'occasion de 63 à 16 Mo....

      Par contre, il faut bien regarder les conditions du test. Un développeur a un FreeBSD aux petits oignons et compare avec un Linux "stock" ou un Linux de debug de Fedora.

      Je n'ai pas vérifié pour le bench en question, mais d'autres benchs que j'avais vu et qui arrivaient à la même conclusion comparaient des systèmes en cours de finalisation (donc sans debug) et sans optimisation spécifique de part et d'autre (justement parce que le le testeur ne voulait pas que sa meilleure maitrise de FreeBSD influe sur le résultat).
      • [^] # Re: Linux

        Posté par  . Évalué à 3.

        > October 20, 2007
        À cette date, le dernier noyau de Rawhide était encore compilé avec les options de debug ... Sans compter que le test a eu lieu auparavant.
        Fedora est rentré il y a quelques jours *seulement * en phase de finalisation.
        le noyau dont tu parles date de "29-Oct-2007 23:10" (Cf le mirroir principal)
      • [^] # Re: Linux

        Posté par  . Évalué à 1.

        Le bench fait par FreeBSD est très bien, et je ne passe pas que celui qui a fait le bench est malhonnète.

        Lors des premiers benchs, FreeBSD a révélé un bug dans glibc. Grand merci à FreeBSD. Mais ça date de Mars 2007 environ !
        Maintenant, 6 mois après, FreeBSD nous fait "TATA : on met une branlée à Linux !" et communique beaucoup sur ça car FreeBSD sort sa version 7.0.

        Ce n'est pas cool et limite puant. Linux doit foutre une branlée à FreeBSD dans pleins d'autres benchs. Mais quand Linux sort, Linux ne dit pas "TATA : on met une branlée à FreeBSD !".
        • [^] # Re: Linux

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

          On peut également ajouter que ce n'est que 15% d'écart, que le prochain FreeBSD sortira en 2009 ou plus encore, tandis que la prochaine version 2.6.24 de Linux qui devrait sortir d'ici moins de deux mois, avec une version de CFS encore peaufinée et les processus compartimentés qui semblaient manquer, comblera sûrement ce petit écart.

          Linux progressant beaucoup plus vite que ses concurrents, je trouve idiot (surtout venant d'autres OS libres) de faire tout un foin là dessus alors que ça ne durera qu'un court laps de temps.
          • [^] # Re: Linux

            Posté par  . Évalué à 2.

            > 2.6.24 de Linux qui devrait sortir d'ici moins de deux mois

            J'ai du mal à le croire. Le patch rc1 est un record en taille (à la grande surprise de Linus) :
            http://article.gmane.org/gmane.linux.kernel/594585
            it really is quite impressive.
            Si je me trompe, tant mieux.
          • [^] # Re: Linux

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

            Le prochain freebsd ne sortira pas en 2009, il devrait y avoir des version 7.X et 6.X entre temps, donc aussi des amélioration et du peaufinage. En 2008 la prochaine version majeure du kernel et donc de l'OS devrait sortir (les cycles de développement de FreeBSD n'ont rien a voir avec celui de linux)

            secundo il ne s'agit en aucun cas d'une communication officielle, d'ailleurs le bench tout comme le pdf ne disent pas linux c'est de la merde il sont trop naze, ils ont 15% d'écart avec nous, ils disent "enfin sched_ule" est concurrentiel, et FreeBSD est de retour parmi les OS performant sur du matos moderne.

            Donc contrairement à ce que dit l'auteur du journal, il ne s'agit pas d'un défi lancé aux devs de linux, pour preuves, l'auteur du boulot sur shed_ule et des bench a donné un maximum d'information aux développeurs linux pour qu'ils puissent corriger les bugs qu'il avait découvert, il a même accepter de refaire ces benchs en prenant en compte les modifications/optimisation qui lui ont été recommandées par les devs linux, il s'agit simplement d'essayer de se positionner par rapport à un OS comparable.

            Pour finir sortir une version tous les 2 ou 3 mois ne signifie pas en aucun cas progresser plus vite, cela signifie juste faire des release plus fréquentes. Le foin c'est vous (ceux qui sentent linux attaqué par le rapport et les bench) et l'auteur du journal qui le font.
            • [^] # Re: Linux

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

              >>> Donc contrairement à ce que dit l'auteur du journal, il ne s'agit pas d'un défi lancé aux devs de linux

              C'est un défi amical à mon avis. La petite pique humoristique à l'égard de CFS est révélatrice.
              On est d'accord que ce n'est pas du tout agressif.
            • [^] # Re: Linux

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

              > Pour finir sortir une version tous les 2 ou 3 mois ne signifie pas en
              > aucun cas progresser plus vite, cela signifie juste faire des release
              > plus fréquentes. Le foin c'est vous (ceux qui sentent linux attaqué
              > par le rapport et les bench) et l'auteur du journal qui le font.

              J'ajouterais qu'une des spécificités de FreeBSD (et des autres BSD) est
              la disponibilité de l'ensemble des sources dans un CVS, avec les outils
              permettant de mettre à jour quand bon nous semble, que ce soit pour les
              branches -STABLE ou -CURRENT.

              Ainsi, de nombreux sites utilisent un FreeBSD -STABLE en prod', et le
              mettent à jour quand ils ont le temps ou quand quelque chose qui les
              intéresse a été committé, sans attendre les nouvelles releases.
              • [^] # Re: Linux

                Posté par  . Évalué à 1.

                Mouaif. Tu fais ça pour deux ou trois paquets.

                Sinon il y a plusieurs distributions qui le propose aussi. On en parle peu car c'est très limité comme cible. Surtout que les paquets sont déjà compilés...
                Toutes les versions ne sont pas compilées, c'est le mainteneur qui décide si ses modifications peuvent être testées avec un risque raisonnable. Tester tout ce qui se passe sur un CVS sans discernement n'est pas une bonne idée. Vraiment pas.
                • [^] # Re: Linux

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

                  Je ne parle pas de paquets, mais bien de l'ensemble du système, y
                  compris noyau + système de base, qui sur les BSD forment un tout
                  cohérent, sont développés en continu, et dans le même dépôt CVS¹.

                  Si on suit la branche -CURRENT, effectivement, comme tu dis, on ramasse
                  tout ce qui passe dans le CVS, et on peut avoir des surprises ;-) Ce
                  n'est bien sûr pas conseillé sur un serveur de prod', mais c'est
                  important que des gens l'utilisent et fassent des mises à jour
                  régulières, soit sur des serveurs non critiques, soit sur des machines
                  de dév': c'est ce qui permet de faire remonter les problèmes et les
                  idées d'améliorations.

                  Par contre, si on suit la branche -STABLE, le risque de mauvaises
                  surprises est très réduit : ce qui y est mis (MFC = Move From Current)
                  a déjà été validé pendant une période suffisante dans la branche
                  -CURRENT. La fréquence des mises à jours y est aussi plus faible.

                  ¹: en fait, ce n'est pas tout à fait vrai... Certains développements
                  conséquents sont réalisés dans un dépôt à part, et re-synchronisés
                  périodiquement, pour éviter de tout bouleverser !
                  • [^] # Re: Linux

                    Posté par  . Évalué à 1.

                    C'est très bien d'avoir cette posibilité. Pas de problème.
                    Mais ce n'est pas spécifique à FreeBSD (contrairement à ce que tu laisses croire) et c'est assez commun dans Linux. Voila ce que je veux dire.

                    Juste un exemple, koji de Fedora :
                    http://koji.fedoraproject.org/koji/

                    Il va chercher dans le cvc :
                    http://cvs.fedoraproject.org/viewcvs/

                    Tu peux installer koji en local sur ta bécane ainsi tu peux aussi construire les paquets que le développeur trouve "risqué".

                    M'enfin, la branche Rawhide fait très bien l'affaire.
                    • [^] # Re: Linux

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

                      Ça me semble tout de même bien différent d'une mise à jour complète par
                      make buildworld puis make buildkernel...
                      • [^] # Re: Linux

                        Posté par  . Évalué à -1.

                        Prend une Gentoo alors.
                        Bouffer du cpu pour compiler des truc qui sont déjà compilés ce n'est pas kiffe.
        • [^] # Re: Linux

          Posté par  (Mastodon) . Évalué à 3.

          Ce n'est pas cool et limite puant. Linux doit foutre une branlée à FreeBSD dans pleins d'autres benchs. Mais quand Linux sort, Linux ne dit pas "TATA : on met une branlée à FreeBSD !".


          normal linux n'est pas un OS.

          Mais bon si tu remplaces linux par le nom d'une distrib commerciale, crois-moi tu en verras des comparaisons plus ou moins vaniteuse avec d'autres OS.
        • [^] # Re: Linux

          Posté par  . Évalué à 2.

          euh tu voudrais que linux se compare a un os que personne ne connait dans le grand public ?
          /me sort
          /me fuit installer hurd

Suivre le flux des commentaires

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