Transcription

1 Ceci est un extrait électronique d'une publication de Diamond Editions : Ce fichier ne peut être distribué que sur le CDROM offert accompagnant le numéro 100 de GNU/Linux Magazine France. La reproduction totale ou partielle des articles publiés dans Linux Magazine France et présents sur ce CDROM est interdite sans accord écrit de la société Diamond Editions. Retrouvez sur le site tous les anciens numéros en vente par correspondance ainsi que les tarifs d'abonnement. Pour vous tenir au courant de l'actualité du magazine, visitez : Ainsi que : et

2 Par :: Nicolas Boulay :: :: Tests de l AMD Athlon FX 53 J ai eu entre les mains un Athlon FX 53. C est sans doute ce qui se fait de plus puissant dans le monde des CPU en attendant la sortie du FX 55. Difficile de résister à l envie de le tester dans tous les sens. La gamme Athlon FX correspond au super haut de gamme d AMD, elle sert de démonstration technologique. C est un processeur compatible AMD64, rebaptisé x86_64 depuis, et que Intel a décidé d appeler EMT64 en oubliant complètement AMD. Tous ces 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 bleue. Dès la sortie d un nouveau matériel, un tas de gens se ruent pour le tester. On peut trouver ainsi sur le Web un grand nombre de rapports de tests 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 leurs performances réelles qui n ont souvent plus rien à voir 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 est fait sous Windows! A propos de benchmark Il existe des dizaines de tests disponibles sur Internet ou dans la presse. Très peu se focalisent 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 délibérément restreint à son utilisation en tant que station de travail et non en tant que serveur. Écrire une suite de tests n est pas 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 CPU dans un environnement typique GNU/Linux utilisant les outils libres fournis dans toutes les bonnes distributions. Pour réaliser cela, il est possible de fonctionner par comparaison, toutes choses étant égales par ailleurs. Lors d une comparaison, les CPU sont testés avec la même carte mère (la plus rapide), les mêmes disques dur, les mêmes cartes graphiques. On peut en déduire que les différences de performance observées proviennent du CPU. C est ce qui est fait, la plupart 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 deux CPU d architecture différente dans un environnement strictement identique. Il faut savoir précisément ce que fait le programme de test pour tirer des conclusions valables. En effet, si l 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 entrée/ sortie. Si d un côté, on dispose d une baie de disque RAID fiber channel et de l autre d un disque IDE, il sera difficile de tirer des conclusions sur l influence du CPU. Un moyen de se passer de disque est d utiliser tmpfs qui emploie la mémoire vive : Linux gère alors les entrées/sorties uniquement vers de la RAM et non vers les disques. Cela permet de se débarrasser 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 fichiers temporaires au maximum. En fait, lors des tests, je me suis rendu compte qu utiliser tmpfs ne changeait pas, ou très peu, les résultats par rapport à l utilisation directe du disque dur (notamment lors de compilations avec gcc). En effet, avant chaque test, je copie les éléments de travail dans le répertoire temporaire. Or, s il y a suffisamment de mémoire vive libre, Linux l utilise comme buffer, ce qui revient au même que le tmpfs. Cela n est valable, bien sûr, qu à condition que la machine dispose de suffisamment de mémoire vive. Benchmark synthétiques ou applicatifs La plupart des benchs diffusés et utilisés sont sous Windows et utilisent des programmes synthétiques (*mark). Ces tests sont censés reproduire l utilisation moyenne «d applications». Ils sont de plus en plus difficile à écrire car les CPU ne sont plus «homogènes». Ces tests Windows se basent sur l utilisation statistique d instructions dans les applications. Or, ces statistiques varient grandement selon l application observée. 30

3 31 De plus, les manières d accéder à la mémoire influent maintenant également sur les performances. Il est loin le temps où les tests comme Drystone étaient représentatifs de quoi que ce soit. Un bench applicatif utilise une application particulière (sic) et en mesure les performances, comme, par exemple, la suite Spec ( Spec est uniquement disponible sous NDA et demande plusieurs dizaines d heures de calcul. Un test synthétique peut difficilement être représentatif de la même manière pour un compresseur audio ou pour un traitement de texte. Il «suffirait» donc de créer deux tests, 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 deux applications du domaine. Certes, il reste le risque d utiliser un programme qui est écrit d une manière très particulière et qui ne donnera pas les mêmes résultats que d autres programmes de sa catégorie. Quand on choisit un processeur, typiquement, on veut savoir lequel est le plus puissant ou lequel présente le meilleur rapport qualité/prix. Bref, le plus rapide pour les applications que l on utilise «maintenant». À 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érentes options de compilation ou dois-je utiliser le paquet d une distribution? En effet, très peu d utilisateurs recompileront pour optimiser leurs applications (si, si, gentoo est une exception). Il est peut-être intéressant de faire la comparaison, mais la plupart des essais montrent que la différence de performances ne dépasse pas quelques pourcents. L autre point délicat concerne l utilisation ou non d instructions que ne peuvent pas (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, ou encore l Altivec pour le PPC. La plupart de ces instructions ont été rajoutées à des jeux d instructions existants. On a donné des noms à ce groupe de nouvelles instructions. Dans la tête des gens, ils devraient donc former un élément à part. Pourtant ce ne sont que des instructions en plus. La plupart des codeurs MPEG4 utilisent les instructions SSE dans leur code. Estce é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. Ces instructions font partie du CPU et l on teste donc bien ses performances dans les applications qui nous intéressent. Évidement, on peut fournir une explication sur certains résultats 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éciales d un certain CPU. Par exemple, il y a beaucoup de chance que l équipe d XviD porte, à terme, son code sous assembleur x86_64. Mais, il y a très peu de chances qu elle le porte sous VIS, l extension SIMD des processeurs Sparc de SUN. Que tester? Il est assez difficile de choisir les applications qui peuvent servir de benchs. Quelques essais montrent qu une tâche qui dure quelques secondes en moyenne peut avoir des écarts de l ordre de 30% entre deux exécutions! Il est ardu de conclure quoi que ce soit dans ce cas. Cela laisse entrevoir de belles optimisations futures dans l utilisation interactive de Linux. Malheureusement, la seconde est l unité de temps pour de nombreuses 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 choisi 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 totale de bench d une grosse heure). Dans ce cas, les variations entre deux exécutions sont plus faibles. Encore faut-il trouver des applications de «tous les jours» qui nécessitent une minute de CPU sans que cela soit trop artificiel. La compilation est une des tâches qui prend beaucoup de temps. Mais c est finalement une tâche très particulière qui intéresse peu l utilisateur lambda. Le multimédia est un gros consommateur de puissance CPU, pour la compression audio et vidéo. La retouche d image peut nécessiter également de la puissance. Enfin, une compression de fichier peut également être longue. Les jeux sont souvent utilisés pour tester la puissance d une machine, mais le rôle de la carte graphique est beaucoup trop prépondérant dans le résultat final pour en déduire quelque chose sur la puissance du 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 GHz 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 disque comme, par exemple, le démarrage d une application comme OpenOffice.org qui va chercher un grand nombre de fichiers, un peu partout sur le disque. Un tel test ne permet pas de tester le CPU. La compilation de kernel Un des tests les plus utilisés est la compilation du kernel Linux. Il suffit de prendre une version particulière de celuici et une version donnée de GCC, utiliser les options par défaut et le tour est joué. Enfin presque Le Kernel compilé le sera uniquement pour la machine du test. Or il existe différentes architectures, pour lesquelles une partie du code de Linux est spécifique. Le code compilé n est ainsi pas identique d une machine à une autre. Il est difficile de savoir si cette différence est notable ou non, et si elle fait varier le temps de compilation. Le travail demandé à GCC est différent. Mais cette différence doit être faible. Quitte à compiler du code, autant compiler GCC lui-même. GCC 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 effectue. Il est considéré comme assez représentatif Tests de l AMD Athlon FX 53

4 des programmes en nombre entier «lourd». Comme dans ce test j utilise le programme et le code de GCC, je peux même me permettre de maîtriser la version du compilateur qui sert à compiler, et la version du compilateur qui a servi à compiler le compilateur (NDLR : Aaaaahhhh). Pour que «les choses soient (au maximum) égales par ailleurs». Facile, non? (mais si ) Pour pouvoir maîtriser la version de GCC, il faut le recompiler. Et cette compilation doit se faire trois fois (vous comprenez pourquoi mon P3 a souffert ). En effet, je dispose des sources de GCC 3.4 et la 3.2. est installée sur le système. En compilant la 3.4 avec la 3.2, j ai une influence de la 3.2 dans les performances du binaire 3.4 ainsi généré (optimisation différente, etc.). En recompilant la 3.4 avec le binaire 3.4 généré précédemment, j obtiens un compilateur 3.4 avec un binaire optimisé 3.4. Le nouveau binaire 3.4 génére, au bit près, la même sortie que le binaire précédent compilé 3.2, mais le code machine et les performances ne sont pas les mêmes. C est la recompilation suivante qui sera chronométrée. GCC est composé d un frontend spécifique à chaque langage, et d un backend spécifique à chaque CPU. Ceux-ci sont assez différents selon le CPU, mais on peut considérer comme comparable la complexité des backends de processeurs CISC. Ils contiennent en effet de nombreuses passes de reconnaissance de pattern pour réduire le nombre d instructions utilisées. D un autre côté, les processeurs RISC sont plus simples et donc comparables entre eux en termes de complexité. 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 Pi 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. Il fait un calcul entier en précision arbitraire. Pour cela, les calculs sont faits par la machine de la même manière qu on le faisait à la main sur du papier. Si un homme décompose une opération en opérations à un chiffre, la machine décompose l opération en fonction de la taille de ses registres. Dans ce type de calculs, avoir un registre deux fois plus large est très avantageux. En effet, pour une même (grande) précision, le nombre d opérations est divisé par deux. Ce programme prend peu de place mémoire, il reste ainsi dans le cache de premier niveau. C est un test synthétique de la puissance de calcul brut en nombre entier de calcul de la machine. Ogg, convert Pour tester les capacités de calcul en nombre flottant, j ai choisi d utiliser les Ogg Tools (oggenc, oggdec). Le compresseur audio utilise beaucoup la FPU. ImageMagick est de plus en plus utilisé dans les générateurs de site web pour diffuser des photos. Il permet de générer des photos en différentes tailles. C est d ailleurs assez long. Le but est de calculer le temps mis pour réduire à une taille donnée un répertoire rempli d images issues d un appareil photo numérique de 4 méga pixel. En utilisation «normale», les entrées/sorties sont très sollicitées pour lire et écrire les images. Ici, les IOs vont être remplacées par l utilisation de la RAM, en raison de l utilisation de tmpfs. En effet, il y a ici «création» d images qui ne peuvent pas être déjà présentes dans un quelconque cache. FFMPEG est le codec utilisé par défaut par beaucoup de compresseurs vidéo disponibles sous Linux. J ai voulu tester XviD qui est également populaire sous d autres OS et qui est plus ou moins la référence en termes de qualité d image. J ai fais un encodage à deux passes avec un son MP3 produit par Lame (l avi supportant très mal le ogg). Parallélisme Je me suis aussi intéressé au test du comportement de la machine avec une charge supérieure à 1 (ce qui veut dire que plus de un programmes sont prêts et utilisent le CPU en même temps). Pour cela, il suffit de lancer plusieurs tâches en parallèle. Cela permet de pouvoir comparer des systèmes n ayant pas le même nombre de CPU. Les performances dépendent plus de la manière dont l OS gère cette charge, de la structure des caches, de la bande passante mémoire par CPU et surtout du nombre de CPU. Cela permet ainsi d évaluer les processeurs SMT (Simultaneous Multi-Threading) comme l hyperthreading des derniers Intel P4. Le SMT consiste en la duplication des registres pour avoir les «entrées» de deux CPU, mais en mutualisant l accès 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ées de nos jours. L utilisation de l option - j de make permet de tester réellement l accélération de la compilation. Pour les autres tests, il s agit simplement de la même tâche lancée n fois. Chaque test a été lancé avec 1, 4 et 8 tâches en même temps. AMD64, Opteron, Athlon 64 et Athlon FX AMD64 est une extension 64 bits du jeu d instruction 32 bits x86 utilisé dans les PC. L Opteron est la version «Pro» de chez AMD destinée aux serveurs (sur socket 940). L Athlon 64 est une version de l Opteron avec un bus mémoire deux fois plus petit à l origine (socket 754), de nouvelles versions avec la même bande passante viennent de sortir (socket 939). L Athlon FX est, à l origine, un Opteron repackagé pour l utilisation desktop. Comme le grand public est moins exigeant en termes de fiabilité que les professionnels, l Athlon FX est disponible dans des fréquences plus élevées que l Opteron. L origine professionnelle de l Athlon FX- 53 rend obligatoire l utilisation de mémoire ECC. 32

5 33 L architecture x86_64 double le nombre de registres disponibles. C est davantage cette extension qui fera gagner des performances que l extension des registres à 64 bits. En effet, les entiers 64 bits vont prendre deux fois plus de place en mémoire, et cela souvent pour rien. Le 64 bits permet de franchir la barrière des 4 Go de RAM par processus (la carte mère de test accepte jusqu à 8 Go). Certains systèmes Xeon d Intel peuvent atteindre 64 Go, mais toujours avec cette limite de 4 Go adressables par processus. Dans certaines applications qui utilisent les registres comme des champs de bits, les registres 64 bits peuvent traiter deux fois plus de données en une fois et permettent donc d aller, en théorie, deux fois plus vite si le code est prévu pour cela (certains jeux d Échec, d application de cryptographie, ou de 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 d ailleurs de tester GLXGEARS : 7800 fps! Ouais, je sais, j ai la plus grosse configuration!). La carte mère est une SK8N d Asus. Le FX-53 est sous le radiateur qui est derrière le ventilateur si, si je vous assure Pour le test, j ai utilisé la version AMD64 (renommé x86_64 depuis pour la 10.1) de la Mandrake Elle marche sans problèmes même si tous les paquets ne sont pas encore disponibles. Il est possible de mixer les bibliothèques et les exécutables 32 et 64 bits. Avoir les résultats de l Athlon FX 53 en mode 32 et 64 bits est intéressant en soit. Mais il est encore plus intéressant de les comparer avec un maximum de machines. Les autres machines de test J ai pu comparer le monstre avec ma machine de travail qui est un bi-athlon avec 768 Mo de RAM. Celle-ci est loin d être ridicule dans tous les tests. Je l ai également comparé avec mon portable PIII 500 Mhz, avec 196 Mo de RAM, qui est ridicule dans quasiment tous les tests, quand il n est pas à genoux avant de finir :) J ai également pu avoir accès à l Athlon sur socket 754 d un ami. Ce CPU fait partie de la série Athlon 64 «abordable», par contre, il dispose de la moitié de la bande passante mémoire du FX (64 contre 128 bits). Enfin, j ai pu avoir quelques résultats de machines dont je n avais pas l accès root. Il n a donc été possible que de tester les programmes installés par défaut : un mono XEON 3.06 GHz qui apparaît équipé de deux CPU grâce à l hyperthreading (CPU virtuels donc), et un bi-xeon 3.2 GHz qui apparaît dans les graphiques avec quatre CPU (virtuels). J ai également eu accès à un portable PowerBook G4 à 500 Mhz. Ces résultats m intéressaient particulièrement pour enfin connaître le rapport de puissance entre un x86 et un PowerPC. Pour se faire une idée plus précise d une machine récente, j ai divisé les temps par deux pour estimer ce que donnerait un G4 à 1 GHz (d où le terme Virtuel_G4). Globalement, les chiffres fournis devraient être plus élevés qu avec 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 parallélisation dynamique, tout est fait en statique par le compilateur. Le compilateur d Intel a nécessité de grosses recherches pour tirer toutes les performances de ce processeur. Les applications testées ont été compilées avec GCC qui est moins avancé que Icc dans la compilation VLIW (si on veut rester poli). De plus, je tiens à rester dans l optique du test d une architecture sous Linux avec les outils libres habituels. Si je fais ce préambule, c est que l Itanium n est pas fait pour Linux, à moins que ce ne soit l inverse, Intel ne cherchant pas à améliorer GCC dans ce domaine. Ces quelques résultats sont donc plus là pour le fun. Chaque graphique présente en abscisse le nombre de tâches en parallèle. La valeur la plus importante à retenir est la première, lorsque le CPU n exécute qu une tâche à la fois. L ordonnée est une normalisation au temps «user» du CPU le plus rapide. Par exemple, un CPU A met 30 secondes à finir un test, un CPU B 40 secondes. 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. Conclusion Globalement, les améliorations dans le jeu d instructions compensent largement l éventuel gâchis 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 cœur est codé en assembleur, seront portées en assembleur x86_64 d autant plus vite que les CPU compatibles se démocratiseront. Tests de l AMD Athlon FX 53

6 Résultats Compact 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 n est pas trop loin derrière. On remarque que le G4 à 1 GHz ferait jeu égal avec l Athlon à 1533MHz. Résultats md5sum 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 consommation mémoire des entiers 64 bits. La perte est faible : quelques pourcents seulement. Player est un test qui utilise mplayer en mode benchmark. Résultats Player Dans ce mode, le nombre d images 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, par exemple, pour un PDA. Ici, la décompression ne semble pas écrite en assembleur pour la version x86_64, d où la différence de performance avec le mode 32 bits. 34

7 35 Résultats Film(XviD) XviD (bench Film) n était pas encore porté sous Mandrake AMD64 quand j ai fait le test, d où la création du test suivant. Les performances du en x86_64 ne laissent présager 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. Résultats Image Dans Image (utilisation de convert de ImageMagick), la version 64 bits atteint presque 20% de vitesse en plus! Résultats ffmpeg FFMPEG (libavcodec) est hautement optimisé en assembleur, mais il ne l est pas encore complètement en X86_64. Il semble ici que la version de la lib testée sur le ne devait pas être la même et devait utiliser la version purement C, à moins que la différence de performance ne soit due à la bande passante réduite. On remarque la très bonne performance du G4 grâce à son jeu d instructions SIMD Altivec. Tests de l AMD Athlon FX 53

8 Résultats Music Le test Music (ogg tools) est assez important car c est le seul test qui mesure 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. Résultats pi Pi est un test entier limité uniquement par la puissance du CPU. Ici, on voit que la version 64 bits est deux fois plus rapide que la 32 bits. Ceci est dû à l avantage évident d avoir des registres deux fois plus grand pour faire des calculs en grande précision. Résultats Gcc La version 64 bits est 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 consommation de bande passante mémoire doit compter ici aussi. 36