Benchmarking HOWTO Linux par Andre D. Balsa, andrewbalsa@usa.net traduit par Francois Laagel, f.laagel@ieee.org v0.12, 15 Aout 1997 (v.f. : 2 du 28 Novembre 1997) Le benchmarking HOWTO Linux traite de certains problemes relatifs a l'evaluation de performances de systemes Linux et presente un ensemble d'outils ainsi qu'un formulaire associe qui permettent de produire des mesures de performances significatives en quelques heures. Peut-etre ce document contribuera-t-il a une diminution du nombre d'articles inutiles dans comp.os.linux.hardware... 11.. IInnttrroodduuccttiioonn _"_C_e _d_o_n_t _o_n _n_e _p_e_u_t _p_a_r_l_e_r _d_o_i_t _e_t_r_e _p_a_s_s_e _s_o_u_s _s_i_l_e_n_c_e_._" _L_u_d_w_i_g _W_i_t_t_g_e_n_s_t_e_i_n _(_1_8_8_9_-_1_9_5_1_)_, _p_h_i_l_o_s_o_p_h_e _A_u_t_r_i_c_h_i_e_n L'evaluation de performances (benchmarking) consiste a mmeessuurreerr la vitesse a laquelle un ordinateur execute une tache calculatoire, et ce de facon a pouvoir comparer differentes configurations logicielles/materielles. Ceci n'a aauuccuunn rapport avec la facilite d'utilisation, l'esthetique, les considerations d'ergonomie ou toute autre appreciation subjective. L'evaluation de performances est une tache fastidieuse et repetitive. Elle necessite que l'on prete une grande attention aux details. Tres souvent les resultats obtenus ne sont pas ceux auxquels on s'attendait et sont sujet a interpretation (ce qui peut tres bien etre le but d'une procedure d'evaluation de performances). Enfin, l'evaluation de performances traite de faits et de chiffres et non pas d'opinion ou d'approximation. 11..11.. PPoouurrqquuooii ll''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess eesstt--eellllee ssii iimmppoorrttaannttee ?? Hormis les raisons mentionnees dans le BogoMips Mini-HOWTO (section 7, paragraphe 2), il arrive, lorsque l'on se constitue une machine Linux, que l'on soit confronte a un budget limite et/ou a des besoins en performances minimales garanties. En d'autres termes, lorsque l'on se pose les questions suivantes : +o Comment maximiser la performance avec un budget donne ? +o Comment minimiser le cout necessaire pour obtenir un niveau de performance donne ? +o Comment obtenir le meilleur rapport performance/cout (etant donne un budget ou des besoins en performances minimales garanties) ? il faudra examiner, comparer et/ou produire des benchmarks (ndt : un benchmark est un programme ou un ensemble de programmes - on parle alors de suite - servant a evaluer les performances d'un systeme informatique). Minimiser les couts sans contraintes de performance implique d'ordinaire la constitution d'une machine a partir de composants de recuperation (ce vieux 386SX-16 qui traine dans le garage sera parfait), et ne necessite pas de benchmarks. Maximiser la performance sans cout plafond n'est pas une situation realiste (a moins que l'on souhaite mettre un Cray dans son salon - la banquette recouverte de cuir qui se trouve au dessus des alimentations electriques est du meilleur gout, n'est-t-il pas ?). L'evaluation de performances sans contrainte de cout ni de performance minimale garantie n'a pas de sens: c'est une perte de temps et d'argent. L'evaluation de performances n'a de sens que dans le cadre d'une prise de decision, c'est a dire si l'on a le choix entre deux alternatives ou plus. D'ordinaire des criteres autres que le ccoouutt interviennent dans le processus decisionnel. Il peut s'agir de la disponibilite, du service, de la fiabilite, de considerations strategiques ou de toute autre caracteristique rationnelle et mesurable d'un systeme informatique. Par exemple, lorsque l'on compare la performance de differentes versions du noyau Linux, la ssttaabbiilliittee est toujours plus importante que la vitesse d'execution. 11..22.. NNoonn--ccrriitteerreess eenn mmaattiieerree dd''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess Malheureusement et tres souvent dans les newsgroups (forums) et les mailing lists (listes de diffusion par courrier electronique), sont cites : 1. La reputation du fabriquant (non-mesurable et sans signification). 2. Les parts de marche du fabriquant (sans signification et non- pertinent). 3. Des parametres irrationnels (superstition ou a-priori par exemple acheteriez-vous un processeur etiquete 131313ZAP et peint en rose ?). 4. La valeur percue (non-significative, non-mesurable et irrationnelle). 5. L'ampleur du tapage marketing (ndt : mercatique pour les integristes :) est ce qu'il y a de pire, je crois. Personnellement, j'en ai marre des logos "XXX inside" ou "kkkkkws compatible" (maintenant "aaaaaPowered" est de la partie, et puis quoi encore ?). AMHA, les milliards de dollards depenses durant de telles campagnes seraient bien mieux utilises par de equipes de recherche pour la conception de nouveaux processeurs, plus rapides (moins chers :-) et moins bugges. Aucune campagne publicitaire, si ambitieuse soit-elle, n'est en mesure de supprimer une bug de la FPU en calcul flottant sur le tout nouveau processeur que vous venez tout juste d'enficher sur votre carte-mere, alors qu'un echange au profit d'un processeur re-concu le fera. 6. Les opinions du type "Vous avez ce pour quoi vous avez paye" ne sont precisement que ca : des opinions. Donnez-moi des faits, s'il vous plait. 22.. PPrroocceedduurreess dd''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess eett iinntteerrpprreettaattiioonn ddeess rreessuullttaattss Quelques recommendations semi-evidentes : 1. Premierement et avant tout, iiddeennttiiffiieezz vvooss oobbjjeeccttiiffss dd''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess. Qu'essayez vous exactement d'evaluer ? En quoi un processus d'evaluation de performances va-t-il vous aider a prendre une decision ulterieure ? Combien de temps et quelles ressources voulez-vous consacrer a cet effort ? 2. UUttiilliisseezz ddeess oouuttiillss ssttaannddaarrdd. Utilisez une version a jour et stable du noyau, des versions standard et a jour de gcc et de la libc, et un benchmark standard. En bref, utilisez le LBT (voir plus loin). 3. Donnez une ddeessccrriippttiioonn ccoommpplleettee de votre configuration materielle (voir le formulaire de compte-rendu plus loin). 4. Essayez d'iissoolleerr uunnee vvaarriiaabbllee uunniiqquuee. L'evaluation de performances comparative est plus informative que l'evaluation de performances "absolue". JJee nn''iinnssiisstteerraaii jjaammaaiiss aasssseezz llaa--ddeessssuuss. 5. VVeerriiffiieezz vvooss rreessuullttaattss. Faites tourner vos benchmarks plusieurs fois et verifiez les variations des resultats obtenus, si variation il y a. Des variations inexpliquees invalideront vos resultats. 6. Si vous pensez que votre effort d'evaluation de performances a produit de l'information significative, ppaarrttaaggeezz--llaa avec la communaute Linux de facon pprreecciissee et ccoonncciissee. 7. OOuubblliieezz lleess BBooggooMMiippss s'il vous plait. Je me promets d'implementer un jour un ASIC (ndt : un acronyme pour Application Specific Integrated Circuit, c'est un circuit integre dedie a une application donnee) dans lequel les BogoMips seront cables. Et alors on verra ce qu'on verra ! 22..11.. CCoommpprreennddrree lleess cchhooiixx eenn mmaattiieerree ddee bbeenncchhmmaarrkkss 22..11..11.. BBeenncchhmmaarrkkss ssyynntthheettiiqquueess vvss.. bbeenncchhmmaarrkkss aapppplliiccaattiiffss Avant de consacrer le moindre temps aux travaux d'evaluation de performances, il importe de faire un choix de base entre benchmarks synthetiques et benchmarks applicatifs. Les benchmarks synthetiques sont specifiquement concus pour mesurer la performance des composants individuels d'un ordinateur, d'habitude en poussant l'un desdits composants jusqu'a sa limite. Un exemple de benchmark synthetique celebre est la suite WWhheettssttoonnee, initialement programmee en 1972 par Harold Curnow en FORTRAN (ou etait-ce en ALGOL ?), et dont l'usage est toujours tres repandu de nos jours. La suite Whetstone produira une mesure de la performance d'une CPU en matiere de calcul flottant. La principale critique que l'on puisse faire aux benchmarks synthetiques est qu'ils ne representent pas la performance d'un ordinateur, en tant que systeme complexe, dans des conditions d'utilisation reelles. Prenons par exemple la suite Whetstone, dont la boucle principale est tres courte, et qui donc peut aisement tenir dans le cache primaire d'une CPU, cette suite maintient le pipeline de la FPU alimente en permanence de facon a pousser celle-ci a sa vitesse maximale. On ne peut pas vraiment critiquer la suite Whetstone si l'on se souvient qu'elle a ete programmee il y a 25 ans (sa conception est meme plus ancienne que ca !), mais il nous faut nous assurer que nous interpretons ses resultats avec prudence quand nous nous preoccupons d'evaluer les performances de micro-processeurs modernes. Un autre aspect tres important qu'il nous faut avoir en tete a propos des benchmarks synthetiques est qu'idealement, ils devraient pouvoir nous dire quelque chose en ce qui concerne un aspect ssppeecciiffiiqquuee du systeme que l'on est en train de tester, et ce independamment des autres aspects dudit syseme : un benchmark synthetique d'une carte D'E/S Ethernet devrait produire les memes resultats (ou des resultats comparables) que ce soit sur un 386SX-16 avec 4 MB de RAM ou sur un Pentium 200 MMX avec 64 MB de RAM. Si tel n'etait pas le cas, le test mesurerait la performance globale de l'association CPU/carte- mere/bus/carte Ethernet/sous-systeme memoire/DMA, ce qui n'est pas tres utile puisque la difference au niveau des CPUs aura un impact plus important que la difference au niveau des cartes Ethernet (ceci suppose bien sur que nous utilisions la meme combinaison noyau/driver (pilote de peripherique)). Dans le cas contraire la difference de performances pourrait etre encore plus grande) ! Enfin, une erreur frequemment commise est de calculer la moyenne de divers benchmarks synthetiques et de pretendre qu'une telle moyenne est une bonne representation de la performance globale d'un systeme donne pour une utilisation dans la vie reelle. Voici un commentaire sur les benchmarks FPU (cite avec la permission du site Web de Cyrix Corp.) : _"_U_n_e _u_n_i_t_e _d_e _c_a_l_c_u_l _f_l_o_t_t_a_n_t _a_c_c_e_l_e_r_e _l_e _l_o_g_i_c_i_e_l _c_o_n_c_u _p_o_u_r _l_'_u_t_i_l_i_s_a_t_i_o_n _d_e _l_'_a_r_i_t_h_m_e_t_i_q_u_e _f_l_o_t_t_a_n_t_e _: _t_y_p_i_q_u_e_m_e_n_t _i_l _s_'_a_g_i_t _d_e _p_r_o_g_r_a_m_m_e_s _d_e _C_A_O_, _d_e _t_a_b_l_e_u_r_s_, _d_e _j_e_u_x _e_n _3_D _e_t _d_'_a_p_p_l_i_c_a_t_i_o_n_s _d_e _c_o_n_c_e_p_t_i_o_n_. _C_e_p_e_n_d_a_n_t_, _l_a _p_l_u_p_a_r_t _d_e_s _a_p_p_l_i_c_a_t_i_o_n_s _P_C _p_o_p_u_l_a_i_r_e_s _d_'_a_u_j_o_u_r_d_'_h_u_i _u_t_i_l_i_s_e_n_t _a _l_a _f_o_i_s _d_e_s _i_n_s_t_r_u_c_t_i_o_n_s _f_l_o_t_t_a_n_t_e_s _e_t _l_'_a_r_i_t_h_m_e_t_i_q_u_e _e_n_t_i_e_r_e_. _C_'_e_s_t _p_o_u_r_q_u_o_i _C_y_r_i_x _a _c_h_o_i_s_i _d_e _m_e_t_t_r_e _l_'_a_c_c_e_n_t _s_u_r _l_e _p_a_r_a_l_- _l_e_l_i_s_m_e _l_o_r_s _d_e _l_a _c_o_n_c_e_p_t_i_o_n _d_u _p_r_o_c_e_s_s_e_u_r _6_x_8_6 _e_t _c_e _d_a_n_s _l_e _b_u_t _d_'_a_c_c_e_l_e_r_e_r _l_e_s _p_r_o_g_r_a_m_m_e_s _q_u_i _e_n_t_r_e_m_e_l_e_n_t _c_e_s _2 _t_y_p_e_s _d_'_i_n_s_t_r_u_c_t_i_o_n_s_. _L_e _m_o_d_e_l_e _d_e _t_r_a_i_t_e_m_e_n_t _d_e_s _e_x_c_e_p_t_i_o_n_s _f_l_o_t_t_a_n_t_e_s _d_e _l_'_a_r_c_h_i_t_e_c_t_u_r_e _x_8_6 _p_e_r_m_e_t _a_u_x _i_n_s_t_r_u_c_t_i_o_n_s _e_n_t_i_e_r_e_s _d_'_e_t_r_e _e_m_i_s_e_s _e_t _d_e _s_e _t_e_r_m_i_n_e_r _p_e_n_d_a_n_t _q_u_'_u_n_e _i_n_s_t_r_u_c_t_i_o_n _f_l_o_t_- _t_a_n_t_e _e_s_t _e_n _c_o_u_r_s _d_'_e_x_e_c_u_t_i_o_n_. _A _l_'_o_p_p_o_s_e_, _u_n_e _s_e_c_o_n_d_e _o_p_e_r_a_t_i_o_n _f_l_o_t_t_a_n_t_e _n_e _p_o_u_r_r_a _p_a_s _e_t_r_e _e_x_e_c_u_t_e_e _a_l_o_r_s _q_u_'_u_n_e _p_r_e_c_e_d_e_n_t_e _i_n_s_t_r_u_c_t_i_o_n _f_l_o_t_t_a_n_t_e _e_s_t _e_n _c_o_u_r_s _d_'_e_x_e_c_u_t_i_o_n_. _P_o_u_r _s_u_p_p_r_i_m_e_r _c_e_t_t_e _l_i_m_i_t_a_t_i_o_n _d_e _p_e_r_f_o_r_m_a_n_c_e _c_r_e_e_e _p_a_r _l_e _m_o_d_e_l_e _d_e _t_r_a_i_t_e_m_e_n_t _d_e_s _e_x_c_e_p_t_i_o_n_s _f_l_o_t_t_a_n_t_e_s_, _l_e _6_x_8_6_, _p_e_u_t _e_m_e_t_t_r_e _s_p_e_c_u_l_a_t_i_v_e_m_e_n_t _j_u_s_q_u_'_a _4 _i_n_s_t_r_u_c_t_i_o_n_s _f_l_o_t_- _t_a_n_t_e_s _v_e_r_s _l_a _F_P_U _i_n_t_e_g_r_e_e _s_u_r _l_e _c_i_r_c_u_i_t_. _P_a_r _e_x_e_m_p_l_e_, _d_a_n_s _u_n_e _s_e_q_u_e_n_c_e _d_e _c_o_d_e _c_o_n_s_t_i_t_u_e_e _d_e _2 _i_n_s_t_r_u_c_t_i_o_n_s _f_l_o_t_- _t_a_n_t_e_s _(_F_L_T_s_) _s_u_i_v_i_e_s _d_e _6 _i_n_s_t_r_u_c_t_i_o_n_s _e_n_t_i_e_r_e_s _(_I_N_T_s_)_, _e_l_l_e_s_-_m_e_m_e_s _s_u_i_v_i_e_s _d_e _2 _F_L_T_s_, _l_e _6_x_8_6 _p_e_u_t _e_m_e_t_t_r_e _t_o_u_t_e_s _c_e_s _1_0 _i_n_s_t_r_u_c_t_i_o_n_s _v_e_r_s _l_e_s _u_n_i_t_e_s _d_'_e_x_e_c_u_t_i_o_n _a_p_p_r_o_p_r_i_e_e_s _a_v_a_n_t _q_u_e _l_'_e_x_e_c_u_t_i_o_n _d_e _l_a _p_r_e_m_i_e_r_e _F_L_T _n_e _s_e _s_o_i_t _t_e_r_m_i_- _n_e_e_. _S_i _a_u_c_u_n_e _d_e _c_e_s _i_n_s_t_r_u_c_t_i_o_n_s _n_e _p_r_o_v_o_q_u_e _d_'_e_x_c_e_p_t_i_o_n _(_c_e _q_u_i _e_s_t _t_y_p_i_q_u_e_)_, _l_'_e_x_e_c_u_t_i_o_n _c_o_n_t_i_n_u_e_, _l_e_s _u_n_i_t_e_s _f_l_o_t_- _t_a_n_t_e_s _e_t _e_n_t_i_e_r_e_s _t_e_r_m_i_n_a_n_t _l_'_e_x_e_c_u_t_i_o_n _d_e _c_e_s _i_n_s_t_r_u_c_t_i_o_n_s _e_n _p_a_r_a_l_l_e_l_e_. _S_i _l_'_u_n_e _d_e_s _F_L_T_s _g_e_n_e_r_e _u_n_e _e_x_c_e_p_t_i_o_n _(_l_e _c_a_s _a_t_y_p_i_q_u_e_)_, _l_e_s _p_o_s_s_i_b_i_l_i_t_e_s _d_'_e_x_e_c_u_t_i_o_n _s_p_e_c_u_l_a_t_i_v_e_s _d_u _6_x_8_6 _p_e_r_m_e_t_t_e_n_t _q_u_e _l_'_e_t_a_t _d_u _p_r_o_c_e_s_s_e_u_r _s_o_i_t _r_e_s_t_i_t_u_e _d_e _f_a_c_o_n _a _c_e _q_u_e _c_e_l_u_i_-_c_i _s_o_i_t _c_o_m_p_a_t_i_b_l_e _a_v_e_c _l_e _m_o_d_e_l_e _d_e _t_r_a_i_t_e_m_e_n_t _d_e_s _e_x_c_e_p_t_i_o_n_s _f_l_o_t_t_a_n_t_e_s_. _L_'_e_x_a_m_e_n _d_e _c_o_d_e _d_e _b_e_n_c_h_m_a_r_k_s _s_y_n_t_h_e_t_i_q_u_e_s _f_l_o_t_t_a_n_t_s _r_e_v_- _e_l_e _q_u_e _c_e_u_x_-_c_i _u_t_i_l_i_s_e_n_t _d_e_s _s_e_q_u_e_n_c_e_s _d_'_i_n_s_t_r_u_c_t_i_o_n_s _p_u_r_e_m_e_n_t _f_l_o_t_t_a_n_t_e_s _q_u_e _l_'_o_n _n_e _t_r_o_u_v_e _p_a_s _d_a_n_s _l_e_s _a_p_p_l_i_c_a_- _t_i_o_n_s _d_u _m_o_n_d_e _r_e_e_l_. _C_e _t_y_p_e _d_e _b_e_n_c_h_m_a_r_k_s _n_e _t_i_r_e _p_a_s _p_r_o_f_i_t _d_e_s _p_o_s_s_i_b_i_l_i_t_e_s _d_'_e_x_e_c_u_t_i_o_n _s_p_e_c_u_l_a_t_i_v_e _d_u _p_r_o_- _c_e_s_s_e_u_r _6_x_8_6_. _C_y_r_i_x _p_e_n_s_e _q_u_e _l_e_s _b_e_n_c_h_m_a_r_k_s _n_o_n_-_s_y_n_t_h_e_- _t_i_q_u_e_s _b_a_s_e_s _s_u_r _d_e_s _a_p_p_l_i_c_a_t_i_o_n_s _d_u _m_o_n_d_e _r_e_e_l _r_e_f_l_e_t_e_n_t _m_i_e_u_x _l_a _p_e_r_f_o_r_m_a_n_c_e _q_u_e _l_e_s _u_t_i_l_i_s_a_t_e_u_r_s _v_o_n_t _e_f_f_e_c_t_i_v_e_m_e_n_t _o_b_t_e_n_i_r_. _L_e_s _a_p_p_l_i_c_a_t_i_o_n_s _d_u _m_o_n_d_e _r_e_e_l _c_o_n_t_i_e_n_n_e_n_t _d_e_s _i_n_s_t_r_u_c_t_i_o_n_s _e_n_t_i_e_r_e_s _e_t _f_l_o_t_t_a_n_t_e_s _e_n_t_r_e_m_e_l_e_e_s _e_t _p_o_u_r _c_e_t_t_e _r_a_i_s_o_n _t_i_r_e_r_o_n_t _u_n _m_e_i_l_l_e_u_r _p_a_r_t_i _d_e_s _p_o_s_s_i_b_i_l_i_t_e_s _d_'_e_x_e_c_u_t_i_o_n _s_p_e_c_u_l_a_t_i_v_e _d_u _6_x_8_6_._" La tendance recente en matiere d'evaluation de performances consiste donc a choisir des applications usuelles et a les utiliser pour mesurer la performance d'ordinateurs en tant que systemes complexes. Par exemple SSPPEECC, l'entreprise a but non-lucratif qui a concu les celebres suites de benchmarks synthetiques SPECINT et SPECFP, a lance un projet pour developper une nouvelle suite de benchmarks applicatifs. Mais, la encore, il est tres improbable qu'une telle suite de benchmarks commerciale comporte du code Linux un jour. En resume, les benchmarks synthetiques sont valables a condition d'avoir compris leurs objectifs et leurs limites. Les benchmarks applicatifs refleteront mieux la performance d'un systeme informatique, mais aucun d'entre eux n'est disponible pour Linux. 22..11..22.. BBeenncchhmmaarrkkss ddee hhaauutt--nniivveeaauu vvss.. ddee bbaass--nniivveeaauu Les benchmarks de bas-niveau ont pour ambition la mesure de la performance du materiel : la frequence de l'horloge du processeur, les temps de cycle de la DRAM (ndt : acronyme pour Dynamic Random Access Memory) et de la SRAM (ndt : acronyme pour Static Random Access Memory) cache, temps d'acces moyen d'un disque dur, temps d'acces piste a piste, etc... Cette approche peut etre utile si vous avez achete un systeme et que vous vous demandez a partir de quels composants il a ete construit, bien qu'une meilleure facon de repondre a cette question soit d'ouvrir le boitier, de dresser l'inventaire des composants que vous trouverez a l'interieur, et d'obtenir les specifications techniques pour chacun d'entre eux (elles sont la plupart du temps disponibles sur le Web). Une autre utilisation possible des benchmarks de bas-niveau consiste a s'en servir pour verifier qu'un driver du noyau a ete correctement configure pour un composant materiel donne : si vous disposez des specifications techniques de ce composant vous pourrez comparer les resultats d'un benchmark de bas-niveau aux valeurs theoriques figurant dans les specs. Les benchmarks de haut-niveau ont plutot pour objectif la mesure de la performance de l'association materiel/driver/systeme d'exploitation en ce qui concerne un aspect specifique d'un systeme informatique (par exemple la performance des entrees-sorties), ou meme une association specifique materiel/driver/systeme d'exploitation/application (par exemple un benchmark Apache sur differents ordinateurs). Bien sur, tous les benchmarks de bas-niveau sont synthetiques. Les benchmarks de haut-niveau peuvent etre synthetiques ou applicatifs. 22..22.. BBeenncchhmmaarrkkss ssttaannddaarrdd ddiissppoonniibblleess ppoouurr LLiinnuuxx AMHA, un test simple que tout le monde peut effectuer a l'occasion d'une mise a jour de la configuration de sa machine Linux est de lancer une compilation du noyau avant et apres cette mise a jour materielle/logicielle, et de comparer les durees de compilation. Si tous les autres parametres sont les memes, alors ce test est valable en tant que mesure de la performance en matiere de compilation, et l'on peut affirmer en toute confiance que : "Le remplacement de A par B a conduit a une amelioration de x % de la duree de compilation du noyau Linux dans telles et telles conditions". Ni plus, ni moins ! Parce que la compilation du noyau est une tache tres courante sous Linux, et parce qu'elle met en oeuvre la plupart des fonctionnalites impliquees dans les benchmarks usuels (sauf le calcul flottant), elle constitue un test iissoollee plutot bon. Cependant, dans la majeure partie des cas, les resultats de ce test ne peuvent pas etre reproduits par d'autres utilisateurs de Linux a cause des differences de configurations materielles/logicielles. Ce test ne constitue donc en aucun cas une metrique permettant de comparer des systemes dissemblables (a moins que nous ne nous mettions tous d'accord sur la compilation d'un noyau standard - voir plus loin). Malheureusement, il n'y a pas d'outils d'evaluation de performances ciblant specifiquement Linux, sauf peut-etre les Byte Linux Benchmarks. Ceux-ci sont une version legerement modifiee des Byte Unix Benchmarks qui datent de 1991 (modifications Linux par Jon Tombs, auteurs originels : Ben Smith, Rick Grehan et Tom Yager). Il existe un site Web central pour les Byte Linux Benchmarks. Une version amelioree et mise a jour des Byte Unix Benchmarks a ete synthetisee par David C. Niemi. Elle s'appelle UnixBench 4.01 pour eviter une confusion possible avec des versions anterieures. Voici ce que David a ecrit au sujet de ses modifications : "Les BYTE Unix benchmarks originels et legerement modifies sont nases a bien des egards ce qui fait d'eux un indicateur inhabituellement non-fiable de la performance d'un systeme. J'ai deliberement fait en sorte que mes indices de perfor- mance soient tres differents pour eviter la confusion avec les vieux benchmarks." David a mis en place une liste majordomo de diffusion par courrier electronique pour les discussions relatives a l'evaluation de performances sous Linux et sous les systemes d'exploitation concurrents. Vous pouvez vous joindre a ces discussions en envoyant un e-mail dont le corps contiendra "subscribe bench" a l'adresse majordomo@wauug.erols.com . Les groupe des utilisateurs de la region de Washington est aussi en train de mettre en place un site Web concernant les benchmarks sous Linux. Recemment, Uwe F. Mayer, mayer@math.vanderbilt.edu a egalement porte la suite Bytemark de BYTE sous Linux. Il s'agit d'une suite moderne et compilee tres habilement par Rick Grehan du magazine BYTE. Bytemark teste les performances de la CPU, de la FPU et du sous-systeme memoire des micro-ordinateurs modernes (ces benchmarks sont strictement orientes vers la performance du processeur, les E/S ou la performance globale du systeme ne sont pas pris en compte). Uwe a aussi mis en place un site Web, site ou l'on peut acceder a une base de donnees contenant les resultats de sa version des benchmarks BYTEmark pour Linux. Si vous etes a la recherche de benchmarks synthetiques pour Linux, vous remarquerez assez vite que sunsite.unc.edu ne propose que peu d'outils d'evaluation de performances. Pour mesurer les performances relatives de serveurs X, la suite xbench-0.2 de Claus Gittinger est disponible sur sunsite.unc.edu, ftp.x.org et d'autres sites (ndt : notamment ftp.lip6.fr qui est l'un des mirroirs de sunsite). Dans son immense sagesse, Xfree86.org refuse de promouvoir ou de recommender le moindre benchmark. XFree86-benchmarks Survey est un site Web comprenant une base de donnees de resultats relatifs a x-bench. En ce qui concerne les E/S purement disque, l'utilitaire hdparm (qui fait partie de la plupart des distributions, mais est aussi disponible sur sunsite.unc.edu) permet de mesurer les taux de transfert grace aux options -t et -T. Il existe plein d'autres outils disponibles librement (sous license GPL) sur Internet pour tester divers aspects de la performance de votre machine Linux. 22..33.. LLiieennss eett rreeffeerreenncceess La FAQ du newsgroup comp.benchmarks par Dave Sill est la reference standard en matiere d'evaluation de performances. Elle n'est pas particulierement orientee Linux, mais elle n'en reste pas moins une lecture recommendee pour tous ceux qui font preuve d'un minimum de serieux envers le sujet. Elle est disponible sur nombre de sites FTP et de sites Web et recense 5566 bbeenncchhmmaarrkkss ddiiffffeerreennttss avec des liens vers des sites FTP permettant de les telecharger. Cependant, certains des benchmarks recenses sont des produits commerciaux. Je n'entrerai pas dans la description detaillee des benchmarks mentionnes dans la FAQ de comp.benchmarks, mais il y a au moins une suite de bas-niveau au sujet de laquelle j'aimerai faire quelques commentaires : la suite lmbench de Larry McVoy. Je cite David C. Niemi : _"_L_i_n_u_s _e_t _D_a_v_i_d _M_i_l_l_e_r _s_'_e_n _s_e_r_v_e_n_t _b_e_a_u_c_o_u_p _p_a_r_c_e _q_u_'_e_l_l_e _p_e_r_m_e_t _d_e_s _m_e_s_u_r_e_s _d_e _b_a_s_-_n_i_v_e_a_u _u_t_i_l_e_s _e_t _p_e_u_t _a_u_s_s_i _q_u_a_n_- _t_i_f_i_e_r _l_a _b_a_n_d_e _p_a_s_s_a_n_t_e _e_t _l_a _l_a_t_e_n_c_e _d_'_u_n _r_e_s_e_a_u _s_i _v_o_u_s _a_v_e_z _d_e_u_x _m_a_c_h_i_n_e_s _a _v_o_t_r_e _d_i_s_p_o_s_i_t_i_o_n _p_o_u_r _l_e _f_a_i_r_e _t_o_u_r_n_e_r_. _M_a_i_s _l_m_b_e_n_c_h _n_'_e_s_s_a_i_e _p_a_s _d_e _p_r_o_d_u_i_r_e _u_n _i_n_d_i_c_e _d_e _p_e_r_f_o_r_m_a_n_c_e _g_l_o_b_a_l_._._._" Un site FTP assez complet en matiere de benchmarks disponibles lliibbrreemmeenntt a ete mis en place par Alfred Aburto. La suite Whetstone utilisee dans le LBT est disponible sur ce site. Une FFAAQQ mmuullttii--ffiicchhiieerr ppaarr EEuuggeennee MMiiyyaa est egalement postee sur comp.benchmarks; c'est une excellente reference. 33.. LLee LLiinnuuxx BBeenncchhmmaarrkkiinngg TToooollkkiitt ((LLBBTT)) Je propose ici un ensemble d'outils pour l'evaluation de performances sous Linux. C'est la version preliminaire d'un vaste environnement d'evaluation de performances pour Linux, il est destine a etre ameliore et a voir ses fonctionnalites etendues. Prenez le pour ce qu'il vaut, c'est-a-dire une proposition. Si vous pensez que cette suite de test n'est pas valable, prenez la liberte de m'envoyer (ndt : a l'auteur et non au traducteur, merci :-) vos critiques par e-mail et soyez surs que je serai heureux d'integrer les changements que vous aurez suggere dans la mesure du possible. Avant d'entamer une polemique, lisez ce HOWTO et les documents cites en reference : les critiques informes sont les bienvenus, les critiques steriles ne le sont pas. 33..11.. MMoottiivvaattiioonnss Elles sont dictees par le bon sens, tout simplement : 1. Cette suite ne doit pas necessiter plus d'une journee de duree d'execution. En matiere de benchmarks comparatifs (diverses executions), personne ne veut passer des jours a essayer de trouver la configuration materielle le plus rapide pour un systeme donne. Idealement, l'ensemble de la suite devrait pouvoir tourner en 15 minutes sur une machine moyenne. 2. Tout le code source doit etre disponible librement sur le Net, pour des raisons evidentes. 3. Les benchmarks devraient fournir des chiffres simples et refletant la performance mesuree. 4. Il devait y avoir un melange de benchmarks synthetiques et de benchmarks applicatifs. 5. Chacun des benchmarks ssyynntthheettiiqquueess devrait pousser un sous-systeme particulier a ses limites. 6. Les resultats des benchmarks ssyynntthheettiiqquueess ne devraient ppaass etre combines par le biais d'une moyenne afin d'en extraire un facteur de merite global (cela va a l'encontre du principe fondateur des benchmarks synthetiques et conduit a une perte d'information considerable). 7. Les benchmarks applicatifs devraient etre representatifs de taches couramment executees sur des systemes Linux. 33..22.. SSeelleeccttiioonn ddeess bbeenncchhmmaarrkkss J'ai selectionne 5 suites des benchmarks differentes en evitant autant que possible les recouvrements dans les tests : 1. Compilation du noyau 2.0.0 (configuration par defaut) avec gcc. 2. Whetstone version 10/03/97 (la version la plus recente de Roy Longbottom). 3. xbench-0.2 (avec les parametres d'execution rapide). 4. Les benchmarks UnixBench version 4.01 (resultats partiels). 5. Les benchmarks de la suite BYTEmark du magazine BYTE beta release 2 (resultats partiels). Pour les tests 4 et 5, "(resultats partiels)" signifie qu'une partie seulement des resultats produits est prise en compte. 33..33.. DDuurreeee ddeess tteessttss 1. Compilation du noyau 2.0.0 : 5 - 30 minutes, selon la performance rreeeellllee de votre machine. 2. Whetstone : 100 secondes. 3. Xbench-0.2 : < 1 heure. 4. Les benchmarks d'UnixBench version 4.01 : environs 15 minutes. 5. Les benchmarks de la suite BYTEmark du magazine BYTE : environs 10 minutes. 33..44.. CCoommmmeennttaaiirreess 33..44..11.. CCoommppiillaattiioonn dduu nnooyyaauu 22..00..00 +o QQuuooii :: c'est le seul benchmark applicatif de la LBT. +o Le code est largement disponible (cad que j'ai finalement trouve une utilisation pour mes vieux CD-ROMs Linux). +o La plupart des linuxiens recompilent leur noyau assez souvent, c'est donc une mesure significative de la performance globale. +o Le noyau est gros et gcc utilise une bonne partie de la memoire (ndt : surtout a l'edition de liens) : ceci contribue a attenuer le biais induit par le cache L2 lorsque l'on se contente de passer de petits tests. +o Les E/S vers le disque sont frequentes. +o Procedure de test : trouvez une antique arborescence source de 2.0.0, compilez la avec les options par defaut (make config, appuyez sur Enter autant de fois que necessaire). Le temps affiche doit correspondre a la duree passee sur la compilation cad apres que vous ayez tape make zImage (sans prendre en compte le make dep clean). Notez que l'architecture cible par defaut est i386, donc si vous compilez sur une autre architecture, gcc devrait etre en mesure de cross-compiler en utilisant i386 en tant qu'architecture cible. +o RReessuullttaattss :: la duree de compilation en minutes et secondes (s'il vous plait, ne rapportez pas les fractions de secondes). 33..44..22.. LLaa ssuuiittee WWhheettssttoonnee +o QQuuooii :: mesure la performance en calcul flottant pur a l'interieur d'une courte (et dense) boucle. Le code source (en C) est assez lisible et il est tres facile de voir quelles sont les operations flottantes impliquees. +o C'est le plus court des tests de la LBT :-). +o C'est un "Vieux Classique" : des chiffres sont disponibles pour comparaison, ses defauts et ses faiblesses sont bien connues. +o Procedure de test : le code source le plus recent devrait etre telecharge depuis le site d'Aburto. Compilez le et executez le en mode double precision. Specifiez gcc et -O2 en tant que pre- processeur et option du compilateur respectivement. Definissez aussi la variable du pre-processur POSIX a 1 pour preciser le type de machine. +o RReessuullttaattss :: un indice de performance en calcul flottant exprime en MWIPS. 33..44..33.. XXbbeenncchh--00..22 +o QQuuooii :: mesure la performance de serveurs X. +o La mesure en xStones fournie par xbench est une moyenne ponderee de quelques tests rapportes aux performances obtenues sur une vieille station Sun ne disposant que d'un display d'un seul bit de profondeur (ndt : en clair, c'est du monochrome pur et dur). Mouais... on peut legitimement se demander si xbench est veritablement adequat en tant que test pour des serveurs X modernes. Neanmoins, c'est le meilleur outil que j'ai trouve. +o Procedure de test : compilez avec -O2. On specifiera aussi quelques options pour une execution courte : ./xbench -timegoal 3 > results/name_of_your_linux_box.out. Pour generer l'indice xStones, il nous faudra encore lancer un script awk; la facon la plus simple de le faire etant de taper make summary.ms. Jetez un coup d'oeuil au fichier summary.ms : l'indice xStone de votre systeme est dans la derniere colonne de la ligne contenant le nom de votre machine -- nom que vous aurez specifie pendant le test. +o RReessuullttaattss :: un indice de performances exprime en xStones. +o Note : ce test, en l'etat, est depasse. Il devrait etre re-ecrit. 33..44..44.. UUnniixxBBeenncchh vveerrssiioonn 44..0011 +o QQuuooii : mesure la performance globale d'un systeme UNIX. Ce test met en oeuvre evidence la performance des E/S fichier et de la gestion du multi-taches par le noyau. +o J'ai supprime tous les resultats de tests arithmetiques et je n'ai conserve que les tests orientes systeme. +o Procedure de test : make avec -O2. Execution avec ./Run -1 (tournez chacun des tests une fois). Vous trouverez les resultats dans le fichier ./results/report. Calculez la moyenne geometrique des indices de EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS et SYSTEM CALL OVERHEAD. +o RReessuullttaattss :: un indice de performance du systeme. (ndt : la moyenne geometrique se definit comme la racine n-ieme du produit des n termes consideres) 33..44..55.. LLeess bbeenncchhmmaarrkkss BByytteemmaarrkk dduu mmaaggaazziinnee BBYYTTEE +o Quoi : fournit une bonne mesure de la performance CPU. Voici un extrait de la documentation : _"_C_e_s _b_e_n_c_h_m_a_r_k_s _o_n_t _e_t_e_s _c_o_n_c_u _d_e _f_a_c_o_n _a _m_e_t_t_r_e _e_n _e_v_i_d_e_n_c_e _l_a _l_i_m_i_t_e _s_u_p_e_r_i_e_u_r_e _d_e _l_a _C_P_U_, _d_e _l_a _F_P_U _e_t _d_e _l_'_a_r_c_h_i_t_e_c_t_u_r_e _m_e_m_o_i_r_e _d_'_u_n _s_y_s_t_e_m_e_. _I_l_s _n_e _p_e_u_v_e_n_t _m_e_s_u_r_e_r _l_a _p_e_r_f_o_r_m_a_n_c_e _d_u _s_o_u_s_-_s_y_s_t_e_m_e _g_r_a_p_h_i_q_u_e_, _d_e_s _a_c_c_e_s _d_i_s_q_u_e _o_u _d_u _d_e_b_i_t _r_e_s_e_a_u _(_c_e _s_o_n_t _l_a _l_e _d_o_m_a_i_n_e _d_'_u_n _e_n_s_e_m_b_l_e _d_i_f_f_e_r_e_n_t _d_e _b_e_n_c_h_m_a_r_k_s_)_. _C_'_e_s_t _p_o_u_r_q_u_o_i_, _i_l _e_s_t _s_o_u_h_a_i_t_a_b_l_e _q_u_e _v_o_u_s _n_'_u_t_i_l_i_s_i_e_z _l_e_s _r_e_s_u_l_t_a_t_s _d_e _c_e_s _t_e_s_t_s _q_u_'_e_n _t_a_n_t _q_u_'_e_l_e_m_e_n_t _d_'_a_p_p_r_e_c_i_a_t_i_o_n _p_a_r_t_i_e_l_l_e_, _e_t _n_o_n _p_a_s _t_o_t_a_l_e_, _l_o_r_s _d_e _l_'_e_v_a_l_u_a_t_i_o_n _d_e _l_a _p_e_r_f_o_r_m_a_n_c_e _d_'_u_n _s_y_s_t_e_m_e_._" +o J'ai supprime tous les resultats de test FPU puisque la suite Whetstone est tout aussi representative des performances a cet egard. +o J'ai decompose les tests entiers en deux groupes : ceux qui sont plus representatifs de la performance cache memoire/CPU, et ceux qui utilisent l'arithmetique entiere de la CPU. +o Procedure de test : make avec -O2. Executez le test avec ./nbench >myresults.dat ou quelque chose d'approchant. Puis, a partir de myresults.dat, calculez la moyenne geometrique des indices des tests STRING SORT, ASSIGNMENT et BITFIELD. Ceci vous donnera l'iinnddiiccee mmeemmooiirree. Calculez la moyenne geometrique des indices des tests NUMERIC SORT, IDEA, HUFFMAN et FP EMULATION: c'est l'iinnddiiccee eennttiieerr. +o RReessuullttaattss :: un indice memoire et un indice entier calcules comme explique ci-dessus. 33..55.. AAmmeelliioorraattiioonnss ppoossssiibblleess La suite de benchmarks ideale tournerait en quelques minutes, comprendrait des benchmarks synthetiques testant chaque sous-systeme separement et des benchmarks applicatifs fournissant des resultats pour differentes applications. Elle produirait aussi automatiquement un rapport complet et eventuellement l'enverrait par e-mail a une base de donnees centrale sur le Web. La portabilite n'est pas vraiment notre souci premier dans cette affaire. Pourtant, une telle suite devrait tourner au moins sur toutes les versions (> 2.0.0) du noyau Linux, et ce dans toutes leurs declinaisons possibles (i386, Alpha, Sparc...). Si quelqu'un a la moindre idee concernant l'evaluation de performances reseau au moyen d'un test a la fois simple, facile d'emploi, fiable, et dont la mise en oeuvre prendrait moins de 30 minutes (configuration et execution), s'il vous plait contactez-moi. 33..66.. FFoorrmmuullaaiirree ddee rraappppoorrtt LLBBTT Au-dela des tests, la procedure d'evaluation de performances n'aurait pas ete complete sans un formulaire decrivant la configuration materielle utilisee lors de leur execution. Le voici donc : (il se conforme aux directives prescrites dans la FAQ de comp.benchmarks) : (ndt : le formulaire en question n'a deliberement pas ete traduit, de facon a ce que l'auteur de ce HOWTO puisse automatiser leur traitement en vue de maintenir une base de donnees de resultats. Voir la section 4 pour un exemple de formulaire correctement rempli). ______________________________________________________________________ LINUX BENCHMARKING TOOLKIT REPORT FORM ______________________________________________________________________ ______________________________________________________________________ CPU == Vendor: Model: Core clock: Motherboard vendor: Mbd. model: Mbd. chipset: Bus type: Bus clock: Cache total: Cache type/speed: SMP (number of processors): ______________________________________________________________________ ______________________________________________________________________ RAM ==== Total: Type: Speed: ______________________________________________________________________ ______________________________________________________________________ Disk ==== Vendor: Model: Size: Interface: Driver/Settings: ______________________________________________________________________ ______________________________________________________________________ Video board =========== Vendor: Model: Bus: Video RAM type: Video RAM total: X server vendor: X server version: X server chipset choice: Resolution/vert. refresh rate: Color depth: ______________________________________________________________________ ______________________________________________________________________ Kernel ===== Version: Swap size: ______________________________________________________________________ ______________________________________________________________________ gcc === Version: Options: libc version: ______________________________________________________________________ ______________________________________________________________________ Test notes ========== ______________________________________________________________________ ______________________________________________________________________ RESULTS ======== Linux kernel 2.0.0 Compilation Time: (minutes and seconds) Whetstones: results are in MWIPS. Xbench: results are in xstones. Unixbench Benchmarks 4.01 system INDEX: BYTEmark integer INDEX: BYTEmark memory INDEX: ______________________________________________________________________ ______________________________________________________________________ Comments* ========= * Ce champ n'est present dans ce formulaire que pour de possibles interpretations des resultats, et tant que tel, il est optionnel. Il pourrait cependant constituer la partie la plus importante de votre compte-rendu, tout particulierement si vous faites de l'evaluation de performances comparative. ______________________________________________________________________ 33..77.. TTeesstt ddee ppeerrffoorrmmaanncceess rreesseeaauu Le test des performances reseau est un veritable defi en soi puisqu'il implique au moins deux machines: un serveur et une machine cliente. Pour cette raison ce genre de test necessite deux fois plus de temps pour etre mis en place, il y a plus de variables a controler, etc... Sur un reseau Ethernet, il me semble votre meilleure option est le paquetage ttcp. (a developper) 33..88.. LLeess tteessttss SSMMPP Les tests SMP sont un autre defi, et tout test concu specifiquement pour un environnement SMP aura des difficultes a s'averer valide dans des conditions d'utilisation reelles parce que les algorithmes qui tirent parti du SMP sont difficiles a developper. Il semble que les versions du noyau Linux les plus recentes (> 2.1.30 ou pas loin) feront du scheduling (ndt : ordonnancement de thread ou de processus) a grain fin ; je n'ai pas plus d'information que ca pour le moment. Selon David Niemi, _"_._._. _s_h_e_l_l_8 de la suite Unixbench 4.01 _f_a_i_t _d_u _b_o_n _t_r_a_v_a_i_l _e_n _m_a_t_i_e_r_e _d_e _c_o_m_p_a_r_a_i_s_o_n _d_e _m_a_t_e_r_i_e_l_/_S_E _s_i_m_i_l_a_i_r_e_s _e_n _m_o_d_e _S_M_P _e_t _e_n _m_o_d_e _U_P_._" (ndt : SMP = Symetric Multi-Processing, UP = Uni-Processor) 44.. UUnnee eexxeeccuuttiioonn ttyyppee eett lleess rreessuullttaattss Le LBT a ete lance sur ma machine perso., une machine de classe Pentium tournant Linux que j'ai assemblee moi-meme et que j'utilise pour ecrire ce HOWTO. Voici le compte-rendu LBT pour ce systeme : LINUX BENCHMARKING TOOLKIT REPORT FORM CPU == Vendor: Cyrix/IBM Model: 6x86L P166+ Core clock: 133 MHz Motherboard vendor: Elite Computer Systems (ECS) Mbd. model: P5VX-Be Mbd. chipset: Intel VX Bus type: PCI Bus clock: 33 MHz Cache total: 256 KB Cache type/speed: Pipeline burst 6 ns SMP (number of processors): 1 RAM ==== Total: 32 MB Type: EDO SIMMs Speed: 60 ns Disk ==== Vendor: IBM Model: IBM-DAQA-33240 Size: 3.2 GB Interface: EIDE Driver/Settings: Bus Master DMA mode 2 Video board =========== Vendor: Generic S3 Model: Trio64-V2 Bus: PCI Video RAM type: EDO DRAM Video RAM total: 2 MB X server vendor: XFree86 X server version: 3.3 X server chipset choice: S3 accelerated Resolution/vert. refresh rate: 1152x864 @ 70 Hz Color depth: 16 bits Kernel ===== Version: 2.0.29 Swap size: 64 MB gcc === Version: 2.7.2.1 Options: -O2 libc version: 5.4.23 Test notes ========== Une charge tres faible. Les tests ci-dessus ont ete executes avec quelques unes des options specifiques du Cyrix/IBM 6x86 activees grace au programme setx86. Il s'agit de : fast ADS, fast IORT, Enable DTE, fast LOOP, fast Lin. VidMem. RESULTS ======== Linux kernel 2.0.0 Compilation Time: 7m12s Whetstones: 38.169 MWIPS. Xbench: 97243 xStones. BYTE Unix Benchmarks 4.01 system INDEX: 58.43 BYTEmark integer INDEX: 1.50 BYTEmark memory INDEX: 2.50 Comments ========= Il s'agit la d'une configuration tres stable et dotee de performances homogenes, ideale pour une utilisation individuelle et/ou developper sous Linux. Je rendrai compte des resultats obtenus avec un 6x86MX des que j'aurai reussi a mettre la main sur l'un d'entre eux ! 55.. PPiieeggeess eett mmiisseess eenn ggaarrddee eenn mmaattiieerree dd''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess Apres avoir compile ce HOWTO, j'ai commence a comprendre pourquoi les mots de "piege" et de "mise en garde" sont si souvent associes a l'evaluation de performances. 55..11.. CCoommppaarreerr ddeess ppoommmmeess eett ddeess oorraannggeess Ou devrais-je dire des Apples et des PCs ? (ndt : pour gouter pleinement toute la finesse de ce jeu de mots, il faut quand meme savoir que pomme se dit apple en anglais :-) C'est tellement evident et c'est une controverse tellement eculee que je ne rentrerai pas dans les details. Je doute que le temps necessaire pour booter un Mac compare a celui d'un Pentium moyen soit une veritable mesure de quoi que ce soit. De facon similaire on pourrait parler du boot de Linux vs. Windows NT, etc... Essayez autant que possible de comparer des machines identiques a une seule difference pres. 55..22.. IInnffoorrmmaattiioonn iinnccoommpplleettee Un seul exemple suffira a l'illustration de cette erreur tres courante. On lit souvent dans comp.os.linux.hardware l'affirmation suivante : "Je viens tout juste d'enficher le processeur XYZ qui tourne a nnn MHz et la compilation du noyau prend maintenant i minutes (ajustez XYZ, nnn et i selon vos besoins). C'est enervant parce qu'aucune autre information n'est fournie: on ne connait meme pas la quantite de RAM, la taille du swap, les autres taches qui tournaient a ce moment la, la version du noyau, les modules selectionnes, le type de disque dur, la version de gcc, etc... Je vous recommende d'utiliser le formulaire de compte-rendu LBT, lequel fournit au moins un cadre informationnel standard. 55..33.. MMaatteerriieell//llooggiicciieell pprroopprriieettaaiirree Un fabriquant de micro-processeurs bien connu a publie naguere des resultats de benchmarks produits avec une version speciale et personnalisee de gcc. Considerations ethiques mises a part, ces resultats sont denues de toute signification, en effet, la totalite de la communaute Linux aurait utilise la version standard de gcc. Le meme genre de consideration vaut aussi pour le materiel proprietaire. L'evaluation de performances est beaucoup plus utile quand elle va de pair avec du materiel sur etagere et du logiciel gratuit (au sens GNU/GPL). 55..44.. PPeerrttiinneennccee On parle de Linux, non ? On devrait donc faire abstraction des benchmarks produits sous d'autres systemes d'exploitation (ceci est une instance particuliere de la comparaison des pommes et des oranges mentionnee plus haut). Si l'on se propose d'evaluer la performance d'un serveur Web, on pourra aussi se dispenser de citer la performance FPU et toute autre information non-pertinente. Dans de tels cas, moins c'est plus. Enfin, vous n'avez pas non plus besoin de parler de l'age de votre chat, de votre humeur pendant que vous procedez a une evaluation de performances, etc... 66.. FFAAQQ QQ11.. Existe-t-il un indice de performances specifique aux machines Linux ? AA.. Non, Dieu merci personne n'a encore invente de mesure du type Lhinuxstone (tm). Meme si c'etait le cas, ca n'aurait pas beaucoup de sens : les machines Linux sont utilisees pour des taches tellement differentes allant des serveurs Web lourdement charges aux stations graphiques pour utilisation individelle. Aucun facteur de merite ne peut decrire les performances d'une machine Linux dans des situations si differentes. QQ22.. Alors, pourquoi ne pas choisir une douzaine de metriques pour resumer la performance de diverses machines Linux ? AA.. Ca serait une situation ideale. J'aimerai voir ca devenir une realite. Y-a-t-il des volontaires pour un pprroojjeett dd''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess ssoouuss LLiinnuuxx ? Avec un site Web et une base de donnees de rapports bien concus, complete et en ligne ? QQ33.. AA.. Les BogoMips n'ont strictement rien a voir avec la performance de votre machine. Voir le BogoMips Mini-HOWTO. QQ44.. Quel est le "meilleur" benchmark pour Linux ? AA.. Ca depend completement de quel aspect des performances d'une machine Linux on souhaite mesurer. Il y a des benchmarks differents pour faire des mesures reseau (taux de transfert soutenu sous Ethernet), des mesures de serveur de fichiers (NFS), de bande passante, de performance CAO, de temps de transaction, de performance SQL, de performances de serveur Web, de performance temps-reel, de performance CD-ROM, de performance sous Quake (!), etc ... Pour autant que je sache, aucune suite de benchmarks supportant tous ces tests n'existe pour Linux. QQ55.. Quel est le processeur le plus rapide pour Linux ? AA.. Le plus rapide pourquoi faire ? Si on est plutot oriente calcul intensif, alors un Alpha a frequence d'horloge elevee (600 MHz et ca continue a grimper) devrait etre plus rapide que n'importe quoi d'autre, du fait que les Alphas ont ete concus dans cette optique. D'un autre cote, si vous voulez vous constituer un serveur de news tres rapide, il est probable que le choix d'un sous-systeme disque rapide et de beaucoup de RAM vous menera a de meilleures ameliorations de performances qu'un changement de processeur (a prix constant). QQ66.. Laissez-moi reformuler la derniere question, alors : y-a-t-il un processeur qui soit le plus rapide dans les applications d'usage general ? AA.. C'est une question delicate mais la reponse est simple : NON. On peut toujours concevoir un systeme plus rapide meme pour des applications d'usage general independamment du processeur. D'ordinaire, en conservant tous les autres parametres a leur valeur nominale, des frequences d'horloge plus elevees permettent d'obtenir de meilleures performances (ndt : surtout si on parle de systemes synchrones :-) et aussi plus de maux de tete. Si vous retirez un vieux Pentium a 100 MHz d'une carte- mere (laquelle n'est pas souvent) upgradable, et que vous le remplaciez par un Pentium 200 MHz MMX vous devriez sentir une difference de performances notable. Bien sur, pourquoi se contenter de 16 MB de RAM ? Le meme investissement aurait ete fait de facon encore plus avisee au profit de quelques SIMMs supplementaires... QQ77.. Donc la frequence d'horloge du processeur a une influence sur la performance d'un systeme ? AA.. La plupart des taches sauf les boucles de NOP (qui sont d'ailleurs supprimees a la compilation par les compilateurs modernes) une augmentation de la frequence d'horloge permettra d'obtenir une augmentation lineaire de la performance. Des applications gourmandes en ressources CPU et tres petites (pouvant donc tenir dans le cache L1 : 8 ou 16KB) verront leur performances augmenter dans la meme proportion que l'augmentation de la frequence d'horloge. Cependant les "vrais" programmes comportent des boucles qui ne tiennent pas dans le cache primaire, doivent partager le cache secondaire (externe) avec d'autres processus et dependent de composants externes (ndt : pour les E/S) beneficieront d'un gain de performance beaucoup moins important. Tout ceci parce que le cache L1 fonctionne a la meme frequence d'horloge que le processeur, alors que la plupart des caches L2 et des autres sous-systemes (DRAM par exemple) tournent en asynchrone a des frequences plus basses. QQ88.. D'accord, dans ce cas, une derniere question sur le sujet : quel est le processeur presentant le meilleur rapport prix/performance pour une utilisation d'usage general sous Linux ? AA.. Definir une "utilisation d'usage general sous Linux" n'est pas chose facile ! Etant donnee une application quelconque, il y a toujours moyen de determiner quel processeur du moment detient le meilleur rapport prix/performance pour ladite application. Mais les choses changent si rapidement a mesure que les fabriquants diffusent de nouveaux processeurs, que dire "le processeur XYZ a n MHz est le choix du moment" serait forcement reducteur. Cependant, le prix du processeur n'est pas significatif dans le cout d'un systeme complet que l'on assemble soi-meme. Donc, la question devrait plutot etre "comment maximize-t-on le rapport performance/cout d'une machine donnee ?" Et la reponse a cette question depend en grande partie des besoins en performance minimale garantie et/ou du cout maximal de la configuration que l'on considere. Il arrive parfois que le materiel sur etagere ne permette pas d'atteindre les besoins en performance minimale garantie que l'on souhaite obtenir et que des systemes RISC couteux soient la seule alternative viable. Pour une utilisation personnelle, je recommende une configuration equilibree et homogene du point de vue de la performance globale (et maintenant debrouillez vous pour deviner ce que j'entends par equilibre et homogene :-); le choix d'un processeur est une decision importante, mais pas plus que celle du disque dur et de sa capacite, celle de la quantite de RAM, celle de la carte graphique, etc... QQ99.. Qu'est-ce qu'une amelioration significative des performances ? AA.. Je dirais que tout ce qui est sous 1% n'est pas significatif (pourrait etre decrit comme marginal). Nous autres, simples mortels, avons du mal a percevoir la difference entre 2 systemes dont les temps de reponses sont distants de moins de 5% . Bien sur, certains evaluateurs de performances - plutot de la tendance integriste - ne sont aucunement humains et vous raconteront, en comparant 2 systemes dont les indices de performances sont de 65.9 et de 66.5, que ce dernier est indubitablement plus rapide. QQ1100.. Comment puis-je obtenir une amelioration significative de performance a moindre cout ? AA.. Puisque le code source complet de Linux est disponible, un examen attentif et une re-conception algorithmique de procedures cles peuvent, dans certains cas, deboucher sur des ameliorations jusqu'a un facteur 10 en terme de performance. Si l'on est sur un projet commercial et qu'on ne souhaite pas plonger dans les trefonds du code source du systeme, ll''iimmpplliiccaattiioonn dd''uunn ccoonnssuullttaanntt LLiinnuuxx eesstt nneecceessssaaiirree. Cf. le Consultants-HOWTO. 77.. CCooppyyrriigghhtt,, rreemmeerrcciieemmeennttss eett ddiivveerrss 77..11.. CCoommmmeenntt ccee ddooccuummeenntt aa--tt--iill eettee pprroodduuiitt La premiere etape a consiste en la lecture de la section 4 "Writing and submitting a HOWTO" de l'index des HOWTOs ecrit par Greg Hankins. Je ne savais absolument rien au sujet de SGML ou de LaTeX mais, apres avoir lu divers commentaires a propos de SGML-Tools, j'etais tente d'utiliser un paquetage de generation de documentation automatique. Cependant l'insertion manuelle de directives de formattage me rappelait l'epoque ou j'assemblais a la main un moniteur 512 octets pour un processeur 8 bits aujourd'hui disparu. J'ai donc fini par recuperer les sources de LyX, les compiler et je m'en suis servi dans son mode LinuxDoc. Une association chaudement recommendee : LLyyXX eett SSGGMMLL--TToooollss. 77..22.. CCooppyyrriigghhtt Le Linux Benchmarking HOWTO est place sous le regime du copyright (C) 1997 par Andre D. Balsa. Les HOWTO Linux peuvent etre reproduits en totalite ou en partie et distribues en totalite ou partiellement sur n'importe quel support physique ou electronique, a condition que ce message de copyright soit conserve dans toutes les copies. La redistribution commerciale est permise et encouragee; cependant l'auteur aimerait etre prevenu de l'existence de telles distributions. Toute traduction (ndt : dont acte :-), tout travail derive ou peripherique incorporant un HOWTO Linux doit etre couvert par ce message de copyright. C'est-a-dire qu'il ne vous est pas possible de produire un travail derive a partir d'un HOWTO et d'imposer des restrictions supplementaires sur sa distribution. Des exceptions a cette regle pourront etre accordees sous certaines conditions; veuillez contacter le coordinateur des HOWTO Linux a l'adresse specifiee ci-apres. Pour etre bref, nous souhaitons promouvoir la dissemination de cette information par autant de canaux que possible. Cependant, nous souhaitons garder un droit de copyright sur les HOWTOs et aimerions etre averti de tout projet de redistribution les concernant. Si vous avez des questions, veuillez contacter Greg Hankins, le coordinateur des HOWTOs Linux, a gregh@sunsite.unc.edu par e-mail ou au +1 404 853 9989 par telephone. (ndt : pour cette version francaise du document original, il semble plus approprie de contacter Eric Dumas, coordinateur des traductions de HOWTOs dans la langue de Moliere par e-mail a l'adresse dumas@freenix.EU.org). 77..33.. NNoouuvveelllleess vveerrssiioonn ddee ccee ddooccuummeenntt De nouvelles version du Benchmarking-HOWTO Linux seront mises a disposition sur sunsite.unc.edu et sur les sites mirroir (ndt : citons ftp.lip6.fr pour nous autres francophones). Ce document existe aussi sous d'autres formats tels que PostScript et dvi, et sont disponibles dans le repertoire other-formats. Le Benchmarking-HOWTO Linux est egalement disponible pour des clients WWW comme Grail, un butineur Web ecrit en Python. Il sera aussi poste regulierement sur comp.os.linux.answers. 77..44.. RReettoouurr Les suggestions, corrections, et ajouts sont desires. Les contributeurs sont les bienvenus et en seront remercies. Les incendies (ndt : est-ce une traduction acceptable de flame ?) sont a rediriger sur /dev/null. Je serai toujours joignable a andrewbalsa@usa.net. 77..55.. RReemmeerrcciieemmeennttss David Niemi, l'auteur de la suite Unixbench, s'est avere etre une source inepuisable d'informations et de critiques (fondees). Je veux aussi remercier Greg Hankins, le coordinateur des HOWTO Linux et l'un des principaux contributeurs au paquetage SGML-tools, Linus Torvalds et toute la communaute Linux. Ce HOWTO est ma facon de renvoyer l'ascenseur. 77..66.. PPaarraavveenntt Votre kilometrage peut varier et variera sans doutes. Soyez conscients que l'evaluation de performances est un sujet tres sensible et une activite qui consomme enormement de temps et d'energie. 77..77.. MMaarrqquueess ddeeppoosseeeess Pentium et Windows NT sont des marques deposees d'Intel et de Microsoft Corporations respectivement. BYTE et BYTEmark sont des marques deposees de McGraw-Hill, Inc. Cyrix et 6x86 sont des marques deposees de Cyrix Corporation. Linux n'est pas une marque deposee, et esperons qu'elle ne le sera jamais.