  Benchmarking HOWTO Linux
  par  Andre  D.  Balsa,  andrewbalsa@usa.net  <mailto:andrew-
  balsa@usa.net>
  traduit    par    Francois     Laagel,     f.laagel@ieee.org
  <mailto: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...

  11..  IInnttrroodduuccttiioonn

  _"_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  mmeessuurreerr  la
  vitesse a laquelle un ordinateur execute une tache calculatoire, et ce
  de   facon   a    pouvoir    comparer    differentes    configurations
  logicielles/materielles.  Ceci  n'a  aauuccuunn  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.

  11..11..  PPoouurrqquuooii ll''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess eesstt--eellllee ssii iimmppoorrttaannttee ??

  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  ccoouutt  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 ssttaabbiilliittee est toujours plus importante que
  la vitesse d'execution.

  11..22..  NNoonn--ccrriitteerreess eenn mmaattiieerree dd''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess

  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.

  22..  PPrroocceedduurreess dd''eevvaalluuaattiioonn  ddee  ppeerrffoorrmmaanncceess  eett  iinntteerrpprreettaattiioonn  ddeess
  rreessuullttaattss

  Quelques recommendations semi-evidentes :

  1. Premierement et avant tout, iiddeennttiiffiieezz vvooss  oobbjjeeccttiiffss  dd''eevvaalluuaattiioonn
     ddee  ppeerrffoorrmmaanncceess. 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. UUttiilliisseezz ddeess oouuttiillss ssttaannddaarrdd. 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 ddeessccrriippttiioonn ccoommpplleettee de votre  configuration  materielle
     (voir le formulaire de compte-rendu plus loin).

  4. Essayez  d'iissoolleerr uunnee vvaarriiaabbllee uunniiqquuee. L'evaluation de performances
     comparative est plus informative que l'evaluation  de  performances
     "absolue". JJee nn''iinnssiisstteerraaii jjaammaaiiss aasssseezz llaa--ddeessssuuss.

  5. VVeerriiffiieezz  vvooss  rreessuullttaattss.  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,  ppaarrttaaggeezz--llaa   avec   la
     communaute Linux de facon pprreecciissee et ccoonncciissee.

  7. OOuubblliieezz  lleess  BBooggooMMiippss 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 !

  22..11..  CCoommpprreennddrree lleess cchhooiixx eenn mmaattiieerree ddee bbeenncchhmmaarrkkss

  22..11..11..  BBeenncchhmmaarrkkss ssyynntthheettiiqquueess vvss.. bbeenncchhmmaarrkkss aapppplliiccaattiiffss

  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  WWhheettssttoonnee,  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 ssppeecciiffiiqquuee 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 SSPPEECC, 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.

  22..11..22..  BBeenncchhmmaarrkkss ddee hhaauutt--nniivveeaauu vvss.. ddee bbaass--nniivveeaauu

  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.

  22..22..  BBeenncchhmmaarrkkss ssttaannddaarrdd ddiissppoonniibblleess ppoouurr LLiinnuuxx

  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 iissoollee 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   <mailto: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
  <mailto: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.

  22..33..  LLiieennss eett rreeffeerreenncceess

  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 5566 bbeenncchhmmaarrkkss ddiiffffeerreennttss 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
  lliibbrreemmeenntt  a  ete  mis  en place par Alfred Aburto. La suite Whetstone
  utilisee dans le LBT est disponible sur ce site.

  Une FFAAQQ  mmuullttii--ffiicchhiieerr  ppaarr  EEuuggeennee  MMiiyyaa  est  egalement  postee  sur
  comp.benchmarks; c'est une excellente reference.

  33..  LLee LLiinnuuxx BBeenncchhmmaarrkkiinngg TToooollkkiitt ((LLBBTT))

  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.

  33..11..  MMoottiivvaattiioonnss

  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 ssyynntthheettiiqquueess devrait pousser un  sous-systeme
     particulier a ses limites.

  6. Les  resultats  des  benchmarks  ssyynntthheettiiqquueess ne devraient ppaass 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.

  33..22..  SSeelleeccttiioonn ddeess bbeenncchhmmaarrkkss

  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.

  33..33..  DDuurreeee ddeess tteessttss

  1. Compilation du noyau 2.0.0 : 5 - 30 minutes, selon  la  performance
     rreeeellllee 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.

  33..44..  CCoommmmeennttaaiirreess

  33..44..11..  CCoommppiillaattiioonn dduu nnooyyaauu 22..00..00

  +o  QQuuooii :: 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  RReessuullttaattss  ::  la  duree de compilation en minutes et secondes (s'il
     vous plait, ne rapportez pas les fractions de secondes).

  33..44..22..  LLaa ssuuiittee WWhheettssttoonnee

  +o  QQuuooii :: 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  RReessuullttaattss  :: un indice de performance en calcul flottant exprime en
     MWIPS.

  33..44..33..  XXbbeenncchh--00..22

  +o  QQuuooii :: 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  RReessuullttaattss :: un indice de performances exprime en xStones.

  +o  Note : ce test, en l'etat, est depasse. Il devrait etre re-ecrit.

  33..44..44..  UUnniixxBBeenncchh vveerrssiioonn 44..0011

  +o  QQuuooii : 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  RReessuullttaattss :: un indice de performance du systeme.

  (ndt  :  la  moyenne  geometrique se definit comme la racine n-ieme du
  produit des n termes consideres)
  33..44..55..  LLeess bbeenncchhmmaarrkkss BByytteemmaarrkk dduu mmaaggaazziinnee BBYYTTEE

  +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'iinnddiiccee  mmeemmooiirree. Calculez  la moyenne geometrique des indices des
     tests NUMERIC SORT, IDEA, HUFFMAN et FP EMULATION:  c'est  l'iinnddiiccee
     eennttiieerr.

  +o  RReessuullttaattss  ::  un  indice memoire et un indice entier calcules comme
     explique ci-dessus.

  33..55..  AAmmeelliioorraattiioonnss ppoossssiibblleess

  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.

  33..66..  FFoorrmmuullaaiirree ddee rraappppoorrtt LLBBTT

  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.
  ______________________________________________________________________

  33..77..  TTeesstt ddee ppeerrffoorrmmaanncceess rreesseeaauu

  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)

  33..88..  LLeess tteessttss SSMMPP

  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)

  44..  UUnnee eexxeeccuuttiioonn ttyyppee eett lleess rreessuullttaattss

  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 !

  55..  PPiieeggeess eett mmiisseess eenn ggaarrddee eenn mmaattiieerree dd''eevvaalluuaattiioonn ddee ppeerrffoorrmmaanncceess

  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.

  55..11..  CCoommppaarreerr ddeess ppoommmmeess eett ddeess oorraannggeess

  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.

  55..22..  IInnffoorrmmaattiioonn iinnccoommpplleettee

  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.

  55..33..  MMaatteerriieell//llooggiicciieell pprroopprriieettaaiirree

  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).

  55..44..  PPeerrttiinneennccee

  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...

  66..  FFAAQQ

     QQ11..
        Existe-t-il un indice de performances  specifique  aux  machines
        Linux ?
     AA.. 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.

     QQ22..
        Alors,  pourquoi  ne  pas choisir une douzaine de metriques pour
        resumer la performance de diverses machines Linux ?

     AA.. Ca serait une situation ideale. J'aimerai voir  ca  devenir  une
        realite. Y-a-t-il des volontaires pour un pprroojjeett dd''eevvaalluuaattiioonn ddee
        ppeerrffoorrmmaanncceess ssoouuss LLiinnuuxx ? Avec  un  site  Web  et  une  base  de
        donnees de rapports bien concus, complete et en ligne ?

     QQ33..

     AA.. Les  BogoMips  n'ont strictement rien a voir avec la performance
        de votre machine. Voir le BogoMips Mini-HOWTO.

     QQ44..
        Quel est le "meilleur" benchmark pour Linux ?

     AA.. 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.

     QQ55..
        Quel est le processeur le plus rapide pour Linux ?

     AA.. 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).

     QQ66..
        Laissez-moi reformuler la derniere question, alors : y-a-t-il un
        processeur qui soit le plus rapide dans les applications d'usage
        general ?

     AA.. 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...

     QQ77..
        Donc la frequence d'horloge du processeur a une influence sur la
        performance d'un systeme ?

     AA.. 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.

     QQ88..
        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
        ?

     AA.. 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...

     QQ99..
        Qu'est-ce qu'une amelioration significative des performances ?

     AA.. 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.
     QQ1100..
        Comment   puis-je  obtenir  une  amelioration  significative  de
        performance a moindre cout ?

     AA.. 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,  ll''iimmpplliiccaattiioonn  dd''uunn
        ccoonnssuullttaanntt LLiinnuuxx eesstt nneecceessssaaiirree. Cf. le Consultants-HOWTO.

  77..  CCooppyyrriigghhtt,, rreemmeerrcciieemmeennttss eett ddiivveerrss

  77..11..  CCoommmmeenntt ccee ddooccuummeenntt aa--tt--iill eettee pprroodduuiitt

  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 : LLyyXX eett
  SSGGMMLL--TToooollss.

  77..22..  CCooppyyrriigghhtt

  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).

  77..33..  NNoouuvveelllleess vveerrssiioonn ddee ccee ddooccuummeenntt

  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.

  77..44..  RReettoouurr

  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.

  77..55..  RReemmeerrcciieemmeennttss

  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.

  77..66..  PPaarraavveenntt

  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.

  77..77..  MMaarrqquueess ddeeppoosseeeess

  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.

