Modèle d’affinité

Le modèle d’affinité d’une application représente la tendance qu’ont les processus à interagir (au sens large). Cette affinité peut être déterminée en fonction de plusieurs mé-triques : entrées/sorties, accès mémoire, etc. Nous avons choisi de nous baser sur l’échange de données entre processus. En effet, la multiplication des unités de calcul au sein d’une même machine et la diminution de la mémoire par cœur encourage les applications paral-lèles à communiquer de plus en plus pendant l’exécution. Cette métrique nous a semblé pertinente pour ces raisons. Il est cependant à noter que tout comme l’algorithme Tree-Matchne dépend pas de MPI, il ne dépend pas non plus de la seule métrique d’échange de données. Il est tout à fait envisageable d’utiliser d’autres types d’informations en entrée de l’algorithme.

Quoi qu’il en soit,TreeMatch a donc besoin d’un modèle d’affinité que nous appel-lerons modèle de communication dans la suite de ce document. Il existe plusieurs moyens, plus ou moins efficaces, permettant de récupérer ce modèle de communication. Nous al-lons présenter tout d’abord la solution que nous avons retenue puis les autres possibilités connues ou que nous avons envisagées.

2.3.2.1 Exécution préliminaire

Une solution pour déterminer le modèle de communication d’une application parallèle consiste en une exécution préliminaire de cette application au moyen d’une version ins-trumentée du support d’exécution. Cette technique, bien que difficile à mettre en œuvre, a plusieurs avantages. Tout d’abord, elle permet d’instrumenter les communications dans les couches très bas niveau du support d’exécution. On peut de cette manière récupérer l’intégralité des communications entre processus depuis une implémentation de MPI, ce qu’un outil de trace, par exemple, ne permet pas. Deuxièmement, elle n’implique aucune modification du code de l’application. Le principal inconvénient, en revanche, est bien en-tendu le coût en temps de calcul d’une exécution préliminaire. Qui plus est, cette exécution doit être effectuée à nouveau dès lors qu’il y a un changement dans les conditions d’ex-périmentation : nouvelles données en entrée, changement de paramètres. En effet, dans la grande majorité des cas, à contexte équivalent (données en entrées, nombre de processus, paramètres), le schéma de communication ne change pas d’une exécution à l’autre. Notons que dans le cadre de nos expériences, le modèle de communication que nous avons extrait

2.3 Solution 31 des applications testées était identique d’une architecture matérielle à une autre. Cepen-dant, un taux important d’appels collectifs peut influencer le modèle de communication en fonction de l’architecture sous-jacente. En effet, la façon dont sera géré le graphe de com-munication de certaines opérations collectives (MPI_Gather par exemple) peut dépendre de la topologie matérielle ou du nombre de processus par unité de calcul.

Open MPI et MPICH étant les deux implémentations libres du standard MPI les plus populaires, nous avons travaillé sur chacune d’elle à un moyen d’extraire le modèle de communication. En moyenne, c’est une centaine de lignes de code dans les couches bas niveau de chacune de ces implémentations (le module Nemesis [15] pour MPICH et le module MCA¹ pour Open MPI) qui ont permis d’ajouter une couche d’instrumentation des communications. Cet ajout nous permet de tracer tant les communications point à point que les communications collectives, ce qui est un avantage face à des solutions de trace standards. Notons enfin que cette instrumentation affecte peu le temps d’exécution de l’application. En effet, comme le montre la figure 2.3, sur trois applications testées avec et sans instrumentation, on peut voir que l’impact de la capture des volumes de communications est estimé à moins de 20%. Pour les noyaux de calcul CG et LU, le déficit de performance avoisine 6%. Pour le noyau FT, cette différence s’établit à près de 16%.

20 40 60 80 100 120 140 160 180 200

cg.C.8 ft.C.8 lu.C.8

Temps d'éxecution (en secondes)

Impact de l'instrumentation avec une version modifiée d'OpenMPI sur trois noyaux des NAS Parallel Benchmarks (moyennes sur 3 exécutions)

Standard Instrumentée

Figure 2.3 – Évaluation de l’impact de l’instrumentation des communications avec une version modifiée de Open MPI sur des noyaux des NAS en classe C sur 8 processus. Les expériences ont été réalisées sur un nœud PlaFRIM embarquant un processeur Intel Xeon X5550.

1. MCA : Modular Component Architecture.

2.3.2.2 Autres techniques

D’autres solutions existent afin d’extraire les échanges de données entre processus.

Les outils de trace sont une approche intéressante que nous avons évaluée. EZTrace [76], développé à Inria Bordeaux, est un de ces outils. Il nécessite également une exécution préliminaire de l’application mais n’implique aucune modification du support d’exécution ni même du code de l’application. En revanche, EZTrace n’est capable d’extraire que les communications point à point explicitées dans le code. Les communications point à point résultant du graphe de communication d’une fonction collective ne peuvent pas être inter-ceptées. Les matrices 2.4(a) et 2.4(b) illustrent les différences que l’on peut observer entre un modèle de communication obtenu avec EZTrace ou avec une version instrumentée de Open MPI.

(a) Matrice de communication extraite par EZTrace.

P 0 1 2 3 4 5 6 7

(b) Matrice de communication extraite par la version instrumentée de Open MPI.

Figure 2.4 – Modèles de communication d’un gradient conjugué (NAS Parallel Benchmarks) exécuté en classe C sur 8 processus sur un nœud PlaFRIM Intel Xeon X5550 (8 cœurs, 8 Mo de cache L3 et 12 Go de RAM par 4 cœurs). Métrique : nombre de messages.

Réduire le temps de l’exécution préliminaire est un objectif pertinent. Des travaux en ce sens ont été effectués [81]. Ils consistent à exclure du code de l’application les portions de calcul de manière à n’exécuter finalement que la partie générant des communications.

Cette approche est cependant très complexe à mettre en œuvre.

Certains modèles de programmation fournissent nativement les moyens d’obtenir ces informations. Charm++ en est un exemple puisque chaque entité logicielle communicante est un objet C++ possédant des attributs de charge et de volume de communication. Cette approche sera traitée dans le Chapitre 3.

2.3 Solution 33 Enfin, un outil comme Zoltan [18], grâce à un algorithme de partitionnement de maillage est capable d’identifier les frontières entre les différentes sous-parties d’un jeu de données afin d’en déduire les échanges au cours de l’exécution. Associé à une très bonne connaissance de l’application, les valeurs obtenues peuvent être très précises.

2.3.2.3 Représentation du modèle de communication et métriques

L’exécution préliminaire de l’application grâce à un support d’exécution instrumenté nous permet de déterminer un graphe à nsommets, nétant égal au nombre de processus de l’application et m arêtes pondérées en fonction de l’affinité. Dans le cadre de l’utilisa-tion de TreeMatch, nous choisissons de stocker ce graphe sous forme d’une matrice de communication d’ordre n, telle que présentée en figure 2.5.

5 10 15

51015

Matrice de communication de ZeusMP/2 (métrique : msg)

Rang processus émetteur

Rang processus récepteur 0.0e+005.0e+061.0e+071.5e+07

Figure 2.5 –Modèle d’affinité des processus de l’application de mécanique des fluides ZeusMP/2.

Le niveau de gris donne le nombre de message échangés par paire de processus.

Nous avons vu que, pour déterminer l’affinité entre processus, nous nous basions sur leurs communications. Cependant, plusieurs métriques permettent d’estimer ces communi-cations. Nous en avons dégagé trois :

— msg : le nombre de messages échangés (au sens MPI) ;

— size : la quantité de données échangées durant l’exécution ;

— avg : la taille moyenne d’un message obtenue à partir des deux mesures précédentes.

Nous avons également travaillé sur une autre métrique basée sur le temps passé dans les communications. Les valeurs ont été récupérées grâce au logiciel EZTrace, qui permet de mesurer avec précision les temps de communication point à point. Cette métrique s’est

avérée peu efficace, même si elle a permis de mettre en lumière des spécificités de l’architec-ture cible (AMD Opteron 6272, Bulldozer) qui ne sont pas documentées par le constructeur (voir chapitre 1).

2.4 Implémentation

Dans cette section, nous allons présenter notre algorithme de placement de processus TreeMatch. Dans un premier temps, nous détaillerons l’algorithme général puis nous proposerons quelques optimisations.