Impact des compilateurs sur les architectures CPU x86/x64

Optimisations et performances

Comme nous l'évoquions précédemment, il n'y a pas qu'une seule manière de traduire un programme C en langage machine exécutable par un processeur. Les compilateurs tentent donc de se démarquer en proposant des options, des optimisations qui ont pour but, en général, d'améliorer les performances. Avant d'aller plus loin et de clarifier ce que nous entendons par optimisation, il est important de relativiser l'impact que le compilateur peut avoir.

En effet si les compilateurs sont de plus en plus intelligents, et peuvent parfois proposer des optimisations et des gains de performances redoutables, ils ne sont pas miraculeux et ne peuvent pas automatiquement transformer un algorithme (la logique du programme) lent et mal conçu en quelque chose de très rapide. Qu'il s'agisse de parallélisme (utiliser tous les cœurs) ou d'optimiser l'exécution sur les processeurs modernes, les compilateurs tentent de faire de leur mieux à partir du code écrit par les développeurs. Pour compliquer la chose, la barrière qui sépare ce qui est du ressort du développeur et du compilateur est de plus en plus fine. Si la gestion des multiples cœurs en parallèle est censée être du ressort du développeur, certains compilateurs s'aventurent (souvent mal) sur ce terrain. A l'inverse la prise en compte de l'architecture du processeur, censée être complètement cachée par le C/C++ et purement du ressort du compilateur peut être prise en compte par les développeurs via divers mécanismes censés aider à ce que le compilateur comprenne leurs intentions. Vouloir profiter au maximum des performances des processeurs modernes, à défaut d'être un art, est donc très souvent un difficile numéro d'équilibrisme, aussi bien pour le développeur que pour le compilateur. Ceci étant posé, revenons sur les différentes optimisations que l'on pourra retrouver au sein des compilateurs !

Réduire la taille

Dans un temps ancien, la qualité d'un compilateur se jugeait à la taille du fichier exécutable (le code machine compilé) qu'il produisait. A une époque ou le stockage était couteux, l'économie de quelques kilo-octets n'était pas quelque chose de négligeable.

Mais au-delà du simple gain de place, réduire la taille était considéré comme une optimisation de performances. Etant donné que nos processeurs se distinguent sur leur capacité à exécuter le maximum d'instructions par seconde, réduire le nombre d'instructions directement dans le programme en réduisant sa taille peut paraitre une piste intéressante !


S'il y a un fond de vérité, de nos jours cependant la question de la taille de l'exécutable est plus complexe. Toutes les instructions n'ont en effet pas le même temps d'exécution. Sur l'architecture Sandy Bridge d'Intel par exemple, là où une addition (add) aura une latence d'un cycle (un hertz du total de GHz du processeur), une multiplication entière (imul) en prendra trois et la division (div) 26 ! Des chiffres qui, qui plus est, ne sont pas constants d'un processeur à l'autre : sur un Pentium 4 F la multiplication avait une latence de 10 cycles.

La chose se complique encore lorsque l'on prend en compte le fait que les cœurs de processeurs, nous en parlons souvent dans nos articles sur l'architecture des processeurs (Bulldozer, Sandy Bridge), disposent dans chacun de leurs cœurs de multiples unités (on parle d'architectures super scalaires, la possibilité d'exécuter plusieurs instructions par cycle, une nouveauté introduite par le Pentium). Ainsi, un processeur Sandy Bridge peut réaliser trois additions en simultanées en un seul cycle, ce qui est aussi le cas d'un Phenom II par exemple. Dans le cas de l'architecture Bulldozer, ce nombre tombe à deux par cœur (les curieux pourront retrouver une liste complète des latences et débits des instructions sur de multiples architectures x86 dans ce document PDF de Torbjörn Granlund ).

Optimiser pour la taille reste malgré tout une option présente dans les compilateurs, nous noterons dans nos tests pratiques un peu plus tard un cas ou cela aura été bénéfique. Dans la majorité des autres cas, cette option ralentissait les performances.