Avant de parler de la pratique honteuse d'AMD que nous comptons dénoncer ici, un rapide retour en arrière est nécessaire pour bien comprendre de quoi il s'agit. Septembre 2003 : Lancement de l'Athlon 64 et de l'Athlon 64-FX. Les premières machines à destinations de la presse commencent à être livrées, avec une version Beta de Windows XP pour AMD64. Dans le carton, tous les journalistes du monde entier trouveront un CD intitulé "AMD Performance Analysis Tools" qui contient quelques exécutables de benchmarks spécialement optimisé par AMD pour le 64-bits. Massivement utilisés par toute la presse à défaut d'autre applications 64-bits à l'époque, ils ont permis de se faire une idée des gains attendus grâce aux extensions AMD64.

Parmi ces benchmarks, un seul est livré avec ses sources et est librement redistribuable, il s'agit d'une version 64-bit d'un benchmark Mini-GZIP, utilisant la librairie ZLIB. Peu de journalistes ayant les compétences et les outils nécessaires pour compiler eux-mêmes le programme, AMD fournit bien sur un binaire 32-bit et un binaire 64-bit, compilé avec Visual C++ 6, ainsi qu'un fichier texte de 23.6 Mo contenant "20000 lieues sous les mers" de Jules Vernes. L'énorme majorité des sites hardwares (nous inclus) et de la presse papier a donc pu observer les extra-ordinaires gains offert par la version 64-bit de Mini-Gzip (gain de plus de 100%) et en faire part aux lecteurs. Encore largement utilisé, ce benchmark fût repris il y a une semaine par x86-secret lors de notre comparatif 32 Vs 64 Bits.

C'est peu aprés que Gilles Vollant, qui a effectué des développements autour de la zLib, nous contacta pour nous demander les fichiers sources de la zlib optimisée par AMD. Intérogé au sujet de l'enorme gain en 64-bit, Il en profita également pour emettre quelques doutes sur la facon dont l'executable 32-bit fût compilé. C'est ainsi que nous nous sommes lancés dans une étude plus approfondie de ce fameux benchmark.

Comme Gilles l'a constaté, 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 cet 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 fournis !

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. Pour en être sur, Gilles a compilé trois librairies zLib 1.1.4 (la même qu'AMD), en utilisant  VC6 comme compilateur (le même qu'AMD en 2003), et nous avons mesuré les performances de ces quatre librairies :

• zlibnoopti.dll : Identique à la version d'AMD, elle n'inclus aucune des optimisations de base.
• zliboptic.dll : Identique à la version d'AMD, sauf le paramètre "-Ox" passé au compilateur comme tout programme normalement compilé.
• zlibasm.dll : Identique à la version d'AMD, mais incluant le code ASM de Brian Raiter pour la fonction "longest_match".
• zlib64 : La version 64-bit optimized founie par AMD

A noter que les résultat de zlibnoopti.dll sont identiques à ceux fournis par le binaire d'AMD. Voici donc les (surprenants) résultats :

Si AMD avait daigné activer une simple optimisation de base, le bench 32-bit aurait été 2 fois plus rapide ! Pire, avec l'optimisation ASM Pentium Pro de 1998, le code 32-bit devient plus rapide que le code 64-bit fourni par AMD ! Il est impossible qu'AMD n'ai eu connaissance de la manière de compiler correctement un fichier, surtout pour des développeurs qui ont convertis en 64-bit une fonction C complexe. Bref, alors qu'AMD recommande toujours l'utilisation de ce benchmark dans ses guides officiels pour reviewers, on peut affirmer qu'AMD a délibérément bridé la version 32-bit pour promouvoir ses extensions 64-bit (A noter que Gilles Vollant a, de son coté, convertis puis optimisé le code de Brian Raiter en assembleur AMD64, ce qui permet d'obtenir une routine plus rapide que celle en assembleur founis par AMD et que celle de Brian Raiter en 32 bits d'au moins 5%). Bref, le pire dans l'histoire étant que tout les journalistes (nous inclus) se sont fait avoir sans s'apercevoir de rien, et ce n'est qu'un an et demi après que le pot au rose est découvert. Inutile de dire, dans ces circonstances, aucun des autres benchmarks fournis par AMD ne vaut une cacahouète. Dommage, après le 6xx, je n'ai plus d'encre sur mon tampon REJECTED...

EDIT : Nous avons mis en téléchargement les dll utilisées (Voir ici)