<HTML> <HEAD> <TITLE>Procédures d'évaluation de performances et interprétation des résultats</TITLE> </HEAD> <BODY> <H1>2. <A NAME="s2"></A>Procédures d'évaluation de performances et interprétation des résultats</H1> <P> <A HREF="Benchmarking-HOWTO.html#toc2">Contenu de cette section</A></P> <P></P> <P>Quelques recommendations semi-évidentes :</P> <P> <OL> <LI> Premièrement et avant tout, <B>identifiez vos objectifs d'évaluation de performances</B>. Qu'essayez vous exactement d'évaluer ? En quoi un processus d'évaluation de performances va-t-il vous aider à prendre une décision ultérieure ? Combien de temps et quelles ressources voulez-vous consacrer à cet effort ?</LI> <LI> <B>Utilisez des outils standard</B>. Utilisez une version à jour et stable du noyau, des versions standard et à jour de gcc et de la libc, et un benchmark standard. En bref, utilisez le LBT (voir plus loin).</LI> <LI> Donnez une <B>description complète</B> de votre configuration matérielle (voir le formulaire de compte-rendu plus loin).</LI> <LI> Essayez d'<B>isoler une variable unique</B>. L'évaluation de performances comparative est plus informative que l'évaluation de performances "absolue". <B>Je n'insisterai jamais assez là-dessus</B>.</LI> <LI> <B>Vérifiez vos résultats</B>. Faites tourner vos benchmarks plusieurs fois et vérifiez les variations des résultats obtenus, si variation il y a. Des variations inexpliquées invalideront vos résultats.</LI> <LI> Si vous pensez que votre effort d'évaluation de performances a produit de l'information significative, <B>partagez-la</B> avec la communauté Linux de façon <B>précise</B> et <B>concise</B>.</LI> <LI> <B>Oubliez les BogoMips</B> s'il vous plait. Je me promets d'implémenter un jour un ASIC (ndt : un acronyme pour Application Specific Integrated Circuit, c'est un circuit intégré dédié à une application donnée) dans lequel les BogoMips seront cablés. Et alors on verra ce qu'on verra !</LI> </OL> </P> <P></P> <H2>2.1 <A NAME="ss2.1"></A> Comprendre les choix en matière de benchmarks</H2> <P></P> <P></P> <H3>Benchmarks synthétiques vs. benchmarks applicatifs</H3> <P></P> <P>Avant de consacrer le moindre temps aux travaux d'évaluation de performances, il importe de faire un choix de base entre benchmarks synthétiques et benchmarks applicatifs.</P> <P>Les benchmarks synthétiques sont spécifiquement conçus pour mesurer la performance des composants individuels d'un ordinateur, d'habitude en poussant l'un desdits composants jusqu'à sa limite. Un exemple de benchmark synthétique célebre est la suite <B>Whetstone</B>, initialement programmée en 1972 par Harold Curnow en FORTRAN (ou était-ce en ALGOL ?), et dont l'usage est toujours très répandu de nos jours. La suite Whetstone produira une mesure de la performance d'une CPU en matière de calcul flottant.</P> <P>La principale critique que l'on puisse faire aux benchmarks synthétiques est qu'ils ne représentent pas la performance d'un ordinateur, en tant que système complexe, dans des conditions d'utilisation réelles. Prenons par exemple la suite Whetstone, dont la boucle principale est très courte, et qui donc peut aisément tenir dans le cache primaire d'une CPU, cette suite maintient le pipeline de la FPU alimenté en permanence de façon à pousser celle-ci à sa vitesse maximale. On ne peut pas vraiment critiquer la suite Whetstone si l'on se souvient qu'elle a été programmée il y a 25 ans (sa conception est même plus ancienne que ça !), mais il nous faut nous assurer que nous interprétons ses résultats avec prudence quand nous nous préoccupons d'évaluer les performances de micro-processeurs modernes.</P> <P>Un autre aspect très important qu'il nous faut avoir en tête à propos des benchmarks synthétiques est qu'idéalement, ils devraient pouvoir nous dire quelque chose en ce qui concerne un aspect <B>spécifique</B> du système que l'on est en train de tester, et ce indépendamment des autres aspects dudit sysème : un benchmark synthétique d'une carte D'E/S Ethernet devrait produire les mêmes résultats (ou des résultats 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'était pas le cas, le test mesurerait la performance globale de l'association CPU/carte-mère/bus/carte Ethernet/sous-système mémoire/DMA, ce qui n'est pas très utile puisque la différence au niveau des CPUs aura un impact plus important que la différence au niveau des cartes Ethernet (ceci suppose bien sûr que nous utilisions la même combinaison noyau/driver (pilote de périphérique)). Dans le cas contraire la différence de performances pourrait être encore plus grande) !</P> <P>Enfin, une erreur fréquemment commise est de calculer la moyenne de divers benchmarks synthétiques et de prétendre qu'une telle moyenne est une bonne représentation de la performance globale d'un système donné pour une utilisation dans la vie réelle.</P> <P>Voici un commentaire sur les benchmarks FPU (cité avec la permission du site Web de Cyrix Corp.) :</P> <P> <BLOCKQUOTE> <EM> "Une unité de calcul flottant accélère le logiciel conçu pour l'utilisation de l'arithmétique flottante : typiquement il s'agit de programmes de CAO, de tableurs, de jeux en 3D et d'applications de conception. Cependant, la plupart des applications PC populaires d'aujourd'hui utilisent à la fois des instructions flottantes et l'arithmétique entière. C'est pourquoi Cyrix a choisi de mettre l'accent sur le parallélisme lors de la conception du processeur 6x86 et ce dans le but d'accélérer les programmes qui entremêlent ces 2 types d'instructions. </EM> </BLOCKQUOTE> <BLOCKQUOTE> <EM> Le modèle de traitement des exceptions flottantes de l'architecture x86 permet aux instructions entières d'être émises et de se terminer pendant qu'une instruction flottante est en cours d'exécution. A l'opposé, une seconde opération flottante ne pourra pas être exécutée alors qu'une précedente instruction flottante est en cours d'exécution. Pour supprimer cette limitation de performance créee par le modèle de traitement des exceptions flottantes, le 6x86, peut émettre spéculativement jusqu'à 4 instructions flottantes vers la FPU intégrée sur le circuit. Par exemple, dans une séquence de code constituée de 2 instructions flottantes (FLTs) suivies de 6 instructions entières (INTs), elles-mêmes suivies de 2 FLTs, le 6x86 peut émettre toutes ces 10 instructions vers les unités d'exécution appropriées avant que l'exécution de la première FLT ne se soit terminée. Si aucune de ces instructions ne provoque d'exception (ce qui est typique), l'exécution continue, les unités flottantes et entières terminant l'exécution de ces instructions en parallèle. Si l'une des FLTs génère une exception (le cas atypique), les possibilités d'exécution spéculatives du 6x86 permettent que l'état du processeur soit restitué de façon à ce que celui-ci soit compatible avec le modèle de traitement des exceptions flottantes. </EM> </BLOCKQUOTE> <BLOCKQUOTE> <EM> L'examen de code de benchmarks synthétiques flottants révèle que ceux-ci utilisent des séquences d'instructions purement flottantes que l'on ne trouve pas dans les applications du monde réel. Ce type de benchmarks ne tire pas profit des possibilités d'exécution spéculative du processeur 6x86. Cyrix pense que les benchmarks non-synthétiques basés sur des applications du monde réel reflètent mieux la performance que les utilisateurs vont effectivement obtenir. Les applications du monde réel contiennent des instructions entières et flottantes entremêlées et pour cette raison tireront un meilleur parti des possibilités d'exécution spéculative du 6x86." </EM> </BLOCKQUOTE> </P> <P>La tendance récente en matière d'évaluation de performances consiste donc à choisir des applications usuelles et à les utiliser pour mesurer la performance d'ordinateurs en tant que systèmes complexes. Par exemple <B>SPEC</B>, l'entreprise à but non-lucratif qui a conçu les célèbres suites de benchmarks synthétiques SPECINT et SPECFP, a lancé un projet pour développer une nouvelle suite de benchmarks applicatifs. Mais, là encore, il est très improbable qu'une telle suite de benchmarks commerciale comporte du code Linux un jour.</P> <P>En résumé, les benchmarks synthétiques sont valables à condition d'avoir compris leurs objectifs et leurs limites. Les benchmarks applicatifs reflèteront mieux la performance d'un système informatique, mais aucun d'entre eux n'est disponible pour Linux.</P> <P></P> <H3>Benchmarks de haut-niveau vs. de bas-niveau</H3> <P></P> <P>Les benchmarks de bas-niveau ont pour ambition la mesure de la performance du matériel : la fréquence 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'accès moyen d'un disque dur, temps d'accès piste à piste, etc...</P> <P>Cette approche peut être utile si vous avez acheté un système et que vous vous demandez à partir de quels composants il a été construit, bien qu'une meilleure façon de répondre à cette question soit d'ouvrir le boîtier, de dresser l'inventaire des composants que vous trouverez à l'intérieur, et d'obtenir les spécifications techniques pour chacun d'entre eux (elles sont la plupart du temps disponibles sur le Web).</P> <P>Une autre utilisation possible des benchmarks de bas-niveau consiste à s'en servir pour vérifier qu'un driver du noyau a été correctement configuré pour un composant matériel donné : si vous disposez des spécifications techniques de ce composant vous pourrez comparer les résultats d'un benchmark de bas-niveau aux valeurs théoriques figurant dans les specs.</P> <P>Les benchmarks de haut-niveau ont plutôt pour objectif la mesure de la performance de l'association matériel/driver/système d'exploitation en ce qui concerne un aspect spécifique d'un système informatique (par exemple la performance des entrées-sorties), ou même une association spécifique matériel/driver/système d'exploitation/application (par exemple un benchmark Apache sur différents ordinateurs).</P> <P>Bien sûr, tous les benchmarks de bas-niveau sont synthétiques. Les benchmarks de haut-niveau peuvent être synthétiques ou applicatifs.</P> <P></P> <H2>2.2 <A NAME="ss2.2"></A> Benchmarks standard disponibles pour Linux</H2> <P></P> <P>AMHA, un test simple que tout le monde peut effectuer à l'occasion d'une mise à jour de la configuration de sa machine Linux est de lancer une compilation du noyau avant et après cette mise à jour matérielle/logicielle, et de comparer les durées de compilation. Si tous les autres paramètres sont les mêmes, alors ce test est valable en tant que mesure de la performance en matière de compilation, et l'on peut affirmer en toute confiance que :</P> <P> <BLOCKQUOTE> "Le remplacement de A par B a conduit à une amélioration de x % de la durée de compilation du noyau Linux dans telles et telles conditions". </BLOCKQUOTE> </P> <P>Ni plus, ni moins !</P> <P>Parce que la compilation du noyau est une tâche très courante sous Linux, et parce qu'elle met en oeuvre la plupart des fonctionnalités impliquées dans les benchmarks usuels (sauf le calcul flottant), elle constitue un test <B>isolé</B> plutôt bon. Cependant, dans la majeure partie des cas, les résultats de ce test ne peuvent pas être reproduits par d'autres utilisateurs de Linux à cause des différences de configurations matérielles/logicielles. Ce test ne constitue donc en aucun cas une métrique permettant de comparer des systèmes dissemblables (à moins que nous ne nous mettions tous d'accord sur la compilation d'un noyau standard - voir plus loin).</P> <P>Malheureusement, il n'y a pas d'outils d'évaluation de performances ciblant spécifiquement Linux, sauf peut-être les Byte Linux Benchmarks. Ceux-ci sont une version légerement modifiée des Byte Unix Benchmarks qui datent de 1991 (modifications Linux par Jon Tombs, auteurs originels : Ben Smith, Rick Grehan et Tom Yager).</P> <P>Il existe un <A HREF="http://www.silkroad.com/bass/linux/bm.html">site Web</A> central pour les Byte Linux Benchmarks.</P> <P>Une version améliorée et mise à jour des Byte Unix Benchmarks a été synthétisée par David C. Niemi. Elle s'appelle UnixBench 4.01 pour éviter une confusion possible avec des versions antérieures. Voici ce que David a écrit au sujet de ses modifications :</P> <P> <BLOCKQUOTE> "Les BYTE Unix benchmarks originels et légerement modifiés sont nases à bien des égards ce qui fait d'eux un indicateur inhabituellement non-fiable de la performance d'un système. J'ai délibérément fait en sorte que mes indices de performance soient très différents pour éviter la confusion avec les vieux benchmarks." </BLOCKQUOTE> </P> <P>David a mis en place une liste majordomo de diffusion par courrier électronique pour les discussions relatives à l'évaluation de performances sous Linux et sous les systèmes d'exploitation concurrents. Vous pouvez vous joindre à ces discussions en envoyant un e-mail dont le corps contiendra "subscribe bench" à l'adresse <A HREF="mailto:majordomo@wauug.erols.com">majordomo@wauug.erols.com</A> . Les groupe des utilisateurs de la région de Washington est aussi en train de mettre en place un <A HREF="http://wauug.erols.com/bench ">site Web</A> concernant les benchmarks sous Linux.</P> <P>Récemment, Uwe F. Mayer, <A HREF="mailto:mayer@math.vanderbilt.edu">mayer@math.vanderbilt.edu</A> a également porté la suite Bytemark de BYTE sous Linux. Il s'agit d'une suite moderne et compilée très habilement par Rick Grehan du magazine BYTE. Bytemark teste les performances de la CPU, de la FPU et du sous-système mémoire des micro-ordinateurs modernes (ces benchmarks sont strictement orientés vers la performance du processeur, les E/S ou la performance globale du système ne sont pas pris en compte).</P> <P>Uwe a aussi mis en place un <A HREF="http://math.vanderbilt.edu:80/~mayer/linux/bmark.html">site Web</A> , site où l'on peut accéder à une base de données contenant les résultats de sa version des benchmarks BYTEmark pour Linux.</P> <P>Si vous êtes à la recherche de benchmarks synthétiques pour Linux, vous remarquerez assez vite que sunsite.unc.edu ne propose que peu d'outils d'évaluation 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.</P> <P> <A HREF="http://www.goof.com/xbench/">XFree86-benchmarks Survey</A> est un site Web comprenant une base de données de résultats relatifs à x-bench.</P> <P>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 grâce aux options -t et -T.</P> <P>Il existe plein d'autres outils disponibles librement (sous license GPL) sur Internet pour tester divers aspects de la performance de votre machine Linux.</P> <P></P> <H2>2.3 <A NAME="ss2.3"></A> Liens et références</H2> <P></P> <P>La FAQ du newsgroup comp.benchmarks par Dave Sill est la référence standard en matière d'évaluation de performances. Elle n'est pas particulièrement orientée Linux, mais elle n'en reste pas moins une lecture recommendée pour tous ceux qui font preuve d'un minimum de sérieux envers le sujet. Elle est disponible sur nombre de sites FTP et de sites Web et recense <B>56 benchmarks différents</B> avec des liens vers des sites FTP permettant de les télécharger. Cependant, certains des benchmarks recensés sont des produits commerciaux.</P> <P>Je n'entrerai pas dans la description détaillée des benchmarks mentionnés 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 <A HREF="http://reality.sgi.com/lm/lmbench/lmbench.html">suite lmbench</A> de Larry McVoy. Je cite David C. Niemi :</P> <P> <BLOCKQUOTE> <EM> "Linus et David Miller s'en servent beaucoup parce qu'elle permet des mesures de bas-niveau utiles et peut aussi quantifier la bande passante et la latence d'un réseau si vous avez deux machines à votre disposition pour le faire tourner. Mais lmbench n'essaie pas de produire un indice de performance global..."</EM> </BLOCKQUOTE> </P> <P>Un <A HREF="ftp://ftp.nosc.mil/pub/aburto">site FTP</A> assez complet en matière de benchmarks disponibles <B>librement</B> a été mis en place par Alfred Aburto. La suite Whetstone utilisée dans le LBT est disponible sur ce site.</P> <P>Une <B>FAQ multi-fichier par Eugene Miya</B> est également postée sur comp.benchmarks; c'est une excellente référence.</P> <P></P> <HR> <P> Chapitre <A HREF="Benchmarking-HOWTO-3.html">suivant</A>, Chapitre <A HREF="Benchmarking-HOWTO-1.html">Précédent</A> <P> Table des matières de <A HREF="Benchmarking-HOWTO.html#toc2">ce chapitre</A>, <A HREF="Benchmarking-HOWTO.html#toc">Table des matières</A> générale</P> <P> <A HREF="Benchmarking-HOWTO.html">Début</A> du document, <A HREF="#0"> Début de ce chapitre</A></P> </BODY> </HTML>
