Journal Benchmark NetBSD5, NetBSD4, Fedora et FreeBSD

Posté par .
Tags : aucun
9
2
mai
2009
Bonjour,

Suite à la sortie de NetBSD 5, Andrew Doran a produit un petit test de comparaison entre NetBSD5, NetBSD4, Fedora et FreeBSD afin d'exposer un peu le boulot effectué entre NetBSD 4 et 5.

Le boulot de Andrew Doran à été de passer d'un model big-lock
à un model de petit lock ou plusieurs threads peuvent executer du code en espace noyau.

Les tests ont été effectué avec des OS sans aucune modification. NetBSD colle bien au talon de Fedora. C'est une belle performance pour un projet de la taille de NetBSD. On peut d'ailleurs voir que l'écart de performance entre NetBSD 4 et 5 est un gouffre !

Le bench : http://blog.netbsd.org/tnf/entry/netbsd_5_0_an_overview
  • # Pas avec Fedora, le troll...

    Posté par . Évalué à 10.

    Comme tout bench qui se respecte, celui-ci est probablement peu représentatif des performances sur des vrais serveurs utilisés en vraie production dans la vraie vie.

    Cependant, ce qui est intéressant ici, ce n'est pas tant de dire que NetBSD colle à Fedora, mais bien de signaler que FreeBSD 7.1 est complètement à la ramasse.

    Et d'un troll.

    Ce qui confirme aussi que DragonflyBSD avait bien fait de forker sous prétexte que les orientations prises par le projet n'étaient pas bonnes.

    Et de deux trolls.

    D'ailleurs, ce serait bien qu'on voit aussi OpenBSD et DragonflyBSD. L'auteur aurait-il eu peur des résultats?

    Et de trois trolls!

    Bon, c'est pas le bon jour, mais hier c'était férié, je le rappelle!!
  • # Bench

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

    Ce benchmark a été signalé par l'auteur de la news NetBSD 5 (c'est le quatrième lien de la dépêche).
    Je recolle mon commentaire : "Évidemment comme c'est un test réalisé par un dev de NetBSD il faut se méfier un peu mais bon ça reste intéressant. ".

    On peut aussi noter que le tout dernier NetBSD est comparé à un noyau 2.6.27 (présent dans Fedora 10) qui date de plus de 6 mois.
    • [^] # Re: Bench

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

      en gros, tu est très sceptique, c'est ça ?
      • [^] # Re: Bench

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

        >>> en gros, tu est très sceptique, c'est ça ?

        Très sceptique serait beaucoup dire.
        Je suis admiratif devant les résultats de NetBSD 5 qui semble écraser FreeBSD et faire presque jeu égal avec Fedora 10...et, comme le souligne Herodiade dessous, j'aimerai que les conditions de ces tests soient précisés et qu'ils soient refaits par une personne neutre. Juste pour être sûr et pour appliquer une saine méthode scientifique.

        Je trouve merveilleux et un peu étonnant que NetBSD fasse un tel bond d'un seul coup.
        FreeBSD a galéré des années pour décomposer son Big Kernel Lock et verrous plus fins. Il a fallu toutes les versions 5.x et toutes les versions 6.x pour commencer à percevoir les dividendes à partir des versions 7.x.
        Linux a aussi mis des années et pourtant son team de dev est incomparablement plus grand que celui de NetBSD.

        Là il semble que NetBSD, par l'intermédiaire d'un seul développeur payé et en seulement deux ans, a dépassé FreeBSD et presque rejoint Linux sur les benchmarks proposés.
        • [^] # Re: Bench

          Posté par . Évalué à 6.

          Je trouve merveilleux et un peu étonnant que NetBSD fasse un tel bond d'un seul coup.
          FreeBSD a galéré des années pour décomposer son Big Kernel Lock et verrous plus fins. Il a fallu toutes les versions 5.x et toutes les versions 6.x pour commencer à percevoir les dividendes à partir des versions 7.x.
          Linux a aussi mis des années et pourtant son team de dev est incomparablement plus grand que celui de NetBSD.

          Là il semble que NetBSD, par l'intermédiaire d'un seul développeur payé et en seulement deux ans, a dépassé FreeBSD et presque rejoint Linux sur les benchmarks proposés.


          Il faut aussi se dire que s'il n'y a qu'une personne, alors il y a aussi moins de temps perdu à organiser les gens, surtout quand ils travaillent sur le même problème.

          Il est possible que les deux précédentes expériences que tu cites lui ai servi de guide ou apparenté !
        • [^] # Re: Bench

          Posté par . Évalué à 7.

          Je trouve merveilleux et un peu étonnant que NetBSD fasse un tel bond d'un seul coup.
          FreeBSD a galéré des années pour décomposer son Big Kernel Lock et verrous plus fins. Il a fallu toutes les versions 5.x et toutes les versions 6.x pour commencer à percevoir les dividendes à partir des versions 7.x.
          Linux a aussi mis des années et pourtant son team de dev est incomparablement plus grand que celui de NetBSD.


          Peut être que NetBSD est vraiment très bien codé et que Adrew Doran est très bon ! :)

          Plus serieusement, On ne peut pas comparer Linux et NetBSD. L'équipe de NetBSD est vraiment beaucoup plus structuré et réduite. C'est un avantage autant qu'un désavantage ! Autant le manque de personne se fait souvent cruellement sentir, autant les choix fait sont tout le temps : Pas de hacks, que des solutions. Sur les mailing list, tout les ajouts sont très discutés. Donc peut être que NetBSD est est plus... simple ?

          C'est en tout cas ce qui ressort à l'utilisation.

          Mais je mettrais un petit bémol au performance de NetBSD par rapport à Fedora. Le point noir pour NetBSD, c'est SELinux !
          Parce que par défaut, SELinux est activé et il y a fort à parier qu'une fois désactivé, Fedora serait un petit peu plus devant...!


          ps : je conseil vraiment les mailings list de NetBSD, surtout
          teck-kern http://www.netbsd.org/cgi-bin/subscribe_list.pl?list=tech-ke(...)
          teck-security http://www.netbsd.org/cgi-bin/subscribe_list.pl?list=tech-se(...)
          mais globalement tout les teck-* et aussi netbsd-users. La lecture de ses listes est vraiment très très instructive pour toute personne s'intéressant à la conception d'un OS.
          • [^] # Re: Bench

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

            Peut être que NetBSD est vraiment très bien codé
            Donc peut être que NetBSD est est plus... simple ?
            En se baladant dans les sources de NetBSD, c'est quelque chose qui saute aux yeux. Hyper propre, net. Ca respire la robustesse, même si c'est 98% subjectif. Ca m'a toujours laissé une impression de "si je monte dans une fusée, je veux qu'elle soit pilotée par NetBSD pour gérer les 11 km/s".
    • [^] # Re: Bench

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

      patrick, cela dépend. À l'installation c'est la 2.6.27 certes, mais depuis 2 semaines de mémoire Fedora 9 et 10 ont une mise à jour officielle vers la 2.6.29...

      Donc le problème est, ce bench a été fait en tenant compte de cette mise à jour ou pas ?
    • [^] # Re: Bench

      Posté par . Évalué à 3.

      En plus on ne parle plus de Fedora Core depuis 2 ans maintenant... (c'est ce que le gars a maru" sur toutes ses diapos)
    • [^] # Re: Bench

      Posté par . Évalué à 10.

      un noyau 2.6.27 [...] qui date de plus de 6 mois

      Oh mon Dieu ! Un noyau antédiluvien ! :P
      • [^] # Re: Bench

        Posté par . Évalué à 4.

        c'est surtout que le noyau entre le 2.6.25 et 2.6.29 avait un gros problème de perf donc la critique est totalement valide:

        http://www.phoronix.com/scan.php?page=article&item=linux(...)
        • [^] # Re: Bench

          Posté par . Évalué à 5.

          Oui enfin leurs résultats sont bizarres à ces gars-là. La performance SSL aurait doublé entre deux noyaux, et comme par hasard la machine de test est un dual core ? Hum hum...
          Certains noyaux n'étaient-ils pas monoprocesseur et d'autres multiprocesseurs ?
          Ça sent l'incompétence à plein nez, le genre de types qui lancent plein de benchmarks mais sont incapables d'interpréter et diagnostiquer les résultats.
          • [^] # Re: Bench

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

            >>> Ça sent l'incompétence à plein nez, le genre de types qui lancent plein de benchmarks mais sont incapables d'interpréter et diagnostiquer les résultats.

            Phoronix est un site assez fiable normalement. Ils font du bon boulot.
            Pour ce problème particulier ce sont eux qui ont raison et d'ailleurs il y a eu un patch sur la LKML pour corriger la régression de performances de sqlite :

            http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)

            Un article explicatif ici : http://lwn.net/Articles/325307/
            • [^] # Re: Bench

              Posté par . Évalué à 3.

              Ok, mais leurs résultats SSL sont quand même très douteux. Que du code 100% userspace devienne deux fois plus rapide d'un noyau à l'autre...
              • [^] # Re: Bench

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

                Peut-être un changement dans la partie crypto du noyau ? C'est vrai que c'est bizarre, il faudrait investiguer.
              • [^] # Re: Bench

                Posté par . Évalué à 2.

                Ou peut-être des améliorations dans la synchronisation multi-thread (je dis ça un peu au pif..)
  • # Méthodologie ?

    Posté par . Évalué à 7.

    Le gars ne donne aucun détail sur les conditions de ses benchs : version du bench, type de machine (raid ou pas, qté de ram, configs, systèmes de fichiers utilisés, params passés aux outils de benchs, etc), ils ne sont pas reproductibles en l'état.

    Je ne connais pas hackbench ni les détails de son test build.sh. Mais au moins concernant sysbench, qui est effectivement un bench très reconnu, les petits détails de paramétrage ont un impact notoirement significatifs (et connus pour être différents selon les OS, justement...).

    Par ex. certains OS s'écroulent très vite si on augmente trop le innodb_thread_concurrency, mais peuvent tenir la même charge que d'autres si on le configure avec justesse.
    Ou encore : sous linux, les différences de résultat sur ce test (en fait, sur tout les benchs OLTP / de SGBD) entre l'ordonanceur d'E/S cfq (par défaut sous Linux, très bien pour le desktop mais très mauvais pour les bdd) et le deadline (plus adapté) sont immenses. Et bien sûr la proportion entre la taille des bases et le cache (innodb_buffer_pool_size) change complètement le sens du test (si le cache est assez grand, on mesure réellement les perfs du scheduler CPU, de VM, de l'implémentation du threading, s'il est petit on mesure les perfs des drivers block/raid, du scheduler d'I/O et du système de fichier). La méthode de flush des dirty pages a aussi un impact important (sous Linux, utiliser O_DIRECT améliore significativement les résultats).
    • [^] # Re: Méthodologie ?

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

      Selon ce qui est indiqué, il semblerait que tout soit d'origine pour les paramétrages (je ne fais que supposer), sauf le my.cnf

      Ce qui me chagrine vraiment c'est qu'il est indiqué que les matériels sont similaires.
      Pardon, similaires ? Ce n'est pas une seule et même machine ?!
  • # Firefox 3.0.10

    Posté par . Évalué à 1.

    Je ne sais pas vous, mais les diapos de sa présentation ne s'affichent pas sous firefox 3.0.10. (pourtant il y a bien une balise dans sa page web et je peux visualiser les images en précisant l'adresse directe).

    Je n'ai pas de soucis avec safari.
    • [^] # Re: Firefox 3.0.10

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

      Je suis en Firefox 3.0.10 sous Hardy Heron et je n'ai pas de problème d'affichage des diapos.
      Tu a regardé tes règles adblock ?
      • [^] # Re: Firefox 3.0.10

        Posté par . Évalué à 2.

        Dans le mille... Je n'avais jamais eu de cas flagrant de blocage non-voulu par cette extension, c'est chose faite dorénavant !

        Merci Patrick ;)

Suivre le flux des commentaires

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