of 28

Portage de StarPU sur la bibliothèque de communication NewMadeleine

0 views
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
Portage de StarPU sur la bibliothèque de communication NewMadeleine Guillaume Beauchamp To cite this version: Guillaume Beauchamp. Portage de StarPU sur la bibliothèque de communication NewMadeleine. Calcul
Transcript
Portage de StarPU sur la bibliothèque de communication NewMadeleine Guillaume Beauchamp To cite this version: Guillaume Beauchamp. Portage de StarPU sur la bibliothèque de communication NewMadeleine. Calcul parallèle, distribué et partagé [cs.dc] hal HAL Id: hal Submitted on 14 Sep 2017 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d enseignement et de recherche français ou étrangers, des laboratoires publics ou privés. Me moire de stage : Portage de StarPU sur la bibliothe que de communication NewMadeleine Beauchamp Guillaume Universite de Bordeaux Encadre par Alexandre Denis dans l e quipe Inria TADaaM. 13 septembre 2017 Table des matières 1 Introduction Contexte StarPU MPI StarpuMPI NewMadeleine Objectifs Portage de StarPU sur NewMadeleine Travail effectué Portage sur Newmadeleine Ajout d un nouveau module compilant avec MadMPI Portage du module StarPU-nmad sur New- Madeleine Performances de StarPU-nmad Latence Recouvrement Scalabilité en nombre de requêtes Performance Cholesky Un autre ordonnanceur StarPU : LWS Flush après envoi Granularité Conclusion Remerciements Bibliographie 1 Introduction Dans le cadre du calcul haute performance, il est généralement préférable d utiliser la totalité des cœurs disponible sur une ou des machines, afin d augmenter la puissance de calcul totale. Les noeuds modernes ont également fréquemment une architecture hétérogène ayant de multiples cœurs ainsi que des accélérateurs(gpu,etc). Il serait ainsi souhaitable qu un calcul soit répartit entre les accélérateurs et les cœurs mais cela implique de réécrire des parts du programme parallélisable dans différents langages, certains périphériques ayant des contraintes particulière, ainsi que faire des transferts de données entres ces périphériques et les cœurs. De plus ces accélérateurs et les cœurs n ont généralement pas la même efficacité sur les différentes parties d un programme, ce qui rend difficile d effectuer une répartition optimale du travail. Enfin de nombreuses librairies, comme le solveur Chameleon développé à l Inria, ne peuvent pas être développées a destination d une architecture spécifique, et doivent donc adapter la répartition des données aux ressources disponibles. Un ordonnanceur de tache comme StarPU [1], utilisé par Chameleon[2], permet de simplifier le développement de tels programmes parallèles, en gérant la répartition du calcul et d effectuer les communication nécessaires, les applications devant seulement découper leur applications en taches indiquant les données en entrées et en sorties. L ordonnanceur organise ensuite les taches de manière efficace et en effectue les transferts de données nécessaires à leur exécution. Bien qu il tente de réduire leur nombre et de les recouvrir(exécuter un calcul simultanément a un transfert de données au lieu de devoir attendre la fin du transfert pour reprendre le calcul), la durée et l efficacité du recouvrement de ces transferts ont une influence importante sur le temps de calcul. StarPU possède une interface StarPU-MPI permettant d effectuer des communications nœuds a nœuds en se basant sur la norme de librairie de communication MPI. L implémentation de StarPU- MPI actuelle l utilise pour faire des transferts de données entre plusieurs machines. Cependant bien qu étant les librairies de communication les plus utilisées leur modèle envoi/réception n est pas vraiment adapté aux besoins de StarPU, n assurant pas la progression des communications hors des appels MPI. De plus l implémentation actuelle est peu efficace avec un grand nombre de requêtes. La librairie NewMadeleine qui permet d utiliser un modèle basé sur des appels distants de procédures(rpc) en plus du modèle envoi/réception pourrait permettre de résoudre ces problèmes, garantissant sans appels de l application la progression des communi- 2 cation. Elle fournit de plus une interface MadMPI qui pourrait, dans un premier temps, faciliter la transition. Nous avons donc développé une nouvelle implémentation de StarPU-MPI qui serra appelée StarPU-NMad basant ses communications inter-nœuds d abord sur Mad-MPI puis dans un second temps sur NewMadeleine. Nous présenterons dans un premier temps, StarPU, MPI et New- Madeleine. Puis nous décrirons notre port d une implémentation basée sur MPI de StarPU-MPI a une implémentations basée sur NewMadeleine. Enfin nous étudierons les impacts de ce port sur la performance de StarPU. 3 2 Contexte 2.1 StarPU La librairie StarPU [3] [1] est une librairie de calcul haute performance développée à l INRIA par l équipe STORM. Elle permet de paralléliser sur un seul nœud (mémoire partagée) un programme décrit a l aide de taches. Elle est notablement utile pour paralléliser des programmes ayant des dépendances de données complexes ou sur un support hétérogène (accélérateurs/gpu/cœurs). Les taches sont définies par une ou plusieurs implémentations destinées à un/des supports d exécutions, ainsi qu une liste de paramètres ayant différent mode d accès (lecture, écriture, lectureécriture). StarPU détecte les supports d exécutions disponibles puis y distribue les taches, de manière à assurer la cohérence de données. Ainsi pour une donnée, l ordre d exécution entre deux écriture et entre une écriture et une lecture soit le même que lors de l ajout de la tache. L ordre entre lectures n est pas important, et plusieurs taches exécutées simultanément peuvent avoir une même donnée en lecture. StarPU effectuera les transferts de données nécessaires. StarPU tente de faire les transferts de données dès qu elles sont disponibles pour réduire le coût des communications. 2.2 MPI MPI est une interface de communication par passage de messages. Elle est le moyen le plus utilisé pour paralléliser des application sur plusieurs nœuds (mémoire distribuée). Un communicateur représente un groupe de processus MPI (généralement sur des nœuds différents) avec lesquels on peut communiquer. Un outil (mpirun/mpiexec) est fournit par les implémentations d MPI qui permet de lancer des processus exécutant un même programme sur différents nœuds. Ces différentes instances du programmes ont un communicateur en commun qui leur permet de connaître le nombre d instance et leur rang parmi elles. Pour effectuer une communication l émetteur du message doit poster un send, et le récepteur un receive. Les send/receive ont pour paramètre le communicateur utilisé, un tag pour distinguer différents message, et le rang de la source/destination. Les paramètres ANY TAG, ANY SOURCE peuvent être utilisé lors d une réception pour recevoir un message ayant n importe quel tag ou venant de n importe quel source. Le receveur fera correspondre les messages 4 Figure 1 Progression caractéristiques de nombreux protocoles MPI reçus selon ces paramètres. Selon la taille du message il peut être envoyé de deux manières : Eager pour les petits messages. Quand l envoi est posté le message est directement envoyé au receveur. Le message y est stocké par le receveur jusqu à ce qu il post un receive qui copiera alors le message déjà reçu dans un buffer. Ce protocole réduit la latence mais utilise plus de mémoire et augmente le nombre de copie. Rendez-Vous pour les plus gros message. L émetteur demande au receveur via eager si il est près a recevoir le message. Une fois le receive posté, une réponse est envoyé, puis l émetteur envoie le message en une ou plusieurs parties selon sa taille. MPI fournit également des fonctions non-bloquantes isend/ireceive, qui sont souvent utilisées afin de pouvoir recouvrir les communications par le calcul. Cependant le standard MPI ne garantit pas la progression des communications MPI non bloquantes hors des appels de la librairie. Selon l implémentation de MPI utilisée, il peut donc être nécessaire de lui faire des appels périodiquement pour faire progresser les communications (Fig 2). 2.3 StarpuMPI Le module StarpuMPI [4] permet d utiliser StarPU sur plusieurs nœuds (en mémoire distribuée). Chaque nœuds exécute une instance de Starpu, les communications inter-nœuds sont effectuées par MPI et les communications intra-nœud sont inchangées. Il permet 5 de communiquer implicitement les données nécessaires a l exécution des taches sur plusieurs nœuds, de faire des communications explicites a l aide d un interface send/receive propre a StarPU-MPI qui va planifier une communication dès que la donnée est disponible ainsi que de faire des MPI Send/Receive directement sur des données. Chaque donnée a un tag unique et distinct ainsi qu un nœud propriétaire qui l envoie aux nœuds la nécessitant pour exécuter une tache. Tous les nœuds connaissent le diagramme de tache et savent donc quand les autres nœuds ont besoin de quelles données. Les données ont un nœud propriétaire qui les envoie aux autres nœuds si ils ont besoin d y accéder. Les taches sont réparties de manière a minimiser les écritures sur des données qui ne sont pas propriétaires du nœud. Le communications se font avec des communication MPI non-bloquantes isend/ireceive, selon le protocole suivant : Lors d une lecture, si la donnée n a pas déjà été transmise au nœud exécutant la tache, elle lui est envoyé par son nœud propriétaire. Elle est conservée jusqu à ce que le nœud receveur voit qu un écriture doit avoir lieu sur cette donnée. Lors d une écriture, la donnée est de même reçu si besoin par le nœud exécutant la tache puis renvoyée modifié au nœud propriétaire. Tous les autres nœuds voyant qu une écriture est prévue dans leur diagramme de tache invalident la donnée. Pour faire progresser les communications MPI, il est nécessaire de faire des appels fréquents a la librairie. Ces appels sont effectués par un thread de communication propre a chaque nœud. Lorsqu une tache souhaite débuter une communication, elle empile une requête StarpuMPI. Le thread de communication propre a chaque nœuds débute toutes les communications MPI empilé, puis teste si elles terminent de manière active. Cela garantit la progression et que MPI n est appelé que depuis un seul thread (la mojorité des implémentations de MPI ne supportant pas, ou pas efficacement de faire de communications depuis plusieurs thread.). Cette implémentation a deux problèmes majeurs : un cœur est effectivement sacrifié pour effectuer cette attente active, tant que des communications sont en attente. Le thread doit parcourir et tester toutes les requêtes en attente pour trouver qu une communication s est terminée. Cela cause une augmentation linéaire de la latence si un grand nombre de requêtes sont en attente. Dans la dernière version de StarPU (1.2/1.3), des optimisations spécifiques à certaines implémentations MPI (en particulier OpenMPI) ont été ajoutées dans le module. Par exemple, les communications 6 MPI n utilisent qu un seul tag et le tag des données StarPU est représenté par un champ supplémentaire de la donnée MPI, certaines implémentation d MPI ayant un surcoût pour un nombre élevé de tags. 2.4 NewMadeleine NewMadeleine [5] est une librairie de communication développée à l INRIA dans l équipe TADaaM similaire mais plus bas niveau à MPI dont elle a une implémentation MadMPI. NewMadeleine est capable de fusionner des communications de petite taille selon leur destination. Bien que pouvant augmenter la latence si les communications ne sont pas attendues, envoyer des communications de plus grosse taille permet d atteindre un débit plus élevé. Elle maintient cependant une latence comparable a MPI. Elle fournit, en plus d une interface send/receive, une interface Remote Procedure Call. Le receveur enregistre un service sur un tag, un masque et une session (équivalent du communicateur MPI). Deux fonctions sont associées au service : Le handler, lit l entête du message et alloue l emplacement où recevoir le message (cette interface peut donc envoyer directement des messages de taille variable contrairement au send/- receive de MPI/nmad) Le finaliser, appelé quand le message a été reçu Ces fonctions sont appelées lors de la réception des données par NewMadeleine et ne doivent pas faire d appels coûteux ou bloquants, la progression des communications ne pouvant reprendre qu après leur terminaison. Elle fournit une implémentation de MPI, MadMPI, mais qui limitée par l interface MPI ne permet pas d utiliser toutes les fonctionnalités (RPC) de NewMadeleine. La fusion des messages courts ne nécessitant pas de changements particuliers de l interface, elle reste possible. Les communications progressent grâce à la librairie PIOMan [6].. Trois mécanismes permettent de fait progresser les communications : idle : un thread a faible priorité pouvant être exécute fréquemment (appelé au plus tous les 5µs). Ayant une priorité plus faible que le calcul il s exécute sur les cœurs inactifs. timer : un thread a priorité normale garantit la progression (appelé tous les 2ms), mais pas suffisant pour avoir une latence acceptable pour de nombreuses applications. explicit polling : Lors d un test/wait, le thread faisant l appel fait progresser les communications. 7 3 Objectifs 3.1 Portage de StarPU sur NewMadeleine Les librairies MPI classiques ne correspondent pas aux besoins spécifiques d une application StarPU, un passage a NewMadeleine serrait intéressant pour les raisons suivantes : Les performances du module StarPUMPI chutent pour un grand nombre de requêtes en attente, d un coté car certaines implémentation de MPI et en particulier OpenMPI, peinent pour un nombre important de requêtes en attente, de l autre car le thread de progression a par nature une complexité linéaire au nombre de requête en attente pour tester les requêtes terminées. Une implémentation RPC utilisant NewMadeleine, qui est efficace même avec un grand nombre de requêtes en attente, ayant une complexité selon leur nombre constante au lieu de linéaire, et permettrait également d éviter de maintenir une liste des requêtes en attente, réduirait le surcoût causé par les requêtes en attentes.. Supprimer le thread de progression, la progression étant assurée par NewMadeleine. Cela pourrait améliorer sensiblement le recouvrement, ne faisant plus une attente active quand une communication est en attente. Nos objectifs sont les suivants : Obtenir une meilleur scalabilité en nombre de requêtes. Avoir un meilleur recouvrement Un impact positifs causé par la fusion des petits messages Garder l augmentation éventuelle de la latence sous un seuil raisonnable. 3.2 Travail effectué Ajout d un module StarPUNMad basé sur la version 1.1 de StarPU-MPI et 1.3 de StarPU Compiler le module avec MadMPI, qui nous permettra une transition plus facile vers NewMadeleine. Port du module sous NewMadeleine, en utilisant la progression idle de PIOMan au lieu d un thread de progression. L utilisation par taches étant l élément principal, mais on souhaite que l utilisation de NewMadeleine soit transparente pour un utilisateur de StarPU. Étude de performance du port 8 Figure 2 Le nouveau module StarPU-NMad implémentant StarPU-MPI 4 Portage sur Newmadeleine 4.1 Ajout d un nouveau module compilant avec MadMPI StarPU est compilé avec Autotool. Afin de faciliter une intégration future, nous avons ajouté un dossier MadMPI dans StarPU et modifié les fichier d autoconf/automake de manière a ce que le module ne soit compilé que si l option enable-nmad est passée a autoconf et la librairie MadMPI trouvée (passée via with-mpexec=, with-mpicc=, with-mpiexec=). Elle désactive également la compilation du module mpi, cependant la librairie StarPU-MPI est compilé quand même mais a partir du dossier MadMPI au lieu de MPI. Nous avons utilisé la version du module starpu-mpi 1.1 comme base de notre module MadMPI, n intégrant pas encore des optimisations spécifiques à certaines implémentations de MPI qui serraient inutiles ou contre-productives avec la librairie NewMadeleine. Cependant l interface de StarPU-MPI ayant changé entre 1.1 et 1.3,, nous avons du la porter a la nouvelle interface. Nous avons du faire les changements suivants : Ajout de fonctions faisant des appels indirects a MPI pour Simgrid (une librairie permettant de simuler un cluster plus grand que celui disponible) : trivial a porter, le support de Sim- 9 grid n étant pas encore intégré dans StarPU-MadMPI, nous faisons directement un appel MPI. Changement de paramètrestype de retours : trivial Ajout du sous modules starpu mpi datatype gérant les types MPI définit par l utilisateur : intégré depuis StarPUMPI1.3. Ajout de diverses fonctions permettant d initier un transfert de données : change seulement l initialisation des requêtes StarPU- MPI. Port des tests de la version 1.3 de StarPU-MPI afin de tester la nouvelle interface, il a également fallu les rendre plus rigoureux au standard MPI, MadMPI étant moins tolérant que OpenMPI/IntelMPI. Ainsi, par exemple, il refuse de s initialiser si pas appelé par mpirun/exec (le standard recommence qu un communicateur contenant 1 seul nœuds soit créé). 4.2 Portage du module StarPU-nmad sur NewMadeleine Garder MadMPI Nous souhaitons passer de MadMPI a NewMadeleine afin de pouvoir faire des requêtes ne nécessitant pas d être complétées par un thread en attente active. Nous souhaitons cependant respecter l interface StarPU-MPI afin de minimiser les changements nécessaires pour une application passant de StarPU-MPI a StarPU-NMad. L interface StarPU-MPI prends en paramètre des types spécifiques de MPI, afin notamment de définir comment des données sont représentées en mémoire, ou de créer des communicateurs regroupant des nœuds différents. Elle permet de plus de mélanger des communications MPI écrites par l application utilisateurs avec les communications gérées par StarPU. Il est donc nécessaire de continuer a inclure MadMPI, l utilisateur pouvant donc continuer a faire des requêtes MPI. Nous avons également utilisé certaines de ses fonctions internes afin de pouvoir convertir les types MPI en types nmad, et empaqueter les données selon la représentation qu ils décrivent. Enfin certaines fonctionnalités de MPI n ont pas d équivalent dans NewMadeleine, et ne seraient donc pas amélioré, voire dégradé suite la perte d optimisations spécifiques, par un passage de MadMPI à une nouvelle implémentation basée sur NewMadelaine. Par exemple, starpu mpi barrier, reste implémenté par un appel de MPI Barrier. Nous voulons principalement remplacer les initialisation des requêtes Send/Receive, le thread de progression gérant leur complétion et donc également les Test/Wait, où l utilisateur peut tester/attendre 10 la fin d une requête. Choix du protocole : RPC ou Send/Receive StarPU nmad possède deux paradigmes pour communiquer : le send receive similaire a MPI, et le Remote Procedure Call. Nous comptions initialement utiliser des communications RPC de New- Madeleine pour remplacer le send/receive de MPI. Ainsi quand nous recevons une communication, le handler est appelé et nous n avons donc pas besoin de tester chacune des requêtes en attente, pour trouver laquelle s est terminée. Cependant que faire si on reçoit une donnée qui n est pas encore attendue? On ne peut pas remplacer directement la donnée par sa version modifiée que l on vient de recevoir, en effet il est possible que notre StarPU local soit moins avancé dans l exécution du diagramme de tache que l émetteur et que nous ayons encore des taches accédant en lecture a cette donnée. Il serrait donc nécessaire de maintenir une liste des transfert reçu mais pas encore attendu. Ce qui est déjà fait pour un Send/Receive de manière plus efficace (protocole eager, qui est inefficace pour les gros messages). Il serrait certes également possible de définir un handler pour chaque requête prê
Related Search
Advertisements
Related Docs
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks