Précédent : Logiciels Remonter : Projet APACHE, Algorithmique Parallèle, Programmation Suivant : Actions industrielles
Précédent : Logiciels Remonter : Projet APACHE, Algorithmique
Parallèle, Programmation Suivant : Actions
industrielles
Participants : J. Briat , A. Carissimi , J. Chassin de
Kergommeaux , I. Ginzburg , M. Pasin , M. Rivière .
Mots-clés : modèles de programmation, environnement
d'exécution, processus légers, communication par message, accès
de mémoire à distance, ordonnancement
Résumé : Les noyaux exécutifs les plus répandus actuellement pour la programmation parallèle sont PVM et MPI. La raison est qu'ils sont disponibles et efficaces sur tout type de multiprocesseur. Leur fonction est de gérer les ressources de calcul et de communication en terme de processus communicants. Faire de la répartition dynamique de la charge de calcul sur un modèle de processus communicants implique de faire de la migration de processus. Dans un contexte de calcul haute performance, cette technique s'avère trop coûteuse.Une solution alternative, prise dans ATHAPASCAN-0 est d'étendre le modèle de réseau statique de processus lourds communicants (PVM, MPI) à celui de réseau dynamique de processus légers communicants et capables d'accéder à des mémoires distantes. L'intérêt de cette méthode est qu'elle est proche du paradigme processus communicants, et donc qu'elle peut hériter des avantages de cette approche (portabilité et efficacité). Un autre avantage est qu'elle offre une boîte à outil riche pour gérer données et calcul. En effet, un concept fondamental du parallélisme est celui de la localité, c'est-à-dire le rapprochement sur un couple processeur-mémoire d'un couple calcul-donnée.
L'intérêt d'un noyau exécutif réside aussi dans son aptitude à supporter différents paradigmes de programmation parallèle. Les fonctions de base d'ATHAPASCAN-0 permettent d'exprimer facilement un programme parallèle soit comme un réseau dynamique de processus communicants, soit comme un graphe de tâches. La qualité d'un noyau exécutif pour machine parallèle réside d'une part dans son aptitude à permettre l'utilisation efficace du parallélisme physique de la machine et, d'autre part, dans sa capacité à rendre compte de différentes pratiques ou modèles de parallélisation.
Athapascan-0 est orienté vers des machines parallèles à mémoire distribuée et privilégie l'organisation d'un calcul parallèle comme un réseau dynamique de processus communicants où le placement des processus et des données est explicite. L'utilisation efficace de telles machines nécessite de paralléliser les tâches de calcul et les tâches de communication c'est-à-dire recouvrir les calculs par des communications. Le recours systématique à des opérateurs de communication non bloquants permet à un programmeur d'assurer le meilleur recouvrement au sein d'un processus. La multiprogrammation de plusieurs processus permet alors de pallier des recouvrements imparfaits au sein des processus. Un travail de thèse a montré que l'utilisation de ce double mécanisme permettait un recouvrement systématique calcul - communication dès que c'était possible. Sur ces bases a été développée une bibliothèque apte à assurer de façon concurrente aux calculs les mouvements de données entre mémoires distantes. Cette bibliothèque permet de lire, écrire ou déplacer des objets entre mémoires distantes ou d'ouvrir des flots de communication d'objets entre processus. Ces opérateurs ont montré leurs efficacité dans des applications telles que l'application de Dynamique Moléculaire.
Le modèle prôné par ATHAPASCAN permet de décrire un programme parallèle comme un réseau de processus communicants ou un graphe de tâches. Il manque de concepts structurants permettant de considérer un sous-réseau de processus comme un noeud unique. Nous explorons le concept de groupe issu des systèmes distribués dans un cadre léger . Les problèmes principaux portent sur la construction de groupes et la détermination de l'état d'un groupe, les communications pluralistes au sein d'un groupe et entre groupes. Un point clef est la notion d'appel de multiprocédure à distance pour rendre compte de l'instanciation d'un groupe de processus pour exécuter en parallèle une même procédure. Une version d' ATHAPASCAN-0 propose de tels concepts dont l'usage a été expérimenté dans le développement d'une bibliothèque parallèle pour le calcul formel (GIVARO).
L'objectif d'un noyau exécutif tel que ATHAPASCAN-0 est d'être le support des développements conduits dans le projet. Il se doit donc d'être capable de s'adapter aux évolutions technologiques d'une machine parallèle à mémoire distribuée. Le projet suit plusieurs axes d'évolution. Un premier axe concerne l'accroissement d'efficacité des noeuds de calcul et des réseaux d'interconnexion. En particulier, l'apparition de noeuds multiprocesseurs à mémoire commune pose le problème de l'utilisation efficace de ce parallélisme pour d'une part améliorer le potentiel de calcul parallèle mais aussi le recouvrement calcul - communication. De même, de nouvelles interfaces pour réseaux rapides permettent d'accélrer les communications de ou vers la mémoire. Bien qu'ATHAPASCAN-0 ait été conçu pour prendre en compte de telles évolutions, il est nécessaire d'expérimenter et de mesurer pour déterminer les réglages conduisant à la meilleure efficacité.
Un autre axe concerne la tendance à utiliser des ensembles de machines quelconques via des réseaux locaux pour disposer momentanément d'une puissance de calcul importante. Les problèmes viennent alors de l'hétérogénéité des éléments. L'hétérogénéité des représentations de données a été prise en compte dès la conception initiale du noyau exécutif ATHAPASCAN-0. Le second problème est celui de la régulation de charge. L'identification des informations pertinentes à remonter aux ordonnanceurs de niveau applicatif et les incidences sur l'auto-ordonnancement des différences d'efficacité des processeurs et réseaux sont des points en cours d'étude.
Pour explorer ces différents problèmes, une plate forme hétérogène incluant des technologies émergeantes est en cours d'installation. Elle repose sur un ensemble diversifié de processeurs (RS6000, Sun, PC Pentium monoprocesseur et multiprocesseurs, DEC Alpha) et réseaux (Fast Ethernet, Myrinet, commutateurs IBM SPx et Cray T3E, et bientôt bus SCI, etc.). Un action collaborative est en cours sur ce thème avec les projets Caps, Remap et Sirac, ainsi que le LIFL.
ATHAPASCAN-0 est développé prioritairement pour la programmation directe d'applications scientifiques ou comme support exécutif d'ATHAPASCAN-1. Il peut être néanmoins intéressant de tester son adéquation en tant que support exécutif pour d'autres langages de programmation. Un travail se poursuit autour de Prolog et d'autres travaux sont envisagés autour de la programmation en Fortran HPF (avec C. Germain au LRI) et Axiom (un langage de calcul formel avec le projet SAFIR). La parallélisation des systèmes de programmation en logique pose des problèmes difficiles d'ordonnancement et de partage de charge, les raisons étant l'estimation a priori du grain des tâches parallèles et le caractère spéculatif de certains calculs. Un prototype PLOSYS est en cours de développement en collaboration avec le projet LOCO et l'université de Porto Allegre.
Résumé : ATHAPASCAN-1 implémente un modèle de programmation parallèle qui permet l'expression de la décomposition d'un calcul en sous-calculs parallèles ainsi que l'enchaînement de phases parallèles, avec une syntaxe et une sémantique simples. Ce modèle est basé sur la création dynamique d'activités (ou tâches) qui se partagent des données.ATHAPASCAN-1 propose un mécanisme original de résolution des conflits d'accès aux données partagées. Cette interface de programmation permet de générer un graphe de flot de données dont les noeuds sont les tâches (graphe macro-dataflow). Ce graphe peut avoir une structure statique (i.e. connue a priori) ou être déterminée dynamiquement (i.e. construite en cours d'exécution). Un module de répartition de charge permet de répartir les tâches statiquement ou dynamiquement, en fonction des caractéristiques du graphe : c'est alors un programme qui s'exécute sur le noyau exécutif ATHAPASCAN-0, en terme de processus communicants avec placement explicite. ATHAPASCAN-1 permet ainsi de séparer le programme qui décrit l'algorithme, du programme qui alloue les ressources de la machine aux diverses tâches. Cette séparation doit permettre d'obtenir par un algorithme de répartition adapté et, quelle que soit la machine sous-jacente, une implantation efficace et portable d'un même programme conçu avec un grain suffisamment fin. Un travail de ``benchmarking'' de cette interface est mené en étroite relation avec sa conception.
ATHAPASCAN-1 permet une description explicite et dynamique du parallélisme par création asynchrone de tâches parallèles. Pratiquement, ATHAPASCAN-1 se présente comme une interface de programmation impérative (bibliothèque C++) où tout appel de procédure ATHAPASCAN-1 se traduit par la création d'une tâche parallèle. Ces procédures sont sans effet de bord et les paramètres effectifs sont des références à des données globales du programme, qui sont traitées comme les données à assignation unique du modèle de calcul dataflow. Les accès effectués sur ces objets définissent les relations de dépendances entre les tâches. Quatre modes d'accès sont offerts. Les données admettent des lectures et des écritures (le cas le plus courant qui impose des contraintes de séquencement entre les tâches), ou bien des lectures uniquement (donc potentiellement concurrentes), ou encore des écritures exclusivement et enfin des écritures par accumulation uniquement. La sémantique est que toute lecture d'un objet partagé (i.e. lecture-écriture) voit la dernière écriture dans l'ordre séquentiel d'appel des tâches. Cet ordre est une exécution séquentielle possible du programme ATHAPASCAN-1 correspondant à un parcours en profondeur d'abord du graphe des appels. La création de tâche est asynchrone, car l'instant d'activation de la tâche lors d'une exécution dépend de la satisfaction des contraintes de cohérence sur les données et de la répartition de charge qui peut retarder l'activation d'une tâche voire l'exécuter localement et séquentiellement.
L'interface permet l'interprétation d'un programme sous forme d'un graphe de tâches (graphe macro data-flow) sans exiger une analyse complexe de code. L'exécution d'une tâche est conditionnée par la terminaison d'autres tâches et/ou la disponibilité de données. Nous appelons transitions de telles conditions d'exécution. Une tâche passe à l'état prêt lorsque toutes les transitions qui conditionnent son exécution sont franchies.
La construction et l'exécution du graphe est dynamique et distribuée. Sur chaque noeud, un état local et partiel de l'application est maintenu. Cet état évolue en fonction des actions des tâches en cours d'exécution sur le noeud. Celles-ci accèdent à des données, créent de nouvelles tâches et de nouvelles données, puis se terminent. L'état local enregistre ces modifications. Cet état évolue aussi à l'initiative de l'ordonnanceur local qui décide des tâches à exécuter parmi les tâches prêtes. C'est lui aussi qui, coopérant avec les ordonnanceurs distants, décide d'exporter (respectivement importer) des tâches. Un module local de gestion des transitions coopére avec ses correspondants distants pour déterminer globalement les transitions franchies. La détermination du franchissement global d'une transition à partir de la détection de franchissements locaux est un algorithme distribué de la classe des algorithmes de détection de terminaison globale.
L'objectif d'une stratégie de répartition (politique de décision) dépend de l'application considérée : ce peut être d'optimiser le temps d'exécution ou l'espace mémoire, généralement un compromis entre les deux. La qualité de la stratégie dépend en outre de la connaissance de l'application (i.e. du graphe de tâches associé) et de la machine d'exécution. Le système est donc ouvert : la stratégie de répartition peut être substituée par une autre qui respecte une spécification d'interface avec le module de gestion du graphe de tâches d'une part et avec le module de mise en oeuvre des tâches (sous forme de threads ATHAPASCAN-0) d'autre part. Le choix de la stratégie de répartition et les informations de coûts se font par annotation du code, et ceci pour chaque tâche. Ces informations peuvent aussi être héritées. Les expérimentations développées sur ATHAPASCAN-0 ont montré la pertinence de telles informations pour répartir efficacement certaines applications, en particulier en décomposition de domaines et dynamique moléculaire.
Il existe une librairie qui comporte pour l'instant des
stratégies naïves (aléatoire, cyclique) et des stratégies de
répartion justifiées sur le plan théorique par la théorie de
l'ordonnancement en ligne (ordonnancement 
-compétitif). Ces stratégies cherchent à minimiser
l'inactivité des noeuds (algorithmes de liste, ``work
stealing''). Cette librairie doit s'enrichir dans l'avenir. Une
perspective est d'offrir un interface de programmation pour
différentes politiques, suivant un certain consensus en ce qui
concerne l'implantation des algorithmes de répartition en terme
de composants, politiques de prise d'information, de décision
et de transfert.
Résumé : Les programmes parallèles sont en général difficiles à mettre au point et leurs performances sont critiques. Dans le contexte du projet, une approche de trace logicielle s'impose, pour de simples raisons de portabilité. Nos recherches se sont concentrées sur des techniques permettant de maîtriser l'intrusion générée par la trace logicielle : il s'agit de mettre au point des algorithmes de réexécution déterministe pour le débogage et de correction de la perturbation temporelle pour les traces de performance. D'autres travaux portent sur le problème du filtrage de l'information (de débogage ou de performance) afin qu'elle soit utilisable par le programmeur à travers des outils de visualisation.
Le non déterminisme apparent des exécutions parallèles induit des erreurs fugitives particulièrement difficiles à détecter. En effet, des programmes parallèles produisant des résultats déterministes sont susceptibles d'emprunter des chemins d'exécution différents en raison de conditions différentes dans l'environnement d'exécution (par exemple s'il y a régulation dynamique de charge). Dans ces conditions, des erreurs fugitives sont susceptibles d'apparaître, erreurs qui ne se produisent pas à toutes les exécutions ou disparaissent lorsque des moyens d'investigation sont mis en oeuvre (traceur, débogueur). La technique classique pour mettre au point les programmes à comportement non déterministe est d'enregistrer, au cours d'une exécution initiale, une trace. Cette trace sera utilisée pour forcer le programme à suivre le même chemin durant les exécutions suivantes pour lesquelles il sera ainsi possible d'utiliser tous les outils de débogage existants.
Dans le cadre des techniques classiques de réexécution de programmes parallèles, un mécanisme original a été défini pour un sous-ensemble de ATHAPASCAN-0. Le surcoût dû à la prise de traces a été mesuré de façon systématique en utilisant des programmes synthétiques. Les résultats des mesures ont mis en évidence un surcoût très faible. Le travail en cours consiste à étudier une adaptation des mécanismes existants à l'ensemble des primitives de ATHAPASCAN-0, ainsi qu'à ATHAPASCAN-1.
La prise de trace concerne essentiellement l'ordonnancement des fils d'exécution, avec pour chaque processus léger son identité, le début, la fin et la cause des périodes de suspension de son exécution. S'y ajoutent des informations permettant de reconstituer l'historique des communications. La mise en oeuvre d'un traceur pour ATHAPASCAN-0 a permis de soulever et de résoudre divers problèmes d'identification des fils d'exécution, d'observabilité de leur ordonnancement, d'atomicité des événements et de gestion des tampons de trace. Le traceur contient un mécanisme de recalage des horloges distribuées sur chaque processeur afin de disposer d'une horloge physique globale. Il est construit en instrumentant le code, de façon à ce que le temps de prise de mesure soit autant que possible prévisible et n'induise qu'une perturbation localisée autour du point mesuré. Un algorithme de correction post-mortem est en cours de réalisation, permettant de corriger autant que faire se peut les perturbations directes du programme instrumenté.
La visualisation des exécutions parallèles est difficile en
raison du grand nombre d'objets mis en oeuvre lors de ces
exécutions. Les propriétés que doivent vérifier les
environnements de visualisation d'exécutions parallèles sont
principalement l'extensibilité en terme de fonctionnalités
(nouvelles représentations visuelles ou sonores) et en terme de
taille de l'objet visualisé ![[*]](../icons/foot_motif.gif){kind=icon}
.
Pour assurer l'extensibilité de l'environnement de visualisation, ce dernier est constitué d'un ensemble de composants. Un outil d'analyse de traces et de visualisation particulier est constitué en assemblant des composants de l'environnement pour constituer un graphe flot de données. L'environnement peut être enrichi par encapsulation d'un module de traitement de traces ou de visualisation pour constituer un nouveau composant de l'environnement. Des protocoles de communication entre composants ont été définis pour faciliter la réalisation de nouveaux modules connectables aux composants existants. Un prototype a été réalisé en utilisant le système OpenStep et son portage vers le système du domaine public GnuStep, pour en faciliter la diffusion, est étudié actuellement.
Les programmes ATHAPASCAN mettent en oeuvre un nombre important de processus légers, apparaissant et disparaissant dynamiquement durant l'exécution des programmes. Deux des visualisations les plus utilisées ont été combinées et adaptées à ATHAPASCAN : la représentation gère un nombre variable de processus légers dont les communications (diagramme espace-temps) et les états d'activité (diagramme de Gantt) sont représentés. Les objets visuels (tranche de vie de processus léger, communication, par exemple) sont interrogeables par l'utilisateur. Différents filtres ont été également réalisés pour faciliter la compréhension de l'utilisateur en regroupant ou restructurant l'information.
Précédent : Logiciels Remonter : Projet APACHE, Algorithmique
Parallèle, Programmation Suivant : Actions
industrielles