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.
Journal FreeBSD 7.0 arrive...et il a les crocs !
30
oct.
2007
# Ouais mais ...
Posté par Sébastien B. . Évalué à 2.
[^] # Re: Ouais mais ...
Posté par Ozz . Évalué à 10.
# Linux
Posté par IsNotGood . Évalué à 9.
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 IsNotGood . Évalué à 3.
Il a été corrigé dans glibc 2.6.
[^] # Re: Linux
Posté par patrick_g (site web personnel) . Évalué à 4.
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 IsNotGood . Évalué à 2.
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/10/33(...)
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 arapaho . Évalué à 3.
You can easily switch to ULE by recompiling your kernel
[^] # Re: Linux
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Linux
Posté par lasher . Évalué à 4.
[^] # Re: Linux
Posté par sobek . Évalué à 4.
Ça tombe bien, FreeBSD 7.0 n'est pas sorti non plus ;)
Il compare donc deux systèmes en phase de finalisation.
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....
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 GeneralZod . Évalué à 3.
À 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 IsNotGood . Évalué à 1.
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 Okki (site web personnel, Mastodon) . Évalué à -1.
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 IsNotGood . Évalué à 2.
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/594585Si je me trompe, tant mieux.
[^] # Re: Linux
Posté par Bapt (site web personnel) . Évalué à 10.
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 patrick_g (site web personnel) . Évalué à 3.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
> 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 IsNotGood . Évalué à 1.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
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 IsNotGood . Évalué à 1.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
make buildworld puis make buildkernel...
[^] # Re: Linux
Posté par IsNotGood . Évalué à -1.
Bouffer du cpu pour compiler des truc qui sont déjà compilés ce n'est pas kiffe.
[^] # Re: Linux
Posté par Psychofox (Mastodon) . Évalué à 3.
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 modr123 . Évalué à 2.
/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.