Re: Debian vs Solaris vs FreeBSD
Vendredi 13 octobre 2006, 13:16:30 CEST, rixed@happyleptic.org a écrit :
>
> -[ Fri, Oct 13, 2006 at 12:00:24PM +0200, Sylvain Sauvage ]----
> > Quand on fait un test, on s'assure que toutes les conditions sont
> > les mêmes et que seul un petit ensemble de paramètres change.
> > P.ex. :
> > ??? si on décide de tester plusieurs noyaux, on s'assure que tous
> > les programmes utilisateur sont exactement les mêmes (ce qui est
> > quasiment impossible). Pour pseudo-tester entre Linux et FreeBSD,
> > on utilisera p.ex. un Debian GNU/Linux et une Debian GNU/kFreeBSD ;
>
> Et si on veut tester une distro globale et pas juste le noyau, on fait
> exactement ce que le monsieur à fait.
Ce premier point était, comme indiqué, un exemple de test et de la
façon dont on pourrait s'y prendre pour le réaliser. J'ai traité du cas
de ce test en particulier dans le paragraphe suivant, après le mot
« Ici ».
> Je ne vois pas en quoi ce test
> est irrecevable.
Puisque tu ne cite pas la partie dans laquelle j'expliquais en quoi
ce test était irrecevable en l'état, la revoilà :
<<
Ici, ce n'est pas [la] « rapidité de
Debian », la « rapidité de FreeBSD » et la « rapidité de Solaris » qui
sont testées, c'est le temps d'exécution d'une compilation d'un certain
programme (inconnu), avec certains paramètres (inconnus, cf. Makefile,
compilation conditionnelle, etc.),
— avec certains outils (inconnus), les outils GNU, et sur un noyau
Linux, le tout compilé/distribué par Debian (?) ;
— avec certains outils (inconnus, pas forcéménent les mêmes qu'au
dessus), les outils GNU, et sur un noyau FreeBSD, une partie
compilé/distribué par FreeBSD ;
— avec certains outils (inconnus, id.), les outils GNU (même pas sûr),
et sur un noyau Solaris, une partie compilé/distribué par Sun.
>>
Ce qui rend ce test irrecevable, ce sont les différents « inconnus »
que je relève et toutes les différences inconnues qui s'y ajoutent.
> Au contraire, il est plus intérressant de savoir
> comment se comparent entre eux des systèmes complets face aux
> commandes de tous les jours que de savoir combien de changement de
> contextes peuvent faire un noyau Linux ou BSD par seconde, par
> exemple.
Je ne dis pas qu'un test sur les systèmes complets ne peut pas être
intéressant, je dis qu'il faut s'assurer des paramètres que l'on teste.
J'ajouterais aussi que lorsque l'on publie une étude, on donne
suffisamment de pièces au public visé pour qu'il puisse juger des
résultats obtenus et des conclusions avancées.
(Certains trouveront les termes « publier » et « étude » trop forts
mais cela revient exactement à cela :
— il s'agit d'un démarche de test rationnelle, donc d'une étude ;
— on rend public une expérience, donc on publie.)
Un exemple d'un tel test peut être le temps et la mémoire utilisée
entre le démarrage du PC et l'obtention d'un environnement
opérationnel, avec des services _suffisamment_ équivalents, en
_définissant_ toutes les différences (p.ex. « pour A on utilise le
programme X, pour B, c'est Y, car les deux ont les mêmes fonctions, la
même empreinte mémoire mais n'existent pas sur les deux
distributions »).
Le temps d'exécution du programme X sur les systèmes A et B ne permet
pas de _discuter_ des systèmes A et B. Cela permet juste de _dire_ que
X met le temps Ta sur A et Tb sur B. C'est tout.
(Merci de bien noter la distinction entre « dire » et « discuter ».)
Si l'on veut _discuter_ de ces résultats, il faut comprendre les
contextes et donc les documenter en montrant les paramètres en jeu.
Il y a ici des paramètres qui ne sont pas maîtrisés et, surtout, qui
ne sont pas documentés.
Tester, sur deux systèmes bien définis, la compilation d'un même
programme, permet effectivement d'avoir une idée de la différence de
comportement entre les deux systèmes.
Par contre, encore une fois, on doit s'assurer des paramètres testés.
Surtout si l'on veut expliquer ou discuter des résultats. Sinon, comme
je l'ai fait en résumant mon dernier message, tout ce que l'on peut
dire, c'est que l'on ne peut rien dire.
Pour reprendre la magnifique analogie de la voiture, on se retrouve
ici avec un message se résumant à :
« X a mis trois heures pour arriver à Paris, Y, avec la même voiture,
a mis deux heures, et Z, avec une voiture similaire, a mis une heure
et demie. »
Sont-ils partis du même endroit ? Ont-ils pris le même chemin ?...
> > ??? si on décide de faire le test via une compilation, on s'assure
> > que les options de compilation sont les mêmes (le passage de -O0 à
> > -O3 peut p.ex. modifier le temps de compilation par un facteur 10),
> > on s'assure que le code compilé est le même (pas de #ifdef qui omet
> > la moitié du code), etc.
>
> L'OP n'a fait que rapporter une petite expérience, dont les résultats
> lui ont semblé étrange à juste titre et nous devrions le remercier de
> nous en avoir fait part plutôt que de le renvoyer dans les cordes
> parcequ'il ne nous plaît pas qu'on dise du mal de notre distro
> favorite.
Tu m'attribues des intentions, des sentiments et un jugement que je
n'ai pas.
Le collègue de Sébastien fait une expérience mais Sébastien ne la
documente pas. Sébastien fait un jugement (« catastrophique ») et nous
demande de discuter des résultats.
Ma réponse, qui peut être perçue comme un peu sèche, n'est pas un
« renvoi dans les cordes parce que le résultat ne me plaît pas et qu'il
dit du mal de ma distribution favorite », c'est :
— une explication de ce que sont un banc de test et la façon dont on
étudie les résultats ;
— une indication de non participation à une discussion sur ces
résultats qui ne sont pas documentés, dans l'espoir que Sébastien,
ou son collègue (ou quiconque, d'ailleurs), vérifie l'orthogonalité
des paramètres et nous donne plus de documentation sur ces tests.
En un mot, j'ai juste essayé de rationaliser le débat pour éviter que
le catastrophisme du message ne parte en glose ou, plutôt, en troll
(eh, on est encore vendredi).
--
Sylvain Sauvage
Reply to: