Team PARIS

Members
Overall Objectives
Scientific Foundations
Application Domains
Software
New Results
Contracts and Grants with Industry
Other Grants and Activities
Dissemination
Bibliography
Inria / Raweb 2002
Project: PARIS

Project : paris

Section: New Results


Keywords : metacomputing , CORBA , Java , framework , objets , composants , transformation de programme , couplage de codes .

Grilles de calcul

Participants : Alexandre Denis, Benoît Hubert, Guillaume Mornet, Christian Pérez, Jean-Louis Pazat, Thierry Priol, André Ribes.

L'accroissement des performances des calculateurs et des réseaux permet d'envisager de nouvelles applications dans le domaine de la simulation. Il est ainsi possible de coupler plusieurs codes de calcul afin d'améliorer la qualité des résultats en prenant en compte un plus grand nombre de phénomènes physiques. L'utilisation de réseaux à haut débit permet également d'envisager la visualisation des résultats produits par un supercalculateur quelque soit la distance qui sépare le supercalculateur du système de visualisation. Cette activité a pour objectif de contribuer au développement de technologies qui permettent la conception d'environnement de metacomputing. Nos travaux portent principalement sur des extensions au concept d'objets distribués en y intégrant le parallélisme, la génération automatique de code réparti, la conception de mécanismes de communication efficace entre objets distribués, les répertoires de données et la conception d'environnements logiciels pour la programmation par composants logiciels.

Une plate-forme d'intégration d'intergiciels et d'exécutifs communicants

Keywords : partage de ressources réseaux , intergiciels , exécutifs , ORB haute performance .

Participants : Alexandre Denis, Benoît Hubert, Christian Pérez, Thierry Priol.

L'exécution d'applications de simulation numérique distribuée sur des grilles de calculs nécessite l'utilisation de plusieurs intergiciels et/ou exécutifs ayant accès aux ressources réseaux. Il se pose alors un problème nouveau : la cohabitation de plusieurs intergiciels et/ou exécutifs au sein d'un même programme. Par exemple, les objets CORBA parallèles requièrent l'utilisation simultanée de l'intergiciel CORBA et de l'exécutif MPI. C'est à dire, qu'un ORB doit cohabiter avec un exécutif MPI. Cette cohabitation soulève en particulier des problèmes d'accès aux réseaux. Non seulement les différents systèmes doivent coopérer alors qu'ils n'ont a priori aucune connaissance les uns des autres mais en plus cette coopération doit être obtenu sous des contraintes de hautes performances. Le second problème avec les grilles de calculs est qu'il faut être capable de transporter les communications d'un intergiciel, comme par exemple CORBA sur tous les réseaux, allant des SAN au WAN, disponibles au sein d'une grille.

Nous avons proposé de bâtir une infrastructure permettant de brancher des intergiciels et/ou des exécutifs. Cette infrastructure est basée sur un modèle d'exécution qui garantit une cohabitation efficace des différents intergiciels et exécutifs. Le prototype PadicoTM a permis de démontrer la pertinence de la proposition en obtenant plus de 96 % de la bande passante d'un réseau Myrinet 2000, aussi bien avec MPI qu'avec CORBA.

En 2002, nous avons généralisé nos travaux sur les mécanismes d'intégration d'intergiciels et d'exécutifs communicants. Nous avons proposer une architecture d'un environnement de communication pour les grilles de calcul. Cette architecture ambitionne d'étendre l'usage des grilles de calcul en autorisant l'exécution d'applications distribués et/ou parallèles sans contraindre l'utilisation d'une couche de communication particulière. Ainsi, les deux principaux paradigmes de programmation, parallèles et distribués, peuvent être utilisés quelque soit les technologies réseaux disponibles dans une grille : CORBA peut être transporté sur des réseaux Myrinet via une couche de communication telles que BIP ou bien MPI peut être déployé sur des réseaux longue distance.

Le principe de notre architecture, présentée en figure 3 repose sur la séparation des fonctionnalités en trois couches : une couche d'arbitrage, une couche d'abstraction et un ensemble de personnalités.

Figure 3. Architecture d'un environnement de communication à trois couches pour les grilles de calcul.
padico-model02

La couche basse est la couche d'arbitrage dont le rôle est d'offrir un accès multiplexé, réentrant et efficace pour toutes les technologies de réseaux. Cette couche n'offre pas une interface uniforme mais utilise chaque technologie réseau avec le paradigme le plus approprié. Ces multiples interfaces reposent cependant sur le principe du callback pour assurer l'efficacité, la réentrance et le multiplexage. La couche d'arbitrage est donc le seul client des ressources réseaux.

Au dessus de la couche d'arbitrage, la couche d'abstraction fournit des services de plus haut niveau, indépendemment des ressources. Son rôle est de fournir des interfaces adaptées aux intergiciels et/ou exécutifs. Elle fédère les services de la couche d'arbitrage en services abstraits. Ainsi, un intergiciel et/ou un exécutif utilisant ces services abstraits ne sait pas s'il utilise un réseau Myrinet ou un réseau longue distance : il utilise toujours la même interface de programmation. La couche d'abstraction choisit automatiquement et dynamiquement le meilleur service de la couche d'arbitrage en fonction des ressources disponibles.

La couche d'abstraction fournit des interfaces abstraites, qui ne sont pas forcément des interfaces standards des paradigmes de programmation parallèles ou distribués. Afin de prendre en compte les intergiciels et/ou exécutifs existants, des personnalités, qui offrent des interfaces standards, sont placées au dessus de la couche d'abstraction. Les personnalités sont de fins adaptateurs entre une interface standard et un service abstrait particulier. Elles ne sont pas sensées réaliser une adaptation d'un protocole

Ces notions ont été intégrées dans PadicoTM  , notre plate-forme d'intégration d'intergiciels et d'exécutifs communicants. Chaque interface abstraite, personnalité et support de protocole a été implémenté dans son propre module dynamiquement chargeable. Actuellement, PadicoTM supportent les personnalités offrant les interfaces socket, les entrées-sorties asynchrones (AIO), Madeleine et Fast Messages. Les exécutifs supportés par PadicoTM sont MPI-CH, OmniORB 3 et 4, Orbacus, MICO et Kaffe. Les performances obtenues montrent que les exécutifs ne faisant pas de recopie de données arrivent à exploiter environ 240 Mo/s sur les 250 Mo/s disponible sur Myrinet 2000. PadicoTM n'ajoute qu'une demi-microseconde à la latence, ce qui permet à MPI-CH d'avoir les mêmes performances avec ou sans PadicoTM.

De nouvelles fonctionnalités sont en cours d'ajout dans PadicoTM. Ainsi, si la plate-forme supporte bien les réseaux locaux, rien de particulier n'avais été fait pour les réseaux haut débit longue distance comme VTHD. Joel Daniel, étudiant américain financé par le International Research Opportunities Program de l'UNH, a pendant trois mois développé une interface multisocket dans PadicoTM. En effet, du fait de la gestion de la perte de paquet avec le protocole TCP/IP, il apparaît intéressant de transporter les données via plusieurs sockets. L'interface utilisateur ne changeant pas, le service reconstruit les données. Les résultats préliminaires montrent une augmentation significative de la bande passante. Il serait cependant intéressant de reconsidérer ce problème avec le nouveau protocole Stream Control Transmission Protocol qui commence à être déployé. En effet, SCTP offre des mécanismes de gestion de multiflot.

Une deuxième fonctionnalité concerne également les réseaux longues distance. L'objectif est de supporter les protocoles à perte de données ajustable. Le principal intérêt de ce genre de protocole est qu'il permet d'améliorer très nettement la bande passante sur les réseaux chargés tout en offrant un modèle de programmation raisonnable. En effet, ces protocoles permettent de spécifier quelles sont les parties d'un message qui ne peuvent pas être perdu, comme le contrôle, et quel est le pourcentage de perte toléré sur les données.

Le logiciel PadicoTM a été déposé à l'APP en juin 2002. Il est diffusé sur Internet via le site du projet Paris. Fin octobre 2002, on compte une trentaine de téléchargement.

Objets CORBA parallèles portables

Participants : Alexandre Denis, Christian Pérez, Thierry Priol, André Ribes.

Ayant proposé et validé le concept d'objets CORBA parallèle portable , nous avons, cette année, réalisé une mise en œuvre (logiciel PaCO ++). Notre approche consiste à spécifier ce qui ressort de la gestion du parallélisme dans un fichier annexe  sous un format XML.

Durant l'année 2002, nous avons conçu un compilateur capable de lire la spécification IDL et le fichier d'annotations XML. Le compilateur génère des talons et des squelettes parallèles qui sont quasiment indépendants d'une implémentation de CORBA. Les bibliothèques de redistribution sont gérées comme des plug-ins. Le code généré est ainsi indépendant de la bibliothèque de redistribution effective. À terme, un avantage attendu est de pouvoir supporter simultanément plusieurs bibliothèques de redistribution et de pouvoir en changer dynamiquement. La chaîne de compilation pour les objets CORBA parallèles est présentée en figure 4.

Figure 4. Chaîne de compilation des objets CORBA parallèles portables.
Generation

Les talons et les squelettes utilisent également quelques primitives de communications, principalement pour s'identifier et réaliser des opérations de synchronisations. Afin de n'être pas dépendant d'une bibliothèque de communications, les communications sont aussi virtualisées. L'implémentation actuelle supporte deux bibliothèques de communication, à savoir MPI et MPCircuit. MPCircuit a été développé dans PadicoTM pour circonvenir à quelques limitations du modèle MPI, dont notamment de ne pas pouvoir créer des communicateurs en mode MIMD. En effet, comme il n'y a pas de synchronisation lors de la création de deux objets CORBA parallèles, nous ne pouvons pas garantir que la primitive sera appelée dans le même ordre sur tous les nœuds.

Une application d'EADS, obtenue dans le cadre de l'ACI GRID RMI, a servi de base pour une démonstration de la pertinence des objets CORBA parallèles à SuperComputing 2002. Cette application est constituée de deux ordonnanceurs locaux, chacun gérant une succession de code MPI. Les deux ordonnanceurs doivent se synchroniser et surtout échanger des données produites par les codes MPI. À l'origine, l'échange se faisait via un système de fichier commun, ce qui empêchait l'application d'être déployée sur une grille. Nous avons introduit un échange des données via les objets CORBA parallèles. En plus de permettre d'assurer le transport de donnée efficace, cette solution a l'avantage d'éviter la sérialisation lors des phases de lecture et d'écriture.

Concept de composant CORBA parallèle

Participants : Christian Pérez, Thierry Priol, André Ribes.

En juillet 2002, la spécification de CORBA 3.0 est sortie. De fait, les composants logiciels sont la spécification courante de CORBA. Notre extension sur les composants logiciels peut donc maintenant s'appuyer sur une spécification finale.

Les travaux menés dans PaCO ++ ont pour but de servir de fondation aux composants logiciels parallèles. En effet, à l'exécution les composants CORBA sont des objets CORBA avec des propriétés particulières. Les extensions parallèles définies pour un objet CORBA sont transposables à une facette d'un composant parallèle. Les réflexions ont concerné les liens entre un composant parallèle et ses facettes. Le problème, similaire à celui entre un objet CORBA parallèle et ses opérations, est la localisation de l'exécution d'une facette (resp. opération) par rapport à un composant (resp. objet) parallèle. Nous pensons qu'il est souhaitable de pouvoir définir des facettes (resp. opérations) séquentielles à l'intérieur d'un composant (resp objet) parallèle. De plus ces facettes (resp opération) peuvent être contraindre, par exemple toujours sur le même servant ou non.

Le développement de GridCCM, bien que basé sur PaCO ++ est fortement lié à la disponibilité d'une implémentation C++ des composants CORBA. Notre approche est d'enrichir les implémentations de CCM de manière la plus portable possible. C'est pourquoi notre effort s'est principalement porté sur PaCO ++.

Durant l'année 2002, nous avons principalement contribué à la diffusion du concept de composant CORBA parallèle 

Framework applicatif pour la simulation en Java

Participants : Guillaume Mornet, Jean-Louis Pazat.

En 2002, nous avons utilisé le prototype Do ! conçu dans le cadre de la thèse de Pascale Launay.

Lors du stage d'été de Maxime Glaizot (étudiant en Maîtrise IFSIC), nous avons pu mettre en évidence un certain nombre de difficultés d'utilisation du prototype Do ! pour la distribution d'un logiciel de modélisation de croissance des arbres réalisé à partir des travaux du CIRAD. La transformation automatique d'un programme Java parallèle en programme distribué pose un certain nombre de problèmes que nous n'avions pas identifié et il semble intéressant de pouvoir décider de la réplication de certaines classes ou de leur localisation de manière explicite ce que le framework de Do ! ne permet pas.

Plutôt que de poursuivre le développement de la plate-forme Do ! il nous semble plus intéressant de reprendre les idées développées dans le cadre de Do ! , c'est à dire la description du parallélisme et de la distribution par des collections pour les appliquer à d'autres environnements. Nous avons donc évalué la possibilité d'utiliser les collections avec la bibliothèque ProActive réalisée à l'Inria Sophia par Denis Caromel. Une première étude réalisée lors du stage de DEA de Taoufik Korchi (Université d'Orléans) a permis de montrer la faisabilité de l'approche et la possibilité d'introduire des constructions structurées dans ProActive.


previous
next