Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Les optimisations des compilateurs


Sujet :

C

  1. #1
    Responsable 2D/3D/Jeux

    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

    Tous les meilleurs cours et tutoriels pour apprendre le langage C.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  2. #2
    Modérateur

    Il enchaine en ce moment !

    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" ^^)

  3. #3
    Expert éminent sénior
    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)
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  4. #4
    Responsable 2D/3D/Jeux

    Citation Envoyé par Bktero Voir le message
    Il enchaine en ce moment !

    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é
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  5. #5
    Expert confirmé
    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.

  6. #6
    Membre chevronné
    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.
    Celui qui peut, agit. Celui qui ne peut pas, enseigne.
    Il y a deux sortes de savants: les spécialistes, qui connaissent tout sur rien,
    et les philosophes, qui ne connaissent rien sur tout.
    George Bernard Shaw

  7. #7
    Responsable Systèmes

    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.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutor...s/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  8. #8
    Expert confirmé
    Citation Envoyé par chrtophe Voir le message
    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 :Sélectionner tout -Visualiser dans une fenêtre à part
    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 :Sélectionner tout -Visualiser dans une fenêtre à part
    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 :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    main:
     push   %rbp
     mov    %rsp,%rbp
     mov    $0x3c,%eax
     pop    %rbp
     retq   
     nopw   0x0(%rax,%rax,1)

  9. #9
    Responsable Systèmes

    oui logique,

    Le compilateur supprime les appels de fonctions inutiles.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutor...s/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  10. #10
    Membre émérite
    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, …

  11. #11
    Invité
    Invité(e)
    Citation Envoyé par sambia39 Voir le message
    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 Voir le message
    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.

  12. #12
    Membre actif
    Merci, tuto très intéressant.

  13. #13
    Membre confirmé
    Merci
    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.
    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.

    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...
    Selso.
    Ingénieur/CdP développement systèmes embarqués &

  14. #14
    Membre du Club
    Tres bon article
    Perso j'ai trouvé cet article vraiment intéressant et j'encourage l'auteur à continuer même si certains y trouvent à redire :-)

###raw>template_hook.ano_emploi###