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
Journal Benchmark NetBSD5, NetBSD4, Fedora et FreeBSD
2
mai
2009
# Pas avec Fedora, le troll...
Posté par Maclag . Évalué à 10.
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 patrick_g (site web personnel) . Évalué à 5.
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 zecrazytux (site web personnel) . Évalué à 3.
[^] # Re: Bench
Posté par patrick_g (site web personnel) . Évalué à 9.
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 Victor . Évalué à 6.
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 kowalsky . É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 Kerro . Évalué à 8.
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 Renault (site web personnel) . Évalué à 2.
Donc le problème est, ce bench a été fait en tenant compte de cette mise à jour ou pas ?
[^] # Re: Bench
Posté par polytan . Évalué à 3.
[^] # Re: Bench
Posté par Guillaume Knispel . Évalué à 10.
Oh mon Dieu ! Un noyau antédiluvien ! :P
[^] # Re: Bench
Posté par Anonyme . Évalué à 4.
http://www.phoronix.com/scan.php?page=article&item=linux(...)
[^] # Re: Bench
Posté par Antoine . Évalué à 5.
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 patrick_g (site web personnel) . Évalué à 5.
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 Antoine . Évalué à 3.
[^] # Re: Bench
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Bench
Posté par Guillaume Knispel . Évalué à 2.
# Méthodologie ?
Posté par herodiade . Évalué à 7.
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 Kerro . Évalué à 9.
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 polytan . Évalué à 1.
Je n'ai pas de soucis avec safari.
[^] # Re: Firefox 3.0.10
Posté par patrick_g (site web personnel) . Évalué à 3.
Tu a regardé tes règles adblock ?
[^] # Re: Firefox 3.0.10
Posté par polytan . Évalué à 2.
Merci Patrick ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.