Les optimisations des compilateurs

Bonjour à tous,

J'ai le plaisir de vous proposer un tutoriel écrit par Guy Grave, alias mewtow, sur les optimisations effectuées par les compilateurs.

Bonne lecture.

Lire le tutoriel
Voir d'autres articles de mewtow

:fleche: Tous les meilleurs cours et tutoriels pour apprendre le langage C.

Il enchaine en ce moment ! :D

Remarques :
- section II A 2, le lien vers Wiki ne fonctionne pas.
- section II C 6, il est dit "dernière optimisation", mais il y a la section II C 7 et II C 8 (qui dit elle aussi "dernière optimisation" ^^)

Je ne comprends pas l'objet de ce tutoriel.

On ne rentre pas assez dans le détail pour comprendre ce qui est gagné, et il y a trop de prérequis pour comprendre pourquoi ca optimise.

Par exemple, il n'y a pas d'explication succinte de ce qu'est le fonctionnement en pipeline (et du coup pourquoi le compilateur est si fort à s'en servir)

Citation:

---

Envoyé par Bktero

Il enchaine en ce moment ! :D

Remarques :
- section II A 2, le lien vers Wiki ne fonctionne pas.
- section II C 6, il est dit "dernière optimisation", mais il y a la section II C 7 et II C 8 (qui dit elle aussi "dernière optimisation" ^^)

---

Le lien a été réparé :)

Personnellement, j'ai bien aimé ce tuto.
Cela donne un bon panorama des types d'optimisation des compilateurs C.

Citation:

---

Envoyé par Guy Grave

II-C-1. Inlining

Une optimisation bien connue est l'inlining. Cette technique consiste à éliminer les appels de fonction d'un programme : le corps de la fonction est intégralement recopié à chaque endroit où celle-ci est appelée. Il faut remarquer que cette technique a tendance à fortement augmenter la taille du code : au lieu d'un seul exemplaire de la fonction, celle-ci est recopiée en autant d'exemplaires qu'il y a de sites d'appel. Aussi, elle n'est effectuée que pour des fonctions relativement petites.

Cela permet d'éliminer l'appel de la fonction, ainsi que tout le code qui prépare l'appel. Dans certains cas, cela permet aussi d'améliorer l'usage de la mémoire cache (pas de saut dans la mémoire). L'inlining permet aussi à d'autres optimisations de fonctionner plus efficacement, comme la propagation de constantes. Il permet aussi d'obtenir des blocs de code linéaires de « grande taille », permettant au réordonnancement d'instructions de fonctionner au mieux.

---

Cependant, dans le cas des toutes petites fonctions, l'inlining peut réduire la taille du code, puisqu'on élimine l'appel de la fonction.
Je pense qu'il faut le préciser explicitement dans le tutoriel. Sinon, un lecteur risque d'interpréter que l'inlining augmente toujours la taille du code, parfois un peu et souvent beaucoup.

Bonsoir,
Je suis d'avis avec @leternel et personnellement je suis étonnée que l’on ne parle pas de: Graphe de flots d’exécution de contrôle, analyse globale de flot de données ou encore les divers algorithmes de flot de données, car c’est là-dessus que compilateur se base pour effectuer les optimisations nécessaires (en utilisant les techniques) par exemple: Le remplacement de code récurrent plus exactement, « l’élimination des sous-expressions communes » dans le graphe de flot de contrôle, optimisation de boucle en appliquant les techniques dites de déplacement de code qui transfère du code à l’extérieur des boucles, l’élimination des variables d’induction qui permet par exemple d’éliminer les variables i; j, k des boucles locales, et enfin le réducteur de force qui remplace les opérations coûteuses par la moins coûteuse et c'est bien dommage que la section « II-B-5. Réduction en force » ne rentre pas en détail dans optimisation des boucles avec des exemples soutenu dans une section spéciale.

Pour moi, s’il faut parler d’optimisation faite par le compilateur il faut donc, allé plus en profondeur; à commencer, par un résumé, de façon brève du rôle de l’optimiseur et comment il réalise les optimisations. Cela sous-entend que l’on doit aussi présenter de façon brève les différents algorithmes et technique que le compilateur utilise.
Malgré le manque de certaines explications le tutoriel est très bien et fort utile pour comprendre certaines technique optimisations faites par le compilateur.
à bientôt.

Citation:

---

Cependant, dans le cas des toutes petites fonctions, l'inlining peut réduire la taille du code, puisqu'on élimine l'appel de la fonction.
Je pense qu'il faut le préciser explicitement dans le tutoriel. Sinon, un lecteur risque d'interpréter que l'inlining augmente toujours la taille du code, parfois un peu et souvent beaucoup.

---

La taille du code va être effectivement augmenté mais l’exécution sera plus rapide, pas de prologue ni d'épilogue. Le but est d'avoir un code plus rapide, pas plus court.

Citation:

---

Envoyé par chrtophe

La taille du code va être effectivement augmenté mais l’exécution sera plus rapide, pas de prologue ni d'épilogue. Le but est d'avoir un code plus rapide, pas plus court.

---

Le code peut aussi être plus court.

Je prends un exemple simple :

Code:

---

1 2 3 4 5 6 7 8

static int determinant(int a, int b, int c) { return b*b-4*a*c; }   int main() { return determinant(2, 10, 5); }

---

Ici, avec l'inlining, determinant(2, 10, 5) serait remplacé par 60, ce qui est plus court (en plus d'être plus rapide) que de déposer 2, 10 et 5 dans la pile ou dans des registres (selon la convention d'appel) puis d'appeler la fonction.

Sur le site https://gcc.godbolt.org/ , avec GCC 6.2, j'ai le code assembleur suivant pour la fonction main :

Code:

---

1 2 3 4 5 6 7 8 9 10

main: push %rbp mov %rsp,%rbp mov $0x5,%edx mov $0xa,%esi mov $0x2,%edi callq 4004f6 <determinant(int, int, int)> pop %rbp retq nopw %cs:0x0(%rax,%rax,1)

---

Par contre, si je remplace return determinant(2, 10, 5) par return 60, le code devient :

Code:

---

1 2 3 4 5 6 7

main: push %rbp mov %rsp,%rbp mov $0x3c,%eax pop %rbp retq nopw 0x0(%rax,%rax,1)

---

oui logique,

Le compilateur supprime les appels de fonctions inutiles.

Bonjour,
un petit mot sur certaines «nouveautés» depuis C99 comme le contrat avec le mot clé restrict ou les directives d'alignement auraient pu trouver leur place dans ce document, au demeurant agréable à lire. Peut-être aurait-on pu y trouver aussi des traces d'aide à l'optimisation spécifiques à certains compilateurs comme par exemple pour gcc les attributs de fonctions pure,const,hot, cold, …, les builtins prefetch, …

Citation:

---

Envoyé par sambia39

Bonsoir,
Je suis d'avis avec @leternel et personnellement je suis étonnée que l’on ne parle pas de: Graphe de flots d’exécution de contrôle, analyse globale de flot de données ou encore les divers algorithmes de flot de données. [...] Pour moi, s’il faut parler d’optimisation faite par le compilateur il faut donc, allé plus en profondeur; à commencer, par un résumé, de façon brève du rôle de l’optimiseur et comment il réalise les optimisations. Cela sous-entend que l’on doit aussi présenter de façon brève les différents algorithmes et technique que le compilateur utilise.

---

C'est un choix volontaire de ma part de ne pas aller aussi loin, choix qui tient à plusieurs raisons. Premièrement, l'article aurait été beaucoup plus compliqué et aurait demandé beaucoup plus de pré-requis pour être compris dans sa totalité. En l'état, cet article est plus accessible, notamment pour des grands débutants. Et même ainsi, l'article n'est pas parfait, vu qu'il demande de solides connaissances en architecture des ordinateurs (les rappels nécessaires n'étant pas faits pour gagner de la place), mais c'est une chose qui est absolument nécessaire quand on parle d'optimisations bas-niveau. Deuxièmement, il aurait fallu que je rédige un véritable cours, équivalent à plusieurs chapitre d'un livre portant sur la compilation. Je n'avais ni la motivation ni le temps pour cela.

Citation:

---

Envoyé par picodev

Bonjour,
un petit mot sur certaines «nouveautés» depuis C99 comme le contrat avec le mot clé restrict ou les directives d'alignement auraient pu trouver leur place dans ce document, au demeurant agréable à lire. Peut-être aurait-on pu y trouver aussi des traces d'aide à l'optimisation spécifiques à certains compilateurs comme par exemple pour gcc les attributs de fonctions pure,const,hot, cold, …, les builtins prefetch, …

---

Pour cet article, j'ai préféré me restreindre aux optimisations valables quelque soit le langage (tant que celui-ci est impératif) et non d'optimisations spécifiques au C/C++, histoire de viser large en terme de lecteurs.

Merci, tuto très intéressant.

Merci pour le tutoriel.
Effectivement l'auteur est très actif je viens d'ouvrir deux articles le concernant, j'ai cru à une erreur de clic. :D
Vis à vis des approfondissements énoncés dans ce thread, on aurait pu juste les citer mais aller plus loin ne me semble pas nécessaire pour cet article. Il me semble que l'auteur vise des optimisations codables (à la façon d'écrire les boucles par exemple), ce qui peut convaincre le lecteur qu'il n'est pas tenu d'écrire lui même ces optimisations, au risque de nuire à la lisibilité du code.
J'essaie justement d'écrire un article qui vise la vérification pratique de ces optimisations.

Par contre je suis d'accord avec picodev pour ajouter à la les attributs de fonctions qui peuvent aider le compilateur, puisque justement il est expliqué que le compilateur peut souffrir de lacune et que le développeur peut intervenir pour l'aider, notamment l'usage de l'attribut "pure", expliqué dans le paragraphe II-B-2. Autre détail dans ma Ubuntu la fonction strlen est déclaré avec cet attribut (__attribute_pure__), ce qui fait que l'usage cette fonction dans une condition de boucle est *normalement* optimisée (pas vérifié) avec GCC. Et je viens de le vérifier pour le MDK de Keil. C'est probablement généralisable à toutes les chaînes de compilation récente, mais je n'ai pu vérifier que cela faisait parti d'un standard (sur le site d'opengroup).
A voir cet article (et la discussion) sur LWN.

Citation:

---

Pour cet article, j'ai préféré me restreindre aux optimisations valables quelque soit le langage (tant que celui-ci est impératif) et non d'optimisations spécifiques au C/C++, histoire de viser large en terme de lecteurs.

---

Ces optimisations ne sont peut-être pas vérifiables pour d'autres langages, puisque d'autres fonctionnalités natives non présentes dans le C/C++ peuvent l'être ailleurs. Ca ne change peut-être pas les listings assembleur, mais sûrement le code du développeur. Je pense notamment au python...

Perso j'ai trouvé cet article vraiment intéressant et j'encourage l'auteur à continuer même si certains y trouvent à redire :-)