Je sais, l'habit ne fait pas le moine mais quand même... Tout doit être dans la diode bleu.
La gamme Athlon FX correspond au super haut de gamme d'AMD qui sert de démonstrateur téchnologique. C'est un processeur compatible AMD64, rebatisé x86_64 depuis, et que Intel a décidé d'appeler EMT64 en oubliant complétement AMD. Tous ses termes définissent la même architecture 64 bits.
Je sais, l'habit ne fait pas le moine mais quand même... Tout doit être dans la diode bleu.
Dés la sortie d'un nouveau materiel, beaucoup de site web se rue pour le tester. On peut lire ainsi un grand nombre de testes sur les derniers processeurs, comparer les bas de gammes ayant le meilleur rapport qualité-prix, comparer les portables pour se faire une idée de leur performance réel qui non souvent plus rien avoir avec la fréquence affichée (pentium-M et pentium 4 mobile, par exemple, le pentium M étant comparable à un P4 mobile ayant 1 Ghz de fréquence de plus). Mais tout cela se fait sous Windows !
Il existe des dizaines de tests disponnibles sur internet ou dans la presse. Très peu se focalise sur l'utilisation de Linux. En testant sous un OS donné, on teste le processeur, mais aussi le compilateur, voire l'OS dans une moindre mesure. L'idée est donc d'avoir une idée des performances d'un processeur dans l'utilisation de Linux. Je me suis restreind à son utilisation en tant que station de travail et non de serveur.
Ecrire un suite de teste n'est pas une chose facile. Le problème est de savoir exactement ce que l'on teste et ce que l'on voudrait tester. Ici, je cherche à estimer les performances de cpu dans un envirronement typique Linux utilisant donc les outils libres fournis dans toutes vos bonnes distributions.
Pour réaliser cela, il est possible de fonctionner par comparaison, toute chose étant égal par ailleurs. Lors d'une comparaison, les cpus sont testés avec la carte mère la plus rapide, les mêmes disques dure, les mêmes cartes graphiques. On peut en déduire que les différences de performances observées proviennent du cpu. C'est ce qui est fait, la plus part du temps, lors d'une comparaison Intel/AMD.
Linux propose un autre challenge : il tourne sur des architectures très différentes : x86, AMD64, ppc, sparc, zSeries, arm, ... Il est donc tentant de créer des tests utilisables partout. Mais il n'est pas possible de tester 2 cpus d'architectures différentes dans un environnement strictement identiques.
Il faut savoir précisement ce que fais le programme de teste pour tirer des conclusions. En effet, si on veut tester un processeur et non la machine dans son ensemble, il ne serait pas normal d'utiliser un test qui passe beaucoup de temps en d'entrée-sortie. Si d'un coté, on a disposition une baie de disque RAID fiber channel et de l'autre un disque IDE, il sera difficile de conclure de l'influence du cpu.
Un moyen de se passer de disque est d'utiliser tmpfs qui utilise de la mémoire vive, Linux gère donc les entrées sortie uniquement vers de la RAM. Cela permet de se passer complètement du problème posé par les disques, moyennant une modération concernant la taille des données ou l'augmentation de la RAM. Je me suis fixé 1 Go de fichier temporaire maximum.
En fait, lors des tests, je me suis rendu comptes qu'utiliser tmpfs ne changeais pas ou très peu les résultats par rapport à l'utilisation direct du disque dure (notament lors de compilation avec gcc). En effet, avant chaque test, je copie les élement de travail dans le répertoire temporaire. Or si il y a suffisament de mémoire vive libre, Linux l'utilise comme buffer, ce qui revient au même que le tmpfs. Cela n'est valable que si la machine dispose d'assez de mémoire vive.
La plus part des benchs diffusés et utilisés sont sous windows et utilise des programmes synthétiques (*mark,...). Ces testes sont censés reproduire l'utilisation moyenne "d'applications". Ces testes sont de plus en plus difficile à écrire car les cpu ne sont plus "homogènes".
Ils se basent sur l'utilisation statistique d'instructions dans les applications. Or ses statistiques varient grandement selon l'application observée. De plus, les manières d'accèder à la mémoire influe maintenant également sur les performances. Il est loin le temps ou les testes comme "Drystone" était représentatif de quoi que se soit.
Un bench applicatif utilise une application particulière et en mesure les performances comme par exemple la suite spec (www.spec.org). Spec est seulement disponible sous NDA et demande plusieurs dizaines d'heures de calculs.
Un test synthètique peut difficilement être représentatif en même temps d'un compresseur audio et d'un traitement de texte. Il "suffirait" donc de créer 2 testes, l'un reproduisant le comportement d'un compresseur, et l'autre celui d'un traitement de texte. Ou bien, encore plus simple : il suffit de mesurer les performances de 2 applications du domaine.
Certe, il y a le risque que l'on utilise un programme qui est écris d'une manière très particulière et ne donne pas les mêmes résultats que les autres programmes de la même catégorie.
Quand on choisit un processeur, typiquement, on veut savoir lequel est le plus puissant ou lequel à le meilleur rapport qualité/prix, le plus rapide pour les applications que l'on utilise maintenant. A quoi sert un processeur qui pourrait être le plus puissant si les applications étaient réécrites pour lui ?
Cela pose également la question : si je choisis une application dois-je la recompiler en essayant différent switch de compilation ou dois-je utiliser le paquet d'une distribution ? En effet, très peu d'utilisateurs iront recompiler pour optimiser leurs applications (sisi, gentoo est une exception).
Il est peut être interrescant de faire la comparaison. Mais la plus part des essais montrent que la différence de performance ne dépasse pas quelques pourcents.
L'autre point délicat concerne l'utilisation ou non d'instructions que ne peuvent (encore) utiliser les compilateurs. Il s'agit souvent d'instruction SIMD (single instruction multiple data) tel que le MMX et le SSE pour le x86 et l'x86_64, l'Altivec pour le PPC.
La plus part de ses instructions ont été rajouté à des jeux d'instruction existant. On a donné des noms à se groupe de nouvelles instructions. Dans la têtes des gens, ils devrait donc former un élement à part. Pourtant ce ne sont que des instructions en plus.
La plus part des codeurs mpeg4 utilisent les instructions SSE dans leur code. Est-ce équitable de tester une application optimisée SSE sur x86, qui ne l'est pas sous PPC mais qui pourrait l'être ?
J'en reviens à mon but initial : avoir la machine la plus rapide pour mes applications. Donc, oui, je considère cela équitable. Ses instructions font partis du cpu et l'on teste donc bien ses performances dans les applications qui nous interressent.
Evidement, on peut fournir une explication sur certain résultat de benchmark. Le lecteur pourra de lui-même se faire une idée si un programme a des "chances" d'utiliser un jour, les instructions spécials d'un certain CPU. Par exemple, il y a beaucoup de chance que l'équipe d'XviD porte à terme leur code sous assembleur x86_64 mais très peu qu'ils le portent sous VIS l'extention SIMD des processeurs Sparc de SUN.
Il est assez difficile de choisir les applications qui peuvent servir de benchs. Quelques essaient montre qu'une tache qui dure quelques secondes en moyenne, peut avoir des écarts de l'ordre de 30% entre 2 executions ! Il est ardu de conclure quoi que se soit dans ce cas. Cela fait entrevoir de belle optimisation future dans l'utilisation interactive de Linux.
Malheureusement, la seconde est la durée de beaucoup de tâches courantes. C'est ce qui fait que l'on finit par changer de machine lassé de ces nombreuses petites attentes.
J'ai finalement choisis de tester des programmes qui prennent "naturellement" du temps. Pour éviter de trop longues attentes, j'ai utilisé une durée moyenne de 1 minute (pour une durée total de bench d'une grosse heure). Dans ce cas, les variations entre 2 executions sont plus faible. Encore faut-il trouver des applications de "tous les jours" qui nécessite 1 minutes de cpu sans que cela soit trop artificielle.
La compilation est une des tâche qui prends beaucoup de temps. Mais c'est finalement une tache très particulière et qui n'interresse que peu les utilisateurs lambda.
Le multimedia est un gros consommateur de puissance cpu : la compression audio et video. La retouche d'image peut nécessiter également de la puissance. Une compression de fichier peut aussi être longue.
Les jeux sont souvent utilisés pour tester la puissance d'une machine mais la cartes graphiques est beaucoup trop prépondérante dans le résultat final pour en déduire quelques choses sur le cpu. Et puis, le jeu n'est pas encore une activité courante sous Linux. De plus, Frozzen Bubble n'a pas besoin d'un Athlon FX-53 à 2,4 Ghzh avec 1 Go de RAM ECC... et j'espère n'en aura jamais besoin.
Beaucoup d'opérations "longues" sont souvent le fait d'accès disques comme par exemple le démarrage d'une application comme OpenOffice.org qui va chercher un grand nombre de fichier, un peu partout sur le disque. Un tel test ne permet pas de tester le cpu.
Un des testes le plus utilisé est la compilation du kernel Linux. Il suffit de prendre une version particulière de celui-ci et une version donnée de gcc, utiliser les options par default et le tour est joué.
Enfin presque. Le noyau compilé le sera pour la machin du teste. Or il existe différentes architectures. Une partie du code de linux y est spécifique pour chacun d'eux. Le code compilé n'est pas identique d'une machine à l'autre.
Il est difficile de savoir si cette différence est notable ou pas et fait varier le temps de compilation car le travail demandé à gcc est différent. Mais cette différence doit être faible. Mais quitte à compiler du code autant compiler gcc lui-même.
Gcc est un programme très complexe dans sa gestion de la mémoire et dans le type d'opérations entières qu'il fait. Il est considéré assez représentatif des programmes en nombre entier "lourd".
Comme dans ce test, j'utilise le programme et le code de gcc , je peux même me permètre de maitriser la version du compilateur qui sert à compiler, et la version du compilateur qui a servi à compiler le compilateur : pour que "les choses soient (au maximum) égal par ailleurs". Facile, non ? (mais si...)
Pour pouvoir maitriser la version de gcc, il faut le recompiler. Et cette compilation doit se faire 3 fois (vous comprennez pourquoi mon P3 a souffert...).
En effet, je dispose des sources de gcc V3.4 et la V3.2. est installé sur le système. En compilant la v3.4 avec la v3.2, j'ai l'influence de la v3.2 dans le performance du binaire v3.4 ainsi généré (optimisation différerente, ...). En recompilant la v3.4 avec le binaire v3.4 juste généré précédement, j'obtient un compilo v3.4 avc un binaire optimisé v3.4.
Le nouveau binaire V3.4 généra au bit près la même sortie que le binaire précédent compilé v3.2 mais le code machine et les performances ne sont pas les même. C'est la recompilation suivante qui sera chronometré.
Gcc est composé d'un front-end qui est spécifique à chaque langage, et d'un back end spécifique à chaque cpu. Ceux-ci sont assez différent selon le cpu. Mais on peut considérer comparrable la complexité des back-end de processeurs CISC qui contiennent plein de passes de reconnaissance de pattern pour réduire le nombre d'instructions utilisés. D'un autre coté, les processeurs RISC sont plus simples et donc comparable entre eux en terme de compléxité.
Il faudrait refaire un test, en désactivant les optimisations (option -O0 de gcc). Le travail demandé par le bench serait plus facilement comparable entre architectures différentes mais serait moins représentatif d'une utilisation habituelle. De plus, il faut bien arréter un jour de développer la suite de tests pour écrire l'article...
Je suis tombé sur un programme de calcul de Pi dont la particularité est de pouvoir être compilé en 32 ou en 64 bits. Il permet de montrer l'avantage du 64 bits dans certains calculs. Celui-ci fait un calcul entier en précision arbitraire. Pour cela, les calculs sont fait par la machine comme si on les faisait la main sur un cahier. Si un homme décompose une opération en opération à un chiffre, la machine décompose l'opération avec la taille de ses registres. Dans ce type de calculs, avoir un registre 2 fois plus large est très avantageux. En effet, pour une même (grande) précision, le nombre d'opération est divisé par 2.
C'est un programme qui prends peu de place mémoire et reste dans le cache de premier niveau. C'est un test synthétique de la puissance de calcul brute en nombre entier de calcul de la machine.
Pour tester les capacités de calcul en nombre flottant, j'ai choisis d'utiliser les ogg tools (oggenc, oggdec). Le compresseur audio utilise beaucoup la fpu.
Image magic est de plus en plus utilisé dans les générateurs de site web pour montrer ses photos. Il permet de génèrer les photos en différente taille (bins, par exemple). C'est d'ailleurs assez long.
Le but est de calculer le temps mis pour réduire la taille d'un répertoire remplit d'image de grande taille tytique issue d'un appareil de photo numérique 4 méga pixel.
En utilisation "normal", les entrées-sorties sont très sollicités pour lire et écrire les images. Ici, les IOs vont être remplacé par l'utilisation de la RAM par l'utilisation de tmpfs. En effet, il y a "création" d'une image qui ne peut donc pas être dans un quelconque cache.
FFMPEG est le codec utilisé par défault par beaucoup de compresseur video disponnible sous Linux.
J'ai aussi voulu tester XviD qui est également populaire sous d'autres OS et qui est plus ou moins la référence en terme de qualité d'image. J'ai fais un encodage à 2 pass avec un son mp3 produit par Lame (l'avi supportant très mal le ogg).
Je me suis aussi interressé au teste du comportement de la machine avec une charge supérieur à 1 (ce qui veut dire que plus de 1 programmes est près et utilisent le cpu en même temps). Pour cela, il suffit de lancer plusieurs taches en parrallèle. Cela permet de pouvoir comparer des systèmes n'ayant pas le même nombre de cpu. Les performances dépendandent plus de la manière qu'à l'OS de gérer cette charge, des structures des caches , de la bandes passantes mémoires par cpu et surtout du nombre de cpu. Cela permet ainsi d'évaluer les processeurs SMT (simultaneous-multi-threading) comme l'hyperthreading des derniers P4.
Le SMT consiste en la duplication les registres pour avoir les "entrées" de 2 cpus mais en mutualisant derrière l'acces aux unités de calculs et aux caches. Cela permet d'augmenter le taux d'utilisation des unités en question en augmentant très peu le nombre de portes logiques.
Peu d'applications sont multithreadés aujourd'hui. L'utilisation de l'option "-j" de make permet de tester réellement l'accélération de la compilation d'une tache de compilation. Pour les autres testes, il s'agit simplement de la même tâche lancer n fois. Chaque teste a été lancer avec 1, 4 et 8 taches en même temps.
AMD64 est une extention 64 bits du jeu d'instruction 32 bits x86 qui est utilisé dans les pc. L'Opteron est la version "pro" pour serveur de chez AMD (sur socket 940). L'Athlon 64 est une version de l'Opteron avec un bus mémoire 2 fois plus petit à l'origine (socket 754), de nouvelles version avec la même bande passante vienne de sortir (socket 939). L'Athlon FX est à l'origine un Opteron repackagé pour l'utilisation desktop. Comme le grand publique est moins exigeant en terme de fiabilité que les professionnels, l'Athlon FX est disponnible dans des fréquences plus élevés que l'Opteron.
L'origine professionnel de l'Athlon FX-53 rend obligatoire l'utilisation de mémoire ECC.
L'architecture x86_64 double le nombre de registre disponnible. C'est plus cette extention qui fera gagner des performances, que l'extension des registres à 64 bits. En effet, les entiers 64 bits vont prendre 2 fois plus de place en mémoire souvent pour rien.
Le 64 bits permet de franchir la barrière des 4 Go de RAM par processus sans problème (la carte mére de test accépte jusqu'à 8Go). Certains systèmes Xeon d'Intel pouvaientt atteindre 64 Go mais toujours avec cette limite de 4 Go adressable par processus. Dans certaines applications qui utilisent les registres comme des champs de bits, les registres 64 bits peuvent traiter 2 fois plus de données à la fois et donc permètent d'aller en théorie 2 fois plus vite si le code est prévus pour (certains jeux d'echec, cryptographie, calcul en grande précision...).
La machine de test est un Athlon FX 53 tournant à 2,4 Ghz avec 1 Go ECC de ram. La carte graphique est une NVIDIA Geoforce 5950.(Il est assez marrant de tester GLXGEARS : 7800 fps ! Ouais, je sais, j'ai la plus grosse ... configuration !). La carte mère est une SK8N d'Asus.
Donc le FX-53 est sous le radiateur qui est derrière le ventilateur, ...sisi je vous assures.
Pour le test, j'ai utilisé la version AMD64 (renommé x86_64 depuis pour la 10.1) de la mandrake 10.0. Elle marche sans problème même si tous les paquets ne sont pas encore disponibles. Il est possible de mixer les bibliothèques et les executables 32 bits et ceux 64 bits.
Avoir les résultats de l'Athlon FX 53 en mode 32 et 64 bits est interrescant en soit. Mais il est encore plus intressant de le comparer avec un maximum de machines.
J'ai pu le comparer avec ma machine de travail qui est un bi-Athlon 1800+ avec 768 Mo de ram qui est loin d'être ridicule dans tous les testes. Je l'ai aussi comparé avec mon portable PIII 500 Mhz, avec 196 Mo de RAM, qui est ridicule, dans quasiement tous les tests, quand il n'est pas à genoux avant de finir.
J'ai pu avoir acces à un Athlon 64 3000+ sur socket 754 d'un amis. Ce cpu fait partie de la série Athlon 64 "abordable", par contre il dispose de la moitier de la bande passante mémoire du FX (64 contre 128 bits).
J'ai pu aussi avoir quelques résultats de machines dont je n'avais pas l'acces root donc il n'a été possible que de tester les programmes installés par default : un mono XEON 3.06 GHz qui apparait équipé de 2 cpus grâce à l'hyperthreading (2 cpus virtuels visibles donc), un bi-XEON 3.2 Ghz qui apparait dans les graphiques avec 4 cpus (virtuels). J'ai égalment eu accès à un portable powerbook G4 à 500 Mhz.
Ces résultats m'interrescaient particuliérement pour enfin connaitre le rapport de puissance entre un x86 et un PowerPC. Pour se faire une idée plus précise d'une machine rescente, j'ai divisé les temps par 2 pour estimer ce que donnerait un G4 à 1 Ghz. (d'ou le terme Virtuel_G4). Globalement, les chiffres fournis devraient plutôt être plus élevé qu'un vrai G4 à 1 Ghz car la fréquence cpu a augmenté plus vite que celle de la mémoire.
Le plus beau étant pour la fin, j'ai pu avoir quelques résultats d'un octo Itanium 2 à 900 Mhz (oui, octo comme huit processeurs).
L'Itanium est un processeur VLIW qui ne fait pas de parrallelisation dynamique, tout est fait en statique par le compilateur. Le compilateur d'Intel a nécessité de grosse recherche pour tirer toutes les performances de ce processeur. Les applications testés ont été compilé avec gcc qui est moins avancé que Icc dans la compilation VLIW (si on veut rester polie). De plus, je tiens à rester dans l'optique de tester une architecture sous Linux avec les outils habituels libres.
Si je fais ce préambule, c'est que l'Itanium n'est pas fait pour Linux, à moins que cela soit l'inverse, Intel ne cherchant pas à améliorer gcc dans ce domaine. Les quelques résultats sont plus là pour le fun.
Chaque graphiques présentes en abcisse le nombre de tache en parrallèle. La valeur, la plus importante, a retenir est la première lorsque le cpu ne fait qu'une tâche à la fois.
L'ordonné est une normalisation au temps user du cpu le plus rapide. Par exemple, un cpu A mets 30 seconde à finir un test, un cpu B 40 s. Le cpu A aura un indice 100, le cpu B aura 75 (=100*30/40). Le cpu B est donc 25 % plus lent que le A.
Le bench Compact fait une série de compression bzip2 et gzip. Le FX-53 est 10 % plus rapide en mode 64 bits et enfume le reste... Le 3000+ n'est pas trop loin derrière. On remarque que le G4 à 1 ghz ferait jeu égal avec l'Athlon 1800+ à 1533Mhz.
Sur le test md5sum, on peut remarquer que la version 64 bits est un poil plus lente. Cela peut s'expliquer par la plus grande consomation mémoire d'entier 64 bits. La perte est faible : quelques pourcents.
Player est un test qui utilise mplayer en mode benchmark. Dans ce mode, le nombre d'image par seconde n'est pas respecté ce qui permet de mesurer la vitesse de décodage. La décompression ne demande pas une grosse puissance pour un PC d'aujourd'hui mais ce n'est pas le cas pour un PDA. Ici, la décompression ne semble pas fait en assembleur pour la version x86_64, d'ou la différence de performance avec le mode 32 bits.
XviD (bench Film) n'était pas encore porté sous mandrake AMD64 quand j'ai fait le teste d'où la création du teste suivant. Les performances du 3000+ en x86_64 ne laisse présager de rien de bon (cette machine était sous cooker). Le code n'est pas encore optimisé en assembleur d'où la différence de performance avec la version 32 bits.
FFMPEG (libavcodec) est hautement optimisé en assembleur. Et il ne l'est pas encore complètement en X86_64. Il semble ici que la version de la lib testé sur le 3000+ ne devait pas être la même et devait utiliser la version purement C à moins que la différence de performance soit dû à la bande passante réduite. On remarque la très bonne performance du G4 grace à son jeu d'instructions SIMD Altivec.
Dans Image (utilisation de convert de Image Magick), la version 64 bits atteind presque 20% de vitesse en plus !
Le test Music (ogg tools) est assez important car c'est le seul teste qui teste la puissance de la fpu. L'ogg est réputé pour demander beaucoup de puissance dans ce domaine. La version 64 bits est encore une fois 20 % plus rapide.
Pi est donc un test entier limité uniquement par la puissance du cpu. Ici, on voit que la version 64 bits est deux fois plus rapide que celle 32 bits. C'est dû à l'avantage d'avoir des registres 2 fois plus grand pour faire des calculs en grande précision.
La version 64 bits est comme dans le test avec Gcc, 15 % plus lente. Il est difficile d'imaginer que c'est l'immaturité de la version x86_64 de gcc qui provoque une telle différence. La différence de consomation de bande passante mémoire doit compter ici aussi.
Globalement, les améliorations dans le jeu d'instruction compense largement l'éventuel gachie de bande passante. Si le programme n'est pas codé en assembleur, la version 64 bits est de l'ordre de 20% plus rapide dés maintenant. On peut s'attendre à ce que les applications phares dont le coeur est codé en assembleur seront porté en assembleur x86_64 d'autant plus vite que les cpus compatibles se démocratiseront.
Nicolas Boulay
<nicolas (point) boulay (at) etherale (point) org>