Quelques recommendations semi-�videntes :
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.
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 Whetstone, 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.
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.
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 sp�cifique 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) !
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.
Voici un commentaire sur les benchmarks FPU (cit� avec la permission du site Web de Cyrix Corp.) :
"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.
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.
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."
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 SPEC, 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.
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.
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...
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).
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.
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).
Bien s�r, tous les benchmarks de bas-niveau sont synth�tiques. Les benchmarks de haut-niveau peuvent �tre synth�tiques ou applicatifs.
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 :
"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".
Ni plus, ni moins !
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 isol� 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).
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).
Il existe un site Web central pour les Byte Linux Benchmarks.
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 :
"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."
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 majordomo@wauug.erols.com. Les groupe des utilisateurs de la r�gion de Washington est aussi en train de mettre en place un site Web concernant les benchmarks sous Linux.
R�cemment, Uwe F. Mayer, mayer@math.vanderbilt.edu 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).
Uwe a aussi mis en place un site Web, site o� l'on peut acc�der � une base de donn�es contenant les r�sultats de sa version des benchmarks BYTEmark pour Linux.
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.
XFree86-benchmarks Survey est un site Web comprenant une base de donn�es de r�sultats relatifs � 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 gr�ce 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.
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 56 benchmarks diff�rents avec des liens vers des sites FTP permettant de les t�l�charger. Cependant, certains des benchmarks recens�s sont des produits commerciaux.
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 suite lmbench de Larry McVoy. Je cite David C. Niemi :
"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..."
Un site FTP assez complet en mati�re de benchmarks disponibles librement a �t� mis en place par Alfred Aburto. La suite Whetstone utilis�e dans le LBT est disponible sur ce site.
Une FAQ multi-fichier par Eugene Miya est �galement post�e sur comp.benchmarks; c'est une excellente r�f�rence.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:25