Précédent : Gestion de la mémoire Remonter : Résultats nouveaux Suivant : Contrats industriels (nationaux, européens et
Précédent : Gestion de la mémoire
Remonter : Résultats nouveaux Suivant :
Contrats industriels
(nationaux, européens et
Le pipeline logiciel est une technique d'optimisation des boucles par réordonnancement des instructions, basée sur un recouvrement des différentes itérations. Les techniques que nous développons sont intégrées au noyau PILO.
Cette année, nous avons développé une méthode de contrôle du nombre de registres nécessaires, basée sur l'ajout contrôlé d'anti-dépendances de données artificielles Ainsi on limite a priori à la fois la pression sur les registres et le degré de déroulage, et donc la taille du code final. Cette méthode est paramétrée par un entier donnant la distance des anti-dépendances ajoutées. Dans le cadre d'une approche itérative d'otimisation de code (projet OCEANS), on peut agir sur ce paramètre pour choisir un code donnant le meilleur compromis possible entre performance, nombre de registres et taille du code. Ce travail est décrit dans [[36]].
Dans le but d'étendre le pipeline logiciel au cas des boucles avec branchements, nous avons aussi développé une nouvelle technique, appelée OMS (Overlapped Modulo Scheduling). L'algorithme est itératif. Partant d'un réordonnancement local d'une itération, on replie le code pas à pas, en recalculant à chaque étape le paramètre MII, qui donne la performance du code associé. Dans cette étude, nous avons diminué la complexité du calcul de MII. L'algorithme OMS a ensuite été étendu pour prendre en compte les branchements dans les boucles et les instructions gardées présentes dans certains processeurs rapides. L'algorithme étendu s'appelle GOMS (Global Overlapped Modulo Scheduling) ; il permettra de faire un compromis entre branchements et instructions gardées, qui peuvent augmenter considérablement la taille du code. Ces travaux sont décrits dans [[37]].
Enfin l'intégration de PILO et LORA à SALTO constitue l'environnement SPS, premier environnement reciblable de pipeline logiciel [[14]].
A l'origine, la technique de pipeline logiciel est utilisée dans l'optimisation de code assembleur, à bas niveau. Or, toutes les informations nécessaires à sa mise en oeuvre sont présentes dans le code à haut niveau - indice de boucle, bornes des boucles, calcul des adresses des tableaux ...- et disparaissent dans le processus de génération de code. De plus, le développeur de code n'a aucun moyen de contrôler l'ordonnancement de son code, alors qu'il peut être détenteur d'informations primordiales, par exemple qu'une donnée n'a sûrement pas été utilisée avant et causera un défaut de cache lors de son chargement. C'est pourquoi nous avons intégré un restructureur de code par pipeline logiciel dans l'environnement de parallélisation Sage++ (développé à l'Université d'Indiana). La boucle FORTRAN est tout d'abord découpée en code à 3 adresses. Les variables temporaires sont stockées dans des tableaux (un tableau par variable du corps de la boucle, chaque élément de tableau correspond à une itération). Le graphe de dépendances est ensuite déterminé, puis envoyé à un logiciel de pipeline logiciel, qui renvoie les dates de lancement des différentes opérations. Les informations liées à l'architecture peuvent aussi être spécifiées par l'utilisateur. Pour provoquer le pré-chargement des données, il peut par exemple indiquer une grande latence d'accès à la mémoire. L'allocateur de registres alloue ensuite les tableaux temporaires dans des variables scalaires, qui seront a priori sauvegardées en registres par tous les compilateurs. Ainsi, l'utilisateur a le contrôle sur l'ordonnancement de son code à bas niveau et peut mettre au point les performances de son code de manière fine.
Cette année, le travail a consisté à intégrer dans le processus d'optimisation une phase d'élimination des chargements mémoire redondants. Eliminer les chargement mémoire redondants diminue la pression sur les accès mémoire qui sont souvent le facteur bloquant de la performance. En retour, on accroît ainsi la pression sur les registres et générer du spill code qui aurait été inutile dans le code original. Nous étudions actuellement comment trouver le meilleur compromis entre mémoire et registres dans ce cadre. Une première version d'élimination des chargements mémoire redondants est déjà implémentée [[19]].