Performances

Nous donnons sur la figure II.4 l'évolution des performances parallèle en fonction du nombre de processeurs et de la taille de la grille considérée. On peut voir que la scalabilité du programme est bonne jusqu'au nombre de processeurs que nous avons pu tester; en effet, le coût d'exécution total augmente légèrement moins vite que $N_{PE}\log_2(N_{PE})$ où $N_{PE}$ est le nombre de processeurs. Il y a une anomalie dans le cas de 8 processeurs et 48 points de grille ; les communications sont sans doute particulièrement optimales pour cette combinaison-là de paramètres.

On constate que la parallélisation est moins efficace pour de petites grilles que pour de plus grandes ; la raison en est sans doute à chercher dans le rapport des latences ou des vitesses de transmission des messages à la vitesse de calcul, qui est défavorable pour de petits messages ; de même, lorsque la taille de la grille s'approche du maximum faisable ($64^3$ environ) par suite de la mémoire par nud limitée du T3E à notre disposition, l'efficacité diminue quelque peu sans doute parce que les messages deviennent trop grands ou parce que la taille de la mémoire cache devient insuffisante pour couvrir les besoins du calcul. La taille optimale de grille est donc entre 40 et 60 points de côté, ce qui est tout à fait celle pour laquelle nous avons visé l'efficacité maximale. D'autre part, on voit que pour un nombre de processeurs moyen (disons entre 8 et 20) le gaspillage de temps total dû à la parallélisation n'est que de 2 environ, ce qui est un très bon chiffre par rapport à la facilité d'utilisation qui résulte de l'accélération très importante des codes. La figure II.4 donne une tendance qui fait espérer que cette conclusion restera vraie pour des grilles plus grandes ou un nombre de processeurs beaucoup plus élevé.

On peut d'autre part retenir la quasi-constance de la durée de la propagation en fonction du nombre de PE, l'accélération de la résolution de $V_{KS}(\vec r,\rho(\vec r))$ compensant le coût des communications. La parallélisation du calcul de $V_{KS}(\vec r,\rho(\vec r))$ a ainsi permis dans le "cas test" d'abaisser la durée de chaque itération temporelle à 1 seconde environ, vitesse sans commune mesure avec celle obtenue sur station de travail. Les performances en termes de mégaflops données par le programme pad sur T3E sont acceptables, de l'ordre de 45 Mflops par processeur. Il est à noter que ces performances ont baissé au fur et à mesure de l'avancée de parallélisation du code, des calculs étant remplacés par des communications, au détriment des Mflops mais au bénéfice de la vitesse d'ensemble !

Il reste cependant (du moins selon << Apprentice >>) quelque 40 % de vitesse à gagner par suite d'inefficacité d'accès au cache. Nous avons essayé quelques-unes des recettes d'optimisation mono-processeur telles que rupture de l'alignement dans le cache, déroulage de boucles, et autres, mais il reste sans doute beaucoup de travail de ce point de vue là.

En conclusion de cette partie, on constate que les efforts de parallélisation ont permis d'abaisser une simulation sur un intervalle de temps intéressant à une durée qui permet d'obtenir des résultats physiques en moins d'une nuit, contre quelques semaines sur station de travail. Sur ces machines, le calcul reste possible, mais sa durée quasi-prohibitive rend presque impossible tout raisonnement physique sur les résultats, avec vérification immédiate. Il reste certainement beaucoup de possibilités d'amélioration des implantations numériques pour obtenir un programme faisant un usage optimal des ressources, mais, pour le moment, le résultat obtenu ici nous semble tout à fait satisfaisant.

Figure: Performances sur T3E du programme parallèle pour une itération dynamique (rapport du temps d'exécution monoprocesseur sur le temps total consommé dans le programme), en fonction du nombre de processeurs (échelle logarithmique) et de la taille de la grille cubique employée. Ce nombre est toujours inférieur à 1, par suite des communications. Certains points n'ont pu être calculés par suite de manque de mémoire par nud (par exemple pour la grille de 64$^3$ points). Pour la même raison, les résultats monoprocesseurs ont été extrapolés au delà de 8 fonctions d'onde traitées (rappelons qu'il y a une fonction d'onde par nud dans la version parallèle). On a choisi des nombres de processeurs qui divisaient exactement le nombre de points de grille pour que la charge soit également répartie.