Introduction
Lors de la création d’un émulateur de processeur x86-32 pour les systèmes qui exécutaient nativement un autre processeur, les développeurs de Windows ont rencontré un cas particulièrement intéressant. Un programme nécessitait l’allocation de 64 Ko de mémoire sur la pile et son initialisation, mais le compilateur utilisé avait généré du code d’une inefficacité flagrante.
Contexte Technique
L’émulateur en question utilisait la traduction binaire, générant du code natif pour effectuer les opérations équivalentes au code x86-32 d’origine. Cette approche offrait une amélioration significative des performances par rapport à l’émulation via interpréteur. Le code x86-32 peut être vu comme du bytecode, et l’émulateur agissait comme un compilateur JIT.
Le programme en question devait allouer 64 Ko de mémoire sur la pile et l’initialiser. La méthode standard consiste à effectuer une analyse de la pile pour s’assurer de la disponibilité de 64 Ko de mémoire, puis à soustraire 65 536 de l’indice de pile, et enfin à initialiser la mémoire dans une petite boucle serrée.
Analyse et Implications
Cependant, le compilateur utilisé avait « optimisé » le code en déroulant la boucle d’initialisation en 65 536 instructions individuelles « écrire un octet en mémoire », chacune sur 4 octets. Cela a résulté en un code de 256 Ko pour initialiser 64 Ko de données.
Cette approche a tellement offensé l’équipe d’émulateur qu’ils ont ajouté un code spécial au traducteur pour détecter cette fonction horrible et la remplacer par une boucle équivalente serrée.
Perspective
Cet exemple souligne l’importance de l’optimisation du code et des compromis entre la complexité du code et les performances. Les développeurs doivent être conscients des limites de leurs outils et des compromis potentiels lors de l’utilisation de fonctionnalités d’optimisation automatique.
