Idées reçues courantes sur les compilateurs

Idées reçues sur l’optimisation des compilateurs

• L’optimisation produit un programme optimal ?
  • Le compilateur ne vise pas à générer le programme optimal, mais à améliorer un programme simplifié.
  • L’optimisation de la taille du code est parfois possible, mais l’optimisation du temps d’exécution est difficile en raison de la complexité des mesures, de l’absence de sous-structure optimale et de l’imprécision des modèles matériels.
  • Le temps d’exécution, contrairement à la taille du code, est difficile à mesurer précisément, dépend de nombreux facteurs et ne possède pas de sous-structure optimale. Par exemple, même si deux boucles sont optimisées séparément, il peut être nécessaire de les fusionner pour optimiser l’ensemble du programme. De plus, l’absence de modèle précis du matériel cible complique l’optimisation. Par exemple, goSLP génère un code de vectorisation SLP globalement optimisé, mais comme le modèle matériel est imprécis, le programme généré peut non seulement ne pas être optimal, mais aussi être plus lent que LLVM.

Idées reçues sur la prédiction de branchement

• Les poids de branchement sont utilisés par le prédicteur de branchement du CPU ?
  • Sur l’architecture x86, les compilateurs ne génèrent pas d’indices de branchement.
  • Les poids de branchement servent au compilateur pour disposer les blocs de code. (Par exemple, si un branchement a une forte probabilité, le bloc cible est placé juste après le bloc courant afin d’améliorer la localité du cache d’instructions.)
  • Sur la récente architecture Intel Redwood Cove, les indices de branchement ont retrouvé une certaine pertinence, mais en pratique les compilateurs génèrent rarement ce type d’indications.

Idées reçues sur les niveaux d’optimisation

• -O3 génère un code bien plus rapide que -O2 ?
  • Avec Clang, la différence de performance entre -O2 et -O3 est faible, tandis qu’avec GCC il peut y avoir un léger écart car -O2 y est moins agressif que chez Clang.
  • -O3 prend très peu en compte la taille du code, ce qui peut provoquer des problèmes de cache d’instructions.
  • Il vaut mieux le vérifier par benchmarking.

Idées reçues sur les interpréteurs JavaScript et les compilateurs JIT

• Si les interpréteurs JavaScript effectuent une compilation JIT à l’exécution, c’est parce qu’ils ne peuvent pas savoir à l’avance quels chemins seront chauds ?
  • Savoir quels sont les chemins chauds ne suffit pas : il faut aussi des informations de type.
  • Comme ces informations de type ne sont connues qu’à l’exécution, les compilateurs JIT compilent le code au runtime.

Idées reçues sur la relation entre compilateur et interpréteur

• S’il y a un compilateur, un interpréteur ne sert à rien ?
  • Pour C/C++, un interpréteur est peu utile, mais dans des cas comme WebAssembly, il peut offrir des avantages en matière de facilité de développement et d’usage, de débogage et de sécurité.

Idées reçues sur le middle-end des compilateurs

• Le middle-end est indépendant de la cible ou de la plateforme ?
  • Dans le cas de LLVM, le middle-end n’est pas totalement indépendant de la cible ou de la plateforme.

Idées reçues sur l’optimisation de la localité des données

• Le compilateur optimise la localité des données ?
  • Les compilateurs optimisent la localité du cache d’instructions, mais presque jamais la localité des données.
  • L’optimisation de la localité des données exige de grands changements dans le code, que les compilateurs C/C++ ne peuvent pas effectuer.
  • Pour améliorer la localité des données, il faut recourir à des techniques comme la conception orientée données.

Idées reçues sur la vitesse de compilation

• -O0 garantit une compilation rapide ?
  • -O0 génère un code débogable et prévisible, mais ne garantit pas toujours une compilation rapide.
  • En général, -O0 est plus rapide que -O2, mais cela peut varier selon la taille du projet et le compilateur.
  • Pour compiler plus vite, on peut envisager de contourner la pipeline de compilation standard (par exemple avec TinyCC) ou de générer directement du LLVM IR.

Idées reçues sur la vitesse de compilation des templates

• Les templates ralentissent la compilation ?
  • Si les templates C++ ralentissent la compilation, c’est à cause du modèle de compilation de C++.
  • Les templates eux-mêmes ne dégradent pas fortement la vitesse de compilation.
  • La bibliothèque standard Phobos de Dlang utilise beaucoup de templates, mais se compile rapidement.

Idées reçues sur l’intérêt de la compilation séparée

• La compilation séparée vaut toujours le coup ?
  • La compilation séparée peut entraîner des temps d’édition de liens plus longs.
  • Dans de nombreux projets, les unity builds (tout le code inclus dans un seul fichier) offrent de meilleures performances.
  • Les unity builds présentent des avantages comme l’optimisation sur l’ensemble du programme, l’accélération de la compilation et de meilleurs journaux d’erreurs.
  • Il est rare que la compilation séparée soit meilleure qu’un unity build.

Idées reçues sur l’optimisation au moment de l’édition de liens (LTO)

• Pourquoi l’optimisation au moment de l’édition de liens (LTO) a-t-elle lieu à l’édition de liens ?
  • La LTO est réalisée pour optimiser l’ensemble du programme.
  • En théorie, il serait plus logique d’effectuer cette optimisation globale au middle-end, mais à cause des contraintes concrètes des systèmes de build C/C++ (difficulté à retrouver les fichiers source et à déterminer les relations d’appel), elle est effectuée à l’édition de liens.
  • Comme l’éditeur de liens peut trouver tous les fichiers objets, le compilateur inclut dans ces fichiers une représentation intermédiaire comme LLVM IR afin que le linker puisse y accéder.

Idées reçues sur l’optimisation par inlining

• L’inlining est surtout utile parce qu’il supprime les instructions d’appel de fonction ?
  • Supprimer les instructions d’appel de fonction est un avantage, mais le principal intérêt de l’inlining est de permettre d’autres optimisations.
  • L’inlining rend possibles des optimisations inter-fonctions.
  • Quand le code de plusieurs fonctions est fusionné en une seule grâce à l’inlining, il devient possible d’appliquer les techniques d’optimisation habituelles à l’échelle de cette nouvelle fonction.

Idées reçues sur le rôle du mot-clé inline

• Le mot-clé inline a-t-il un lien avec l’optimisation par inlining ?
  • En C++, le mot-clé inline était à l’origine un indice destiné à l’optimiseur, mais depuis C++98 il signifie surtout « définitions multiples autorisées ».
  • Dans LLVM, la présence du mot-clé inline ajoute l’attribut inlinehint et augmente le seuil d’inlining, mais son effet reste limité.
  • Pour forcer systématiquement l’inlining d’une fonction, il faut utiliser le spécificateur always_inline.

Idées reçues sur les ressources d’apprentissage des compilateurs

• LLVM est le meilleur compilateur pour apprendre ?
  • LLVM a aussi un intérêt pédagogique, mais il est complexe et très vaste car il prend en charge de nombreux cas d’usage.
  • Pour apprendre le développement de compilateurs, il vaut mieux commencer par des compilateurs plus petits et plus simples comme le compilateur Go, LDC ou DMD.

Idées reçues sur le comportement indéfini (Undefined Behavior)

• Le comportement indéfini ne sert qu’à permettre davantage d’optimisations ?

  • Le comportement indéfini peut aussi désactiver certaines optimisations.

• Le compilateur peut « simplement » définir le comportement indéfini ?

  • Un compilateur peut définir un comportement indéfini, mais cela peut avoir un impact sur les performances.
  • Il serait idéal qu’un compilateur définisse tous les comportements indéfinis selon le comportement de la plateforme, mais en pratique ce n’est pas simple.

Idées reçues sur la génération de code basée sur l’IA

• Une génération de code correcte à 99 % est acceptable ?
  • Dans un compilateur, un code correct à 99 % est en réalité difficilement exploitable.
  • Une erreur sur 1 % du code entraîne de grandes difficultés de débogage et de maintenance.
  • Dans les grands projets, 1 % d’erreurs peut provoquer des problèmes très graves.
  • Les LLM actuels sont en outre bien trop lents par rapport aux compilateurs pour convenir à une génération de code en ligne.