"Ce dont on ne peut parler doit �tre pass� sous silence."
Ludwig Wittgenstein (1889-1951), philosophe Autrichien
L'�valuation de performances (benchmarking) consiste � mesurer la vitesse � laquelle un ordinateur ex�cute une t�che calculatoire, et ce de fa�on � pouvoir comparer diff�rentes configurations logicielles/mat�rielles. Ceci n'a aucun rapport avec la facilit� d'utilisation, l'esth�tique, les consid�rations d'ergonomie ou toute autre appr�ciation subjective.
L'�valuation de performances est une t�che fastidieuse et r�p�titive. Elle n�c�ssite que l'on pr�te une grande attention aux d�tails. Tr�s souvent les r�sultats obtenus ne sont pas ceux auxquels on s'attendait et sont sujet � interpr�tation (ce qui peut tr�s bien �tre le but d'une proc�dure d'�valuation de performances).
Enfin, l'�valuation de performances tra�te de faits et de chiffres et non pas d'opinion ou d'approximation.
Hormis les raisons mentionn�es dans le BogoMips Mini-HOWTO (section 7, paragraphe 2), il arrive, lorsque l'on se constitue une machine Linux, que l'on soit confront� � un budget limit� et/ou � des besoins en performances minimales garanties.
En d'autres termes, lorsque l'on se pose les questions suivantes :
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 � �valuer les performances d'un syst�me informatique).
Minimiser les co�ts sans contraintes de performance implique d'ordinaire la constitution d'une machine � partir de composants de r�cup�ration (ce vieux 386SX-16 qui tra�ne dans le garage sera parfait), et ne n�c�ssite pas de benchmarks. Maximiser la performance sans co�t plafond n'est pas une situation r�aliste (� moins que l'on souhaite mettre un Cray dans son salon - la banquette recouverte de cuir qui se trouve au dessus des alimentations �lectriques est du meilleur go�t, n'est-t-il pas ?).
L'�valuation de performances sans contrainte de co�t ni de performance minimale garantie n'a pas de sens: c'est une perte de temps et d'argent. L'�valuation de performances n'a de sens que dans le cadre d'une prise de d�cision, c'est � dire si l'on a le choix entre deux alternatives ou plus.
D'ordinaire des crit�res autres que le co�t interviennent dans le processus d�cisionnel. Il peut s'agir de la disponibilit�, du service, de la fiabilit�, de consid�rations strat�giques ou de toute autre caract�ristique rationnelle et mesurable d'un syst�me informatique. Par exemple, lorsque l'on compare la performance de diff�rentes versions du noyau Linux, la stabilit� est toujours plus importante que la vitesse d'ex�cution.
Malheureusement et tr�s souvent dans les newsgroups (forums) et les mailing lists (listes de diffusion par courrier �lectronique), sont cit�s :
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.
Je propose ici un ensemble d'outils pour l'�valuation de performances sous Linux. C'est la version pr�liminaire d'un vaste environnement d'�valuation de performances pour Linux, il est destin� � �tre am�lior� et � voir ses fonctionnalit�s �tendues. Prenez le pour ce qu'il vaut, c'est-�-dire une proposition. Si vous pensez que cette suite de test n'est pas valable, prenez la libert� de m'envoyer (ndt : � l'auteur et non au traducteur, merci :-) vos critiques par e-mail et soyez s�rs que je serai heureux d'int�grer les changements que vous aurez sugg�r� dans la mesure du possible. Avant d'entamer une pol�mique, lisez ce HOWTO et les documents cit�s en r�f�rence : les critiques inform�s sont les bienvenus, les critiques st�riles ne le sont pas.
Elles sont dict�es par le bon sens, tout simplement :
J'ai s�lectionn� 5 suites des benchmarks diff�rentes en �vitant autant que possible les recouvrements dans les tests :
Pour les tests 4 et 5, "(r�sultats partiels)" signifie qu'une partie seulement des r�sultats produits est prise en compte.
./xbench -timegoal 3 >
results/name_of_your_linux_box.out.
Pour g�n�rer l'indice xStones, il nous faudra encore lancer un script
awk; la fa�on la plus simple de le faire �tant de taper
make summary.ms. Jetez un coup d'oeuil au fichier summary.ms : l'indice
xStone de votre syst�me est dans la derni�re colonne de la ligne
contenant le nom de votre machine -- nom que vous aurez sp�cifi�
pendant le test.
./Run -1
(tournez chacun des tests une fois). Vous trouverez les r�sultats dans le
fichier ./results/report.
Calculez la moyenne g�om�trique des indices de EXECL THROUGHPUT,
FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS
CREATION, SHELL SCRIPTS et SYSTEM CALL OVERHEAD.(ndt : la moyenne g�om�trique se d�finit comme la racine n-i�me du produit des n termes consid�r�s)
La suite de benchmarks id�ale tournerait en quelques minutes, comprendrait des benchmarks synth�tiques testant chaque sous-syst�me s�par�ment et des benchmarks applicatifs fournissant des r�sultats pour diff�rentes applications. Elle produirait aussi automatiquement un rapport complet et �ventuellement l'enverrait par e-mail � une base de donn�es centrale sur le Web.
La portabilit� 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 d�clinaisons possibles (i386, Alpha, Sparc...).
Si quelqu'un a la moindre id�e concernant l'�valuation de performances r�seau au moyen d'un test � la fois simple, facile d'emploi, fiable, et dont la mise en oeuvre prendrait moins de 30 minutes (configuration et ex�cution), s'il vous plait contactez-moi.
Au-del� des tests, la proc�dure d'�valuation de performances n'aurait pas �t� compl�te sans un formulaire d�crivant la configuration mat�rielle utilis�e lors de leur ex�cution. Le voici donc : (il se conforme aux directives prescrites dans la FAQ de comp.benchmarks) :
(ndt : le formulaire en question n'a d�lib�r�ment pas �t� traduit, de fa�on � ce que l'auteur de ce HOWTO puisse automatiser leur traitement en vue de maintenir une base de donn�es de r�sultats. 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 pr�sent dans ce formulaire que pour de possibles
interpr�tations des r�sultats, et tant que tel, il est optionnel.
Il pourrait cependant constituer la partie la plus importante de votre
compte-rendu, tout particuli�rement si vous faites de l'�valuation
de performances comparative.
______________________________________________________________________
Le test des performances r�seau est un v�ritable d�fi en soi puisqu'il implique au moins deux machines: un serveur et une machine cliente. Pour cette raison ce genre de test n�cessite deux fois plus de temps pour �tre mis en place, il y a plus de variables � contr�ler, etc... Sur un r�seau Ethernet, il me semble votre meilleure option est le paquetage ttcp. (� developper)
Les tests SMP sont un autre d�fi, et tout test con�u sp�cifiquement pour un environnement SMP aura des difficult�s � s'av�rer valide dans des conditions d'utilisation r�elles parce que les algorithmes qui tirent parti du SMP sont difficiles � d�velopper. Il semble que les versions du noyau Linux les plus r�centes (> 2.1.30 ou pas loin) feront du scheduling (ndt : ordonnancement de thread ou de processus) � grain fin ; je n'ai pas plus d'information que �a pour le moment.
Selon David Niemi, "... shell8 de la suite Unixbench 4.01 fait du bon travail en mati�re de comparaison de mat�riel/SE similaires en mode SMP et en mode UP."
(ndt : SMP = Symetric Multi-Processing, UP = Uni-Processor)
Le LBT a �t� lanc� sur ma machine perso., une machine de classe Pentium tournant Linux que j'ai assembl�e moi-m�me et que j'utilise pour �crire ce HOWTO. Voici le compte-rendu LBT pour ce syst�me :
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 tr�s faible. Les tests ci-dessus ont �t� ex�cut�s
avec quelques unes des options sp�cifiques du Cyrix/IBM 6x86 activ�es
gr�ce 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 l� d'une configuration tr�s stable et dot�e de performances
homog�nes, id�ale pour une utilisation individuelle et/ou d�velopper
sous Linux. Je rendrai compte des r�sultats obtenus avec un 6x86MX d�s
que j'aurai r�ussi � mettre la main sur l'un d'entre eux !
Apr�s avoir compil� ce HOWTO, j'ai commenc� � comprendre pourquoi les mots de "pi�ge" et de "mise en garde" sont si souvent associ�s � l'�valuation de performances.
Ou devrais-je dire des Apples et des PCs ? (ndt : pour go�ter pleinement toute la finesse de ce jeu de mots, il faut quand m�me savoir que pomme se dit apple en anglais :-) C'est tellement �vident et c'est une controverse tellement �cul�e que je ne rentrerai pas dans les d�tails. Je doute que le temps n�cessaire pour booter un Mac compar� � celui d'un Pentium moyen soit une v�ritable mesure de quoi que ce soit. De fa�on similaire on pourrait parler du boot de Linux vs. Windows NT, etc... Essayez autant que possible de comparer des machines identiques � une seule diff�rence pr�s.
Un seul exemple suffira � l'illustration de cette erreur tr�s courante. On lit souvent dans comp.os.linux.hardware l'affirmation suivante : "Je viens tout juste d'enficher le processeur XYZ qui tourne � nnn MHz et la compilation du noyau prend maintenant i minutes (ajustez XYZ, nnn et i selon vos besoins). C'est �nervant parce qu'aucune autre information n'est fournie: on ne connait m�me pas la quantit� de RAM, la taille du swap, les autres t�ches qui tournaient � ce moment l�, la version du noyau, les modules s�lectionn�s, 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.
Un fabriquant de micro-processeurs bien connu a publi� nagu�re des r�sultats de benchmarks produits avec une version sp�ciale et personnalis�e de gcc. Consid�rations �thiques mises � part, ces r�sultats sont d�nu�s de toute signification, en effet, la totalit� de la communaut� Linux aurait utilis� la version standard de gcc. Le m�me genre de consid�ration vaut aussi pour le mat�riel propri�taire. L'�valuation de performances est beaucoup plus utile quand elle va de pair avec du mat�riel sur �tag�re et du logiciel gratuit (au sens GNU/GPL).
On parle de Linux, non ? On devrait donc faire abstraction des benchmarks produits sous d'autres syst�mes d'exploitation (ceci est une instance particuli�re de la comparaison des pommes et des oranges mentionn�e plus haut). Si l'on se propose d'�valuer 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 proc�dez � une �valuation de performances, etc...
Existe-t-il un indice de performances sp�cifique aux machines Linux ?
Non, Dieu merci personne n'a encore invent� de mesure du type Lhinuxstone (tm). M�me si c'�tait le cas, �a n'aurait pas beaucoup de sens : les machines Linux sont utilis�es pour des t�ches tellement diff�rentes allant des serveurs Web lourdement charg�s aux stations graphiques pour utilisation individelle. Aucun facteur de m�rite ne peut d�crire les performances d'une machine Linux dans des situations si diff�rentes.
Alors, pourquoi ne pas choisir une douzaine de m�triques pour r�sumer la performance de diverses machines Linux ?
�a serait une situation id�ale. J'aimerai voir �a devenir une r�alit�. Y-a-t-il des volontaires pour un projet d'�valuation de performances sous Linux ? Avec un site Web et une base de donn�es de rapports bien con�us, compl�te et en ligne ?
... BogoMips ...
Les BogoMips n'ont strictement rien � voir avec la performance de votre machine. Voir le BogoMips Mini-HOWTO.
Quel est le "meilleur" benchmark pour Linux ?
�a d�pend compl�tement de quel aspect des performances d'une machine Linux on souhaite mesurer. Il y a des benchmarks diff�rents pour faire des mesures r�seau (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-r�el, 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.
Quel est le processeur le plus rapide pour Linux ?
Le plus rapide pourquoi faire ? Si on est plut�t orient� calcul intensif, alors un Alpha � fr�quence d'horloge �lev�e (600 MHz et �a continue � grimper) devrait �tre plus rapide que n'importe quoi d'autre, du fait que les Alphas ont �t� con�us dans cette optique. D'un autre c�t�, si vous voulez vous constituer un serveur de news tr�s rapide, il est probable que le choix d'un sous-syst�me disque rapide et de beaucoup de RAM vous menera � de meilleures am�liorations de performances qu'un changement de processeur (� prix constant).
Laissez-moi reformuler la derni�re question, alors : y-a-t-il un processeur qui soit le plus rapide dans les applications d'usage g�n�ral ?
C'est une question d�licate mais la r�ponse est simple : NON. On peut toujours concevoir un syst�me plus rapide m�me pour des applications d'usage g�n�ral ind�pendamment du processeur. D'ordinaire, en conservant tous les autres param�tres � leur valeur nominale, des fr�quences d'horloge plus �lev�es permettent d'obtenir de meilleures performances (ndt : surtout si on parle de syst�mes synchrones :-) et aussi plus de maux de t�te. Si vous retirez un vieux Pentium � 100 MHz d'une carte-m�re (laquelle n'est pas souvent) upgradable, et que vous le remplaciez par un Pentium 200 MHz MMX vous devriez sentir une diff�rence de performances notable. Bien s�r, pourquoi se contenter de 16 MB de RAM ? Le m�me investissement aurait �t� fait de fa�on encore plus avis�e au profit de quelques SIMMs suppl�mentaires...
Donc la fr�quence d'horloge du processeur a une influence sur la performance d'un syst�me ?
La plupart des t�ches sauf les boucles de NOP (qui sont d'ailleurs supprim�es � la compilation par les compilateurs modernes) une augmentation de la fr�quence d'horloge permettra d'obtenir une augmentation lin�aire de la performance. Des applications gourmandes en ressources CPU et tr�s petites (pouvant donc tenir dans le cache L1 : 8 ou 16KB) verront leur performances augmenter dans la m�me proportion que l'augmentation de la fr�quence 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 d�pendent de composants externes (ndt : pour les E/S) b�n�ficieront d'un gain de performance beaucoup moins important. Tout ceci parce que le cache L1 fonctionne � la m�me fr�quence d'horloge que le processeur, alors que la plupart des caches L2 et des autres sous-syst�mes (DRAM par exemple) tournent en asynchrone � des fr�quences plus basses.
D'accord, dans ce cas, une derni�re question sur le sujet : quel est le processeur pr�sentant le meilleur rapport prix/performance pour une utilisation d'usage g�n�ral sous Linux ?
D�finir une "utilisation d'usage g�n�ral sous Linux" n'est pas chose facile ! Etant donn�e une application quelconque, il y a toujours moyen de d�terminer quel processeur du moment d�tient le meilleur rapport prix/performance pour ladite application. Mais les choses changent si rapidement � mesure que les fabriquants diffusent de nouveaux processeurs, que dire "le processeur XYZ � n MHz est le choix du moment" serait forc�ment r�ducteur. Cependant, le prix du processeur n'est pas significatif dans le co�t d'un syst�me complet que l'on assemble soi-m�me. Donc, la question devrait plut�t �tre "comment maximize-t-on le rapport performance/co�t d'une machine donn�e ?" Et la r�ponse � cette question d�pend en grande partie des besoins en performance minimale garantie et/ou du co�t maximal de la configuration que l'on consid�re. Il arrive parfois que le mat�riel sur �tag�re ne permette pas d'atteindre les besoins en performance minimale garantie que l'on souhaite obtenir et que des syst�mes RISC co�teux soient la seule alternative viable. Pour une utilisation personnelle, je recommende une configuration �quilibr�e et homog�ne du point de vue de la performance globale (et maintenant d�brouillez vous pour deviner ce que j'entends par �quilibr� et homog�ne :-); le choix d'un processeur est une d�cision importante, mais pas plus que celle du disque dur et de sa capacit�, celle de la quantit� de RAM, celle de la carte graphique, etc...
Qu'est-ce qu'une am�lioration significative des performances ?
Je dirais que tout ce qui est sous 1% n'est pas significatif (pourrait �tre d�crit comme marginal). Nous autres, simples mortels, avons du mal � percevoir la diff�rence entre 2 syst�mes dont les temps de r�ponses sont distants de moins de 5% . Bien s�r, certains �valuateurs de performances - plut�t de la tendance int�griste - ne sont aucunement humains et vous raconteront, en comparant 2 syst�mes dont les indices de performances sont de 65.9 et de 66.5, que ce dernier est indubitablement plus rapide.
Comment puis-je obtenir une am�lioration significative de performance � moindre co�t ?
Puisque le code source complet de Linux est disponible, un examen attentif et une re-conception algorithmique de proc�dures cl�s peuvent, dans certains cas, d�boucher sur des am�liorations jusqu'� un facteur 10 en terme de performance. Si l'on est sur un projet commercial et qu'on ne souhaite pas plonger dans les tr�fonds du code source du syst�me, l'implication d'un consultant Linux est n�c�ssaire. Cf. le Consultants-HOWTO.
La premi�re �tape a consist� en la lecture de la section 4 "Writing and submitting a HOWTO" de l'index des HOWTOs �crit par Greg Hankins.
Je ne savais absolument rien au sujet de SGML ou de LaTeX mais, apr�s avoir lu divers commentaires � propos de SGML-Tools, j'�tais tent� d'utiliser un paquetage de g�n�ration de documentation automatique. Cependant l'insertion manuelle de directives de formattage me rappelait l'�poque o� j'assemblais � la main un moniteur 512 octets pour un processeur 8 bits aujourd'hui disparu. J'ai donc fini par r�cup�rer les sources de LyX, les compiler et je m'en suis servi dans son mode LinuxDoc. Une association chaudement recommend�e : LyX et SGML-Tools.
Le Linux Benchmarking HOWTO est plac� sous le r�gime du copyright (C) 1997 par Andr� D. Balsa. Les HOWTO Linux peuvent �tre reproduits en totalit� ou en partie et distribu�s en totalit� ou partiellement sur n'importe quel support physique ou �lectronique, � condition que ce message de copyright soit conserv� dans toutes les copies. La redistribution commerciale est permise et encourag�e; cependant l'auteur aimerait �tre pr�venu de l'existence de telles distributions.
Toute traduction (ndt : dont acte :-), tout travail d�riv� ou p�riph�rique incorporant un HOWTO Linux doit �tre couvert par ce message de copyright.
C'est-�-dire qu'il ne vous est pas possible de produire un travail d�riv� � partir d'un HOWTO et d'imposer des restrictions suppl�mentaires sur sa distribution. Des exceptions � cette r�gle pourront �tre accord�es sous certaines conditions; veuillez contacter le coordinateur des HOWTO Linux � l'adresse sp�cifi�e ci-apr�s.
Pour �tre bref, nous souhaitons promouvoir la diss�mination de cette information par autant de canaux que possible. Cependant, nous souhaitons garder un droit de copyright sur les HOWTOs et aimerions �tre averti de tout projet de redistribution les concernant.
Si vous avez des questions, veuillez contacter Greg Hankins, le coordinateur des HOWTOs Linux, � gregh@sunsite.unc.edu par e-mail ou au +1 404 853 9989 par t�l�phone.
(ndt : pour cette version fran�aise du document original, il semble plus appropri� de contacter Eric Dumas, coordinateur des traductions de HOWTOs dans la langue de Moli�re par e-mail � l'adresse dumas@freenix.EU.org).
De nouvelles version du Benchmarking-HOWTO Linux seront mises � 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 r�pertoire other-formats. Le Benchmarking-HOWTO Linux est �galement disponible pour des clients WWW comme Grail, un butineur Web �crit en Python. Il sera aussi post� r�guli�rement sur comp.os.linux.answers.
Les suggestions, corrections, et ajouts sont d�sir�s. Les contributeurs sont les bienvenus et en seront remerci�s. Les incendies (ndt : est-ce une traduction acceptable de flame ?) sont � rediriger sur /dev/null.
Je serai toujours joignable � andrewbalsa@usa.net.
David Niemi, l'auteur de la suite Unixbench, s'est aver� �tre une source in�puisable d'informations et de critiques (fond�es).
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 communaut� Linux. Ce HOWTO est ma fa�on de renvoyer l'ascenseur.
Votre kilom�trage peut varier et variera sans doutes. Soyez conscients que l'�valuation de performances est un sujet tr�s sensible et une activit� qui consomme �norm�ment de temps et d'�nergie.
Pentium et Windows NT sont des marques d�pos�es d'Intel et de Microsoft Corporations respectivement.
BYTE et BYTEmark sont des marques d�pos�es de McGraw-Hill, Inc.
Cyrix et 6x86 sont des marques d�pos�es de Cyrix Corporation.
Linux n'est pas une marque d�pos�e, et esp�rons qu'elle ne le sera jamais.