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.