Benchmarking HOWTO Linux
par Andre D. Balsa,
[email protected] <mailto:andrew-
[email protected]>
traduit par Francois Laagel,
[email protected]
<mailto:
[email protected]>
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
[email protected] <mailto:
[email protected]>. 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,
[email protected]
<mailto:
[email protected]> 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
[email protected] 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
[email protected]).
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
[email protected].
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.
