Chapitre 2 : L’existant
III.2 Quelques outil pour la parallélisation d’applications
Neko (Urbán, Défago et Schiper 2002) est une plateforme implémentée en Java. Elle permet le prototypage, la conception, le paramétrage, le déploiement et l’analyse de performances d’algorithmes distribuées.
Comme le montre la Figure 22, Necko permet le développement d’application selon une architecture en couche. Une couche est soit active, dans le cas ou un processus léger ou « thread » lui est dédié, soit passive dans le cas contraire. Les couches passives sont des instances de classes héritant de la classe Layer et les couches actives héritent de
89
ActiveLayer. L’envoi de message « unicast » ou « multicast » se fait à l’aide des instances de la classe NeckoMessage via l’utilisation de communications réseau TCP (Transmission Control Protocol), UDP (User Datagram Protocol) ou d’un réseau simulé. Tous les processus légers de Necko sont reliés à une instance de NeckoProcess. Il est ainsi possible de partager des zones de mémoire entre les processus légers reliés au même
NeckoProcess.
Figure Figure Figure
Figure 22222222 Architecture d’une application nekoArchitecture d’une application nekoArchitecture d’une application neko Architecture d’une application neko
III.2.2 Comet
Comet (Peschanski et J.P. 2004) est un intergiciel pour l’implémentation de systèmes répartis. Il permet la définition de composants et d’événements ainsi que des relations de type « hérite de » dans un langage spécifique appelé « Scope ». Les composants peuvent communiquer entre eux de manière distribuée par l’envoi d’événements. Les communications réseau, implémentés dans Comet utilisent les protocoles TCP et UDP.
Les événements sont des objets, se rapprochant de simples structures de données, comprenant des attributs, des constructeurs, et des accesseurs.
Les composants sont des entités définissant :
• les messages qu’ils peuvent recevoir,
• les messages qu’ils peuvent émettre,
90
• un comportement défini pour la réception d’un message d’un type donné.
Les destinataires des messages ne sont pas spécifiés lors de la conception des composants. Les composants sont reliés entre eux par des connections dynamiques, typées, unidirectionnelles et asynchrones (Peschanski et Briot 2005). Les connexions s’effectuent au travers de la commande « connect » du langage Scope. Celle-ci permet de connecter entre eux deux composants (source vers destination) pour un type de message donné.
Comet permet de plus, de définir des « Rôles » et des « Protocoles » afin de redéfinir dynamiquement et sans interruption de service le comportement des composants.
III.2.3 PVM (Parallel Virtual Machine)
D’après (Geist, et al. 1994), le projet PVM (Parallel Virtual Machine) a débuté en 1989 au laboratoire national d’Oak Ridge. Le prototype PVM 1.0 fut implémenté par Vaidy Sunderdam et Al Geist. Cette version fut utilisée uniquement en interne. La version 2 de PVM a été écrite par l’université du Tennessee, et publiée en mars 1991.
Durant l’année suivante, PVM commença à être utilisé par de nombreuses applications scientifiques. Les retours des utilisateurs amenèrent nombre de changements et une réécriture complète du code pour la version 3.0 publiée en février 1993.
Aujourd’hui PVM à atteint la maturité et la dernière version publiée est la version 3.4.525. Dans la version 3 de PVM, la communication entre les processus d’une application distribuée (envoi de message, synchronisation) se fait via l’utilisation de la bibliothèque « libpvm » et au travers d’un processus serveur, le « daemon » PVM.
De nombreuses implémentations de PVM sont maintenant disponibles, notamment en Java26 en Perl27 en Python28. La version ePVM (Frattolillo 2005) permet une utilisation de PVM sur grille de calcul. Pour cela il suffit que les nœuds de calcul aient accès à internet. Il n’est pas nécessaire qu’ils possèdent une adresse IP (Internet Protocol) publique.
25 http://www.csm.ornl.gov/pvm/pvm_home.html
26 http://www.cs.virginia.edu/~ajf2j/jpvm.html
27 http://www.csm.ornl.gov/pvm/perl-pvm.html
28 http://pypvm.sourceforge.net
91 III.2.4 OpenMP
OpenMP29 (Dagum et Menon 1998) est une API (Application Programming Interface) pour la parallélisation d’application en C, C++ et en fortran. La spécification de l’aspect parallèle d’une application sur des machines à mémoire partagée avec OpenMP s’effectue par inclusion de directives de compilation dans le code, d’utilisation d’une bibliothèque de fonctions et de variables d’environnement.
Alors que la spécification 1.0 de OpenMP date de 1997 pour la version fortran et 1998 pour la version C / C++, la première implémentation pour un réseau de machines à mémoire partagée est publiée en 2000 (Hu, et al. 2000). A l’heure actuelle, les spécifications stables d’OpenMP sont dans leur version 2.5 alors que la soumission de commentaire pour la future version 3.0 s’achevait le 31 janvier 2007.
Il est envisageable de paralléliser des applications en utilisant OpenMP pour du calcul massivement parallèle. Pour preuve il a été utilisé conjointement à MPI (Message Passing Interface) sur le Earth Simulator pour du calcul élément fini distribué (Nakajima 2005). A ma connaissance, OpenMP n’est pas utilisé pour du calcul sur grille.
III.2.5 MPI (Message Passing Interface)
MPI (Message Passing Interface) est un standard pour la programmation parallèle proposé pour la première fois par Walker dans (Walker 1994). La conception de MPI est issue d’un effort collectif de chercheurs Européens et Américains de différentes organisations et institutions.
MPI a été écrit pour obtenir de bonnes performances aussi bien sur des machines parallèles à mémoire partagée que sur des clusters d'ordinateurs hétérogènes à mémoire distribuée. Il inclut des normes de communication point à point et collectives, une bibliothèque de fonctions et un compilateur associé. Il est grandement disponible sur de très nombreux matériels et systèmes d'exploitation. MPI est portable (implémenté sur différentes architectures de mémoires) et rapide (optimisé pour le matériel sur lequel il s'exécute).
D’après (Laforenza 2002) de nombreuses solutions existent pour exécuter des applications distribuées utilisant MPI sur grille : PACX-MPI (Brune, Fagg et Resch 1999), MPI Connect (Fagg, London et Dongarra 1998), Stampi (Imamura, et al. 2000),
29 http://www.openmp.org
92
MPICH/Madeleine III (Aumage, Eyraud et Namyst 2001), MagPIe (Kielmann, et al.
2002), MPICH-G2 (Karonis, Toonen et Foster 2003)30, MetaMPICH (Clauss, Pöppe et Bemmerl 2004)30.
Les travaux de recherches concernant l’utilisation de MPI sur grille sont nombreux.
Le magazine « Future Generation Computer Systems » a publié en février 2008 une section spéciale intitulée : «
Grid computing and the message passing interface
». Cette section présente des projets comme Migol (Luckow et Schnor 2008) : un intergiciel de grille pour l’exécution parallèle avec MPI basé sur Globus, permettant une tolérance accrue aux fautes et MGF (Gregoretti, et al. 2008) : une librairie basée sur MPICH-G2 qui permet l’utilisation transparente de ressources de grille. Ces deux projets permettent de prendre en compte les spécificités d’une architecture grille, et notamment la possibilité d’établir des communications inter-grappe de calcul entre des nœuds appartenant à des réseaux privés et qui ne possèdent pas d’adresse IP (Internet Protocol) publique.III.2.6 CORBA (Common Object Request Broker Architecture)
CORBA (Common Object Request Broker Architecture) est un intergiciel orientée objet pour l’appel de méthodes résidant dans le même espace d’adressage ou dans des espaces d’adressages distants. CORBA est un standard proposé par l’OMG (Object Managment Group).
Une plateforme d’objets répartis comme CORBA comprend un bus d’objets réparti (ou ORB Object Request Broker). Une description claire de ce composant est faite dans (Peschanski et Briot 2005) : «
Ce logiciel dédié, […] représente la clef de voûte de toute l’architecture intergicielle. L’ORB permet à des objets implémentés dans des environnements variés et localisés sur des machines réparties géographiquement d’interagir entre eux. Il implémente les protocoles fondamentaux pour le bon fonctionnement des objets répartis, en particulier la gestion du cycle de vie des objets (déploiement sur des sites distants, localisation d’instances, etc.) ainsi que les invocations distantes de méthodes. Le critère fondamental pour un bus d’objet réparti est de proposer ce genre de service de manière transparente, en s’abstrayant dans les plus larges mesures possibles des contraintes liées à la nature répartie et hétérogène de l’infrastructure sous-jacente.
»
30 Références parues depuis l’article de 2002
93
CORBA utilise de plus un langage de définition d’interface appelé IDL (Inteface Definition Language) qui permet de décrire l’interface que présente un objet pour la communication avec les autres objets de l’application distribuée.
CORBA a été initialement conçue pour le développement d’applications distribuées.
Il permet aujourd’hui de faire communiquer des applications distantes écrites dans des langages différents. Des technologies similaires ont été implémentées par Microsoft avec DCOM (Distributed Component Object Model) et par Sun avec RMI (Remote Method Invocation) de la plateforme Java.
Des travaux ont été menés pour l’utilisation de CORBA sur grille de calcul. Parmi eux, ceux présentés dans l’article (Chunlin et Layuan 2003) présentent un intergiciel de grille basé sur CORBA et ceux présentés dans l’article (Wang 2008) présentent l’implémentation d’un algorithme génétique sur grille calcul utilisant la bibliothèque paCO (Parallel CORBA) (Denis, et al. 2003). PaCO est une bibliothèque permettant à une application distribuée de communiquer en utilisant aussi bien une approche de passage de messages, à la MPI, que des invocations distantes de méthodes, à la CORBA, dans le but affiché de simplifier l’implémentation de simulations distribuées sur grille de calcul.
III.3 Quelques outil pour la parallélisation de simulations à événements