AMD aurait truqué les benchmarks !?

Certains tests de benchmarks, en particulier le Mini-GZIP, auraient été optimisés pour le 64 bits, mais sans que cette optimisation n’ait profité aux processeurs 32 bits !

C’est ce que révèle le site X86-Secret, qui rappelle que « L’énorme majorité des sites hardware (nous inclus) et de la presse papier a donc pu observer les extraordinaires gains offert par la version 64-bit de Mini-Gzip (gain de plus de 100%) et en faire part aux lecteurs« . En fait, en l’absence d’applications 64 bits lors de la sortie de l’Athlon 64, et pour cause !, AMD avait fourni avec ses machines de test un CD d’exécutables de benchmarks de performances intitulé ‘AMD Performance Analysis Tools‘. Concrètement, ces optimisations n’ont pas profité aux tests 32 bits, par exemple en ne prenant pas en compte des optimisations de base comme le MMX ou le SSE, qui pourtant figurent dans les fonctionnalités de base des processeurs depuis quelques années. Quelles conséquences pour les tests de comparaisons de processeurs 32 et 64 bits ? Et bien si les benchmarks 32 bits avaient bénéficié de la même optimisation que les benchmark 64 bits, les résultats des premiers auraient affiché des vitesses deux fois plus rapides. « Si AMD avait daigné activer une simple optimisation de base, le benchmark 32-bit aurait été 2 fois plus rapide !« , vient confirmer X86-Secret. Le gouffre est tel qu’il a servi à survaloriser la puissance des processeurs 64 bits d’AMD, alors que les résultats des processeurs 32 bits sont beaucoup performants qu’annoncés ! Les benchmarks ont toujours été une source de discorde, aux résultats orientés au profit de l’un ou de l’autre. On se souviendra des fonctions de l’Itanium désactivées pour des tests comparatifs avec le Power 5 sur les serveurs d’Apple ! Mais si la tromperie d’AMD est avérée, elle risque moins de relativiser la puissance de l’Opteron par rapport à ses concurrents 32 bits, que de fournir un sujet de moquerie dans les mois à venir? Explication technique de la tromperie

X86-Secret nous fournit la démonstration de la ‘

tromperie‘ d’AMD : AMD a réécrit en ASM x86-64 le code C d’une fonction utilisant le plus de temps CPU : « longest_match ». Intéressant puisque, outre le 64-bit en lui même, la réécriture de n’importe quelle fonction C en assembleur est source de gain de rapidité. Le plus intéressant provient de l’exécutable 32-bit fourni par AMD. Basé sur les sources de zLib 1.1.4, cet exécutable n’inclus absolument aucune des optimisations de base qu’on peut passer au compilateur. Sachant que, dans cet exécutable, la fonction « longest_match » est en C, donc très dépendante du compilateur, on s’étonne beaucoup de cet « oubli ». L’étonnement est encore plus grand lorsqu’on sait que, pour activer ces optimisations, il ne suffit que d’ajouter « -Ox » dans le fichier MakeFile. Pire, si AMD avait vraiment voulu comparer deux choses comparables, il aurait été bon de comparer leur exécutables 64-bits avec un exécutables 32-bits doté de la fonction « longest_match », codée en Assembleur. Or, non seulement cette optimisation existe depuis 1998 : « Pentium-Pro-optimized version of longest_match() » par Brian Raiter, mais en plus celle-ci est incluse dans le répertoire « /contrib » des sources qu’AMD fournies ! Pourquoi alors avoir volontairement (un oubli est exclu) choisi de supprimer toutes les optimisations au code 32-bit ? La réponse semble simple : pour favoriser la version 64-bit dont les gains, alors, n’ont plus rien a voir avec le 64-bits.