FR 3091764 A1 20200717 FR 1873784 A 20181221 Description Titre de l'invention : Modification des caractéristiques des systèmes d'interconnexion des réseaux rapides : Simulation et Application à la prédiction de la performance d'applications parallèles [0001] 1) Nom du ou des rédacteurs Stephan .laure, Nourredinc Taguelmint [0002] 2) Titre proposé Modification des caractéristiques des systèmes d'interconnexion des réseaux rapides : Simulation et Application à la prédiction de la performance d'applications parallèles. [0003] 3) Domaine technique [0004] Le présent travail a été mis en oeuvre dans le domaine des études de Benchmark d'applications parallèles dans le contexte du Calcul Haute Performance « HPC ». Un intérêt particulier est porté sur l'analyse et la prédiction de la performance des applications sur des machines de calcul de caractéristiques différentes. [0005] 4) Problème technique posé [0006] Le Calcul Haute Performance touche de plus en plus de domaines scientifiques tels que l'environnement, la météo et la physique. Dans ces domaines, le besoin de résoudre des problèmes physiques toujours plus complexes, que ce soit au niveau des modèles ou de leur résolution, entraine une forte demande de capacité de calcul. [0007] Ces « machines » sont constitués d'un ensemble de serveurs de calcul appelés « noeuds de calcul ». Ces derniers sont connectés via un réseau rapide appelé « interconnect », ou « réseau Infiniband ». A noter qu'Infiniband désigne en réalité une des différentes technologies permettant d'interconnecter les noeuds de calculs (il existe également une technologie d'Intel nommée OnmiPath). Nous nommerons ci-après un « cluster de calcul » ou « machine de calcul » l'ensemble constitué de (voir figure 1) : noeud de calcul réseau d'interconnexion systèmes de stockage [0008] [fig.l] Architecture générale d'un "Cluster" de calcul. [0009] [fig.2] illustration des communications entre deux processus. [0010] [fig.3] Possibilités d'implémentation de la solution. [0011] L'une des grandes difficultés de la conception d'un « cluster de calcul » est son di- mensionnement. En effet, dans le cadre d'un appel d'offre, par exemple, celui-ci (Commentaire [J511 : quelque chose est en trop ici) est généralement accompagné d'un ensemble d'applications scientifiques, donnant suite à une compagne d'analyse, de test et de projection des performances. L'objectif final de cette compagne est de dimensionner le « cluster de calcul ». Ceci se fait en deux étapes : 2 Maximiser la performance des applications scientifiques (codes de calculs) Optimiser le prix de la machine proposée. [0012] L'un des problèmes récurrents des analyses de la performance des applications scien- tifiques est la non disponibilité de la machine de calcul cible, c'est-à-dire, celle qui sera proposée au porteur de l'appel d'offre. Ceci s'explique essentiellement par deux raisons. D'une part, avec la variété des architectures et des machines de calcul, il est impossible d'avoir à sa disposition l'ensemble des modèles existants. D'autre part, la machine cible peut simplement être en cours de développement et n'est mise sur le marché qu'après des mois voire des années à partir de la date de la proposition de l'offre. Les caractéristiques principales de ces futures machines sont néanmoins communiquées par leurs constructeurs en amont. On a alors recours à la simulation des machines cibles à partir de machines de caractéristiques matérielles différentes, appelées « machines de Benchmark ». [0013] Ces simulations sont menées par les équipes en charge de la performance applicativc, appelées équipes de Benchmark, qui utilisent des modèles, plus au moins complexes, reposant essentiellement sur l'analyse des « sensibilités » (Commentaire [JS2] : peut etre faudrait il expliciter ce terme c'est une sorte de dérivée partielle) de la performance des applications parallèles aux différentes caractéristiques d'un « cluster de calcul ». Parmi ces caractéristiques principales analysées, nous pouvons citer : - la fréquence du processeur CPU en GHz, la bande passante de la mémoire vive ou bande passante mémoire en Go/s, la bande passante du système d'interconnexion (réseau rapide, Infiniband) en Go/s. [0014] La fréquence, exprimée généralement en GHz, désigne le nombre d'opérations ef- fectuées en une seconde par le processeur CPU (Central processing unit en anglais). A titre d'exemple, un processeur cadencé à 3 GHz effectue 3 milliards d'opérations par seconde. [0015] La bande passante mémoire, exprimé généralement en Go/s, désigne quant à elle le nombre d'octet pouvant transiter entre le processeur CPU et sa mémoire. [0016] La bande passante du système d'interconnexion, exprimée elle aussi en Go/s, renseigne le nombre d'octet que peut transférer un réseau de connexion entre les différends noeuds de calcul. [0017] Les ingénieurs de Benchmark utilisent ces caractéristiques comme «paramètres de sensibilité » des applications étudiées. Ces paramètres sont obtenus, pour une application donnée, en l'exécutant sous différentes conditions matérielles. [0018] Par exemple, l'analyse de la sensibilité à la fréquence du processeur est simple, il est tout à fait possible de faire varier la valeur de la fréquence du processeur via des paramètres systèmes. Cette modification de la fréquence a l'intérêt de ne pas engendrer 3 d'effets non linéaires importants sur les autres paramètres de sensibilité. Ces aspects non linéaires sont très importants lors des études de performance comme nous le verrons plus bas. [0019] En revanche il n'est pas simple de faire varier la bande passante mémoire ou la bande passante du réseau d'interconnexion. En effet, pour faire varier la bande passante mémoire il faut généralement modifier la configuration matérielle du cluster de calcul. Ceci implique des arrêts fréquents de la machine et un temps d'intervention conséquent (changement des barrettes mémoires, par exemple). De même, la modification de la bande passante du système d'interconnexion requiert au moins de reconfigurer l'ensemble des commutateurs réseaux (switchs en anglais), ceci nécessite de redémarrer une portion importante de la machine. Ainsi, pour des raisons pratiques et de temps, ce type de modifications n'est pas réalisable. De plus, les machines de calculs sont partagées entre plusieurs utilisateurs sur différents projets ce qui rend encore moins possible ce genres d'interventions. [0020] De cc fait, il est nécessaire d'avoir recours à la simulation des caractéristiques de la machine de calcul qu'à la modification réelle (au niveau matériel) de celles-ci. [0021] 5) Les solutions connues [0022] Pour analyser la sensibilité à la bande passante du système d'interconnexion, les in- génieurs Benchmark utilisent plusieurs méthodes indirectes : [0023] - Le profilage et l'analyse de l'application, notamment par l'utilisation de la couche de communication MPI (Message Passing Interface). Cette méthode permet de connaitre le temps passé dans la partie « communication » de l'application. Cependant, ce temps n'est pas uniquement fonction de la bande passante du système d'interconnexion : ce temps prend également en compte les attentes de synchronisation entre les différents noeuds de calculs ainsi que les latences des communications, comme illustré sur la figure 2. [0024] Ainsi, il est tout à fait possible de mesurer 30% du temps d'une application dans la partie « MPI » mais que ce temps ne soit en aucun cas exclusivement sensible à la bande passante du système d'interconnexion (en d'autres termes ce temps ne variera pas en doublant la bande passante du réseau d'interconnexion). [0025] - Le placement des applications lors de leur exécution. Une technique consiste à utiliser le double du nombre de noeuds qu'en temps normal tout en utilisant que la moitié des coeurs de calcul disponibles. On s'assure néanmoins que, pour chaque noeud de calcul, seul les coeurs d'un seul processeur sont utilisés (il existe généralement deux processeurs par noeud). Ceci permet de doubler la bande passante du réseau d'interconnexion disponible par processus. En effet, dans ce cas de figure, nous utilisons 2 fois moins de processus par noeud de calcul et par conséquent par carte réseau. La bande passante mémoire et les capacités de calcul sont quant à elles maintenues constantes. Cependant, cette modification impacte également le parcours des messages échangés. En effet, doubler le nombre de noeuds conduit à : - la diminution de la proportion des communications intra-noeud, c'est-à-dire, celles qui s'opèrent au sein d'un même noeud et s'effectuant ainsi directement dans la mémoire du noeud (raison pour laquelle ces communications sont plus rapides que les communications inter-noeud). l'augmentation des latences : en effet, il est possible qu'en utilisant plus de noeuds on peut être amené à traverser plus de switchs pour pouvoir communiquer entre les différents processus de l'application. Sachant que plus les messages échangés traversent des switch plus leur latence augmente (traverser un switch augmente la latence des communications). La diminution de la bande passante. Sur certaines topologies réseau on peut observer une diminution de la bande passante. En effet, la bande passante entre les switchs peut-être faible que la bande passante au sein d'un switch. Ceci est fortement dépendant du nombre de câbles placés entre les switchs, on parle alors du « facteur de pruning ». Il est courant d'avoir des facteurs de prunings qui peuvent diviser par 2 ou 3 la bande passante lorsque l'on communique entre deux noeuds sur des switchs différents. [0026] Ces différentes méthodes permettant de simuler la bande passante d'un réseau d'interconnexion engendrent des effets transverses difficilement appréhendables par les modèles de projections usuels. [0027] 6) Présentation de l'invention [0028] La solution proposée dans le présent document consiste à simuler, toutes choses égales par ailleurs, une bande passante du système d'interconnexion plus faible en augmentant la taille des messages transmis par la couche de communication MPI. En effet, nous souhaitons faire en sorte que la modification de la couche MPI simule une bande passante plus faible tout en maintenant à la fois la latence et les caractéristiques intrinsèques au schéma de communication de l'application (la façon dont l'application est synchronisée). Pour cela nous proposons d'augmenter artificiellement la taille des messages transmis par la couche MPI, cette modification de la taille des messages doit être effectuée de façon totalement transparente pour l'application suivant la méthodologie suivante : [0029] - Lorsque le processus X de l'application parallèle veut transférer 1000 octets au processus Y qui en attend en retour 1000 octets du processus X, [0030] - la couche MPI modifiée par notre solution transmettra alors 2000 octets (Commentaire [TN3] : Est-ce qu'il ne serait pas préférable de diviser par deux la taille des messages pour simuler une bande passante double. Cela permet de remplacer un scatter à 128 noeuds par un normal 'modifié' à 64 noeuds) au processus Y, mais ne fera voir que 1000 octets à l'application, tout se passera comme si la bande passante du réseau d'interconnexion avait été divisée par deux. [0031] Il est possible d' implémenter cette invention à différents niveaux : Sous forme d'un « wrapper MPI », c'est une librairie informatique qui encapsule le service MPI en exposant la même interface mais dans laquelle on peut intercepter les appels des primitives MPI depuis l'application et en modifier leur fonctionnement. Cependant l'implémentation à cet endroit risquerait de nécessiter des copies mémoire dans des tampons intermédiaires, ce qui pourrait fausser les résultats. Cependant, il est possible de corriger le résultat en mesurant le temps passé dans ces copies. Sous forme d'un composant d'une implémentation MPI. MPI est un standard dans lequel il existe plusieurs implémentations (TnteIMPT, OpenMPT, MPICH, etc...). Chaque implémentation traduit les primitives du standard MPI en des appels à des librairies d' interfaçage qui vont dialoguer avec les pilotes du système d' interconnexion (sous OpenMPI on parle de BTL ou Byte Transfer Layer, sous inteIMPI on peut citer DAPL). Ces librairies d' interfaçage sont, de notre point de vue, un meilleur endroit pour implémenter cette modification, car l'implémentation pourrait se faire sans copies intermédiaires. 6