Discussion :

[dourouc05]

Les compilateurs C++ sont souvent décriés pour leur lenteur, notamment dans le cas de gros fichiers source. Cela est notamment dû à leur fonctionnement en série : ils ont été conçus à une ère où les processeurs multicœurs étaient rares (par exemple, GCC a débuté son existence en 1987). Depuis lors, l’amélioration de performance des processeurs ne se fait plus par une augmentation de fréquence, mais plutôt du nombre de cœurs. La question de la parallélisation devient donc plus pressante. C’est notamment pourquoi LLVM retravaille certaines parties de son infrastructure pour être mieux exploité en contexte multifil.

Un projet GSoC (Google summer of code) a consisté en l’étude de la parallélisation d’une partie des opérations de GCC, plus particulièrement la partie intermédiaire du compilateur, celle qui s’occupe d’effectuer des optimisations du code indépendantes du processeur ciblé (cette phase se passe sur la représentation intermédiaire GIMPLE). La partie intermédiaire prend une quinzaine de pour cent du temps d’exécution total sur un fichier de test (gimple-match.c, qui représente 100 358 lignes de code C++). Cette phase se passe en deux temps : les optimisations intraprocédurales (optimiser une fonction sans considérer ses interactions avec d’autres) et interprocédurales (avec les interactions, appelées IPA par GCC : inter process analysis).

L’architecture proposée des optimisations se base sur une file producteur-consommateur pour chaque passe d’optimisation, chaque fil d’exécution pouvant prendre un élément dans cette file. De la sorte, si toutes les fonctions à optimiser sont bien équilibrées, on peut espérer diviser le temps d’exécution par le nombre de cœurs disponibles.

Le résultat est assez intéressant : en passant d’un à huit fils d’exécution (le processeur de test disposant de quatre cœurs), le temps complet d’exécution des optimisations est divisé par 2,52 (au vu des parties qui ne sont pas parallélisées, on pouvait espérer un facteur théorique de 2,7). Le temps complet de compilation ne descend que de neuf pour cent. En appliquant la même technique aux optimisations spécifiques aux processeurs (en travaillant au niveau RTL plutôt que GIMPLE), les gains sont plus marqués, cette partie représentant une portion plus importante du temps de compilation : on peut gagner soixante et un pour cent en temps d’exécution en utilisant huit fils d’exécution !

Ces développements ne sont pas encore intégrés dans le code de GCC, mais cela devrait arriver, au vu des gains que l’on peut espérer. Une parallélisation plus fine pourrait encore diminuer les temps de compilation.

Source : présentation GNU Cauldron 2019.

[lsbkf]

Je vois que ça parle de make -j dans leurs slides, mais où est le gain par rapport à ça dans une situation réelle ? C'est pas clair, ça s'étale sur les gains de perfs par rapport à un seul fichier, dont la taille est déjà en soi une erreur à ne pas commettre. On gagnerait plus de temps de compilation à le séparer en plusieurs fichiers, sans pour autant tomber dans l'extrême inverse où on passe plus de temps à multiplier les process et à linker qu'à effectuer la compilation.

Est-ce qu'on a vraiment besoin de paralléliser GCC ou est-ce que c'est juste un projet de recherche ? Personnellement quand je veux compiler un projet, j'enlève cette maudite option -j parce que j'ai envie de faire autre chose en attendant et que j'apprécie pas trop le ventilateur.