Cette section est consacrée à décrire les résultats obtenus sur “Babel”. Afin de simplifier cette pré- sentation, l’influence du choix du couple (P1,P2) est omise. On retiendra que maximiser P1donne de meilleurs résultats, confirmant les préconisations des développeurs de P3dfft (Donzis et al. 2008), le gain en performance restant modéré (5 à 10% au mieux) . De plus, le choix d’un maillage en adé- quation avec un problème physique peut conditionner le choix du couple (P1,P2) comme indiqué au paragraphe 3.3.3.
3.5.1
Cas tests et conditions de test
Le code faisant appel à de nombreuses bibliothèques pré-compilées sur la machine, les paramètres de compilation (optimisation -On) n’ont que très peu d’influence. Les tests sont donc effectués avec un niveau d’optimisation classique -O3. La performance du code est mesurée à partir de tests de scalabilité “forte” (voir 3.1.3). On effectue diverses mesures du temps d’exécution d’un même problème en faisant varier le nombre de processeurs utilisés. Les étapes “rares” telle que l’écriture d’informations relatives au calcul ou la prise de statistiques, sont exclues de ces tests. Ces étapes ont une influence négligeable sur les performances du code puisqu’elles ne dépassent pas 1% du temps d’exécution total. Le calcul relatif à l’adaptation du pas de temps selon le critère CFL est également exclu des tests. Cette étape est désactivée dès que l’on peut établir un pas de temps uniforme. Au regard des échelles de temps caractéristiques du problème, on peut définir une période Tc durant laquelle l’écoulement évolue significativement. Au-delà de cette période, le pas de temps est imposé de manière uniforme :
∆tuni =min{∆ti} ti∈ [0, Tc] (3.5)
La fonction gettimeofday est utilisée pour chronométrer les différentes sections du code. Associée à des barrières MPI, pour synchroniser tous les cœurs, cette fonction possède une précision de l’ordre de la microseconde. Cette précision n’est pas affectée par la “latence” des appels de type MPI_Barrier. La latence d’un appel système est définie par la durée maximale de réalisation effective de cette fonction. Pour les fonctions MPI_Barrier la latence est de l’ordre de la micro-seconde sur “Babel” (données constructeur). Un test de quelque minutes est donc suffisant pour juger des capacités du code de calcul. La dernière partie, sur les tests d’écriture, vise à estimer le temps nécessaire à la sauvegarde des fichiers. Ce test est extrêmement dépendant de l’utilisation du disque par les autres utilisateurs et n’est donc donné qu’à titre d’indication.
3.5.2
Performance obtenues
Les temps d’exécution des différentes parties de l’algorithme global sont soumis à l’influence de deux paramètres essentiels :
1. La taille du maillage dans la direction normale, qui conditionne la taille des matrices dans la résolution des systèmes linéaires.
2. La taille du maillage dans les deux premières directions, qui conditionne la taille des FFT, mais surtout la taille des échanges de données lors des transpositions.
3.5. Exécutions de cas tests sur Babel 61 288×288×352 0.5K cœurs 1024×1024×1280 8K cœurs Calcul du forcage FFT Diff. Finies divers
Fig. 3.8 – Temps d’exécution des différentes parties du code pour deux types de maillages sur “babel”
A titre d’illustration, la figure 3.8 présente les temps d’exécution obtenus dans les étapes principales de l’algorithme. Les deux cas ne sont pas comparables et ne permettent pas de tirer des conclusions générales puisque la taille du maillage ainsi que le nombre de cœurs sont différents. Ils permettent néanmoins d’observer la proportion importante occupée par deux sections du code : le calcul des FFT et la résolution des systèmes linéaires monopolisent ainsi plus de 90% du temps de calcul. La dernière partie coûteuse (6 à 8%) concerne le calcul des termes de forçage dont l’algorithme est exposé dans le chapitre suivant.
Tests de scalabilité forte.
On effectue plusieurs tests, où le choix des maillages est conditionné par les contraintes suivantes : – certains cas nécessitent un nombre minimal de cœurs pour disposer d’une capacité mémoire
totale suffisante ;
– il n’existe pas toujours de compatibilité entre le maillage choisi et le nombre de processeurs (Cf. paragraphe 3.3.3).
Cas test A B1 B2 B3
Nxy 512 1024 896 1024
Nz 512 1024 1280 1280
Tab. 3.2 – Cas tests utilisés pour évaluer la scalabilité du code
On fait donc le choix des quatre maillages présentés dans le tableau 3.5.2. Le cas A, de taille modeste, est compatible avec une utilisation allant de 256 à 16K processeurs. Les maillages relatifs aux cas B présentent un nombre de total de points comparable. Il permettent ainsi d’évaluer l’influence du découplage entre Nxet Nz.
Les étapes pénalisantes pour le calcul parallèle sont les transpositions du domaine, qui impliquent essentiellement des échanges inter-processeurs. Ces transpositions ne peuvent bénéficier d’un speed-up
parfait. En effet, si la multiplication du nombre de processeurs diminue la taille des échanges et donne accès à un plus gros réseau d’interconnexions, le volume total de données échangées reste constant. En cas d’encombrement sur le réseau, dû à un très grand nombre de messages ou à une saturation de la bande passante, on peut s’attendre à une baisse des performances. Le reste du calcul induit peu de communications parallèles et son efficacité propre doit être proche de l’unité.
On isole donc le calcul des FFT (qui inclut les transpositions de domaines) afin de pouvoir mesurer l’impact de ces transpositions sur le “scaling” global de l’application. Les résultats, présentés sur la figure 3.9, démontrent les bonnes performances du code :
1. Les résultats concernant le calcul des FFT illustrent la difficulté de paralléliser des transpositions. On observe cependant une diminution du temps d’exécution jusqu’à 16K cœurs. Au-delà, la multiplication du nombre de processeurs semble contre-productive. Il faut cependant modérer les conclusions que l’on pourrait tirer de ce résultat : il est en effet difficile d’effectuer ce test sur un nombre aussi élevé de processeurs du fait des disponibilités de la machine. Un unique test a donc été réalisé pour le cas B1 sur 32K cœurs.
2. Les temps d’exécution globaux décroissent de manière quasi-linéaire pour une efficacité globale de l’ordre de l’unité. On démontre ici que la section du code consacrée à la résolution de systèmes linéaires se parallélise de manière idéale. Le temps de calcul consacré à cette section restant prépondérant devant le temps nécessaire aux transpositions (Cf. figure 3.8), l’efficacité parallèle globale du code est très peu affectée par la chute d’efficacité relevée pour la section consacrée au calcul des FFT. 1 10 100 1000 0.5K 1K 2K 4K 8K 16K 32K T emps d’execution en s Nombre de coeurs A B1 B2 B3 E=1 0 1 10 100 0.5K 1K 2K 4K 8K 16K 32K T emps d’execution en s Nombre de coeurs A B1 B2 B3 E=1
Fig. 3.9 – Test de scalabilité forte sur plusieurs types de maillages : temps d’exécution global (gauche), calcul des FFT (droite)
Tests d’écriture
L’écriture de fichiers est une étape cruciale pour la performance d’une application. Quelques minutes passées à écrire des fichiers, sont autant de temps de calcul perdu. Ainsi 3 minutes sur 16k processeurs seront facturées 50h par le centre de calcul. Il faut donc exploiter au mieux la bande passante totale
3.5. Exécutions de cas tests sur Babel 63
du système, ici de 12.7 Go/s. Plusieurs tests ont été effectués afin d’obtenir une indépendance vis-à- vis de l’utilisation de la bande passante par d’autres utilisateurs. Le tableau 3.3 résume les résultats obtenus. On observe que l’utilisation de Parallel-NetCDF est très performante et permet de profiter de près du quart de la bande passante totale lorsque l’écriture concerne des fichiers dont la taille totale est de l’ordre de la centaine de Go. Dans ce cas, des temps inférieurs à la minute sont nécessaires pour sauvegarder les champs calculés. Pour limiter les pertes de données en cas de problèmes, une sauvegarde horaire des données est imposée. Celle-ci est donc peu pénalisante puisqu’elle augmente le temps d’exécution total d’environ 1%.
P1 P2 Fichiers Taille totale Taux de Transfert(Max)
288×288×352 16 32 32 1.8 Go 390 Mo/s
1024×1024×1280 64 128 64 82Go 3.6 Go/s
Tab. 3.3 – Taux de transfert obtenu sur “babel” pour deux cas test.
Synthèse du chapitre
Les machines mises à disposition par l’IDRIS, le centre de calcul du CNRS, donnent la possibilité de programmer des applications massivement parallèles, du niveau des standards internationaux dans ce domaine. La construction de ce type d’applications nécessite de prendre en compte les contraintes imposées par l’utilisation de milliers de processeurs qui s’ajoutent à celles rencontrées lors du dé- veloppement d’applications parallèles classiques. Dans notre cas, deux difficultés majeures ont été identifiées :
– La parallélisation du calcul d’une FFT bidimensionnelle sur un domaine de taille N3qui se distribue de manière classique sur un nombre de processeurs inférieur à N. Cette limite, non acceptable, compte tenu des tailles de problème envisagées et du nombre de processeurs mobilisables est levée grâce à une décomposition bidirectionnelle du domaine et l’utilisation d’une bibliothèque appropriée P3dfft.
– La gestion des fichiers d’entrée/sortie ne peut plus se gérer de manière indépendante par chaque processeur comme ça peut-être le cas sur une application utilisant une dizaine de processeurs. L’uti- lisation des directives MPI−IO par l’intermédiaire de la bibliothèque Parallel-Netcdf permet de découpler le nombre de processeurs utilisés du nombre de fichiers écrits en sortie. Elle permet égale- ment la réduction considérable du nombre de fichiers écrits en sortie, ce qui facilite le post-traitement et permet de satisfaire aux contraintes imposées par les systèmes de calculs.
En incorporant ces modifications, l’application originellement développée sur des machines de taille modeste (≤32 processeurs) démontre d’excellente performances de scalabilité sur le super-calculateur Babel. Elle permet d’utiliser efficacement jusqu’à 32K processeurs et offre la possibilité de résoudre des problèmes de taille considérable. On peut ainsi envisager des simulations directes dont le maillage comprend plus d’un milliard de points (10243, 20483 notamment) avec ce code de calcul. De plus la décomposition bidirectionnelle adoptée permet de découpler le nombre de points de maillage utilisé
dans les différentes directions, ce que n’autorisait pas la décomposition classique unidirectionnelle. On peut ainsi optimiser les calculs la géométrie impose de différencier la taille du maillage dans les différentes directions du domaine physique, comme c’est le cas par exemple dans l’étude de jets turbulents.