previous up next top index
Précédent : b) Détection du parallélisme. Remonter : Régularité et transformations de programmes Suivant : Projets HPFIT et TransTool


c) Exploitation du parallélisme.

Détecter le parallélisme d'une application est une chose, l'exploiter en est une autre. Une directive telle que !hpf$ independent est une indication pour le compilateur que certains calculs peuvent être faits en parallèle. Elle ne précise pas où sont les données et où sont effectués les calculs. Pour cela, le programmeur, le compilateur ou le pré-compilateur doivent posséder des techniques de placement des données et des calculs, qui prennent en compte un modèle de machine-cible et son modèle de communications.

La communauté scientifique est toujours à la recherche de la ``bonne façon'' d'aborder ce problème. En l'absence d'une solution définitive, nous avons, nous aussi, étudié de nombreux problèmes de placement, sous des aspects très divers, du fait de la variété de modèles de machines physiques : évaluation d'expressions de tableaux [27, 10] permettant de recouvrir calculs et communications sur des tableaux de processeurs, placement ``modulaire'' [12] pour tenter de formaliser les placements cycliques, placement avec contraintes de ressources [44, 21] pour des réseaux de type systolique, génération automatique de directives de placement pour HPF pour la minimisation des communications [45, 22, 20, 43].

Les travaux précédents visent à prendre en compte le coût des communications entre processeurs. Une autre optimisation importante est la minimisation de la mémoire d'un processeur. En effet, pour exploiter le parallélisme d'une application (souvent écrite pour machines séquentielles avec le souci de réutiliser la mémoire), on est souvent contraint d'``expanser'' la mémoire, c'est-à-dire par exemple de transformer des scalaires en tableaux. Caractériser l'expansion minimale est un problème difficile. Nous donnons des éléments de réponse dans [33, 34].