Vendredi 13 octobre 2006, 13:16:30 CEST, [EMAIL PROTECTED] 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
