Parall�liser le fonctionnement de GCC
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.
