La parallélisation de simulations multi-agents rencontre de nombreuses difficultés liées à l’adaptation d’un programme en mémoire partagée ou distribuée. Il est ainsi possible de citer la nécessité d’identifier les sections parallèles de l’algorithme et de synchroniser l’accès aux données partagées en mémoire partagée, ou la décomposition explicite des données et de l’algorithme ainsi
que la prise en compte des échanges et des communications requises par l’exécution en mémoire distribuée.
Heureusement, le formalisme multi-agents propose une décomposition du système en agents ou en environnement dont la gestion et les échanges peuvent être traités par des plates-formes multi-agents spécialisées. Cette prise en charge d’une partie de l’exécution permet également à de telles plates-formes de faciliter cette démarche de parallélisation.
3.2.1 Madkit
MadKit (Multi-Agent Development Kit)1 est une plate-forme générique de développement et d’exécution de systèmes multi-agents [GF00a] réalisée en Java. Elle est développée au sein du LIRRM2.
Le modèle AGR (Agent, Groupe, Rôle) [Gut01] est à la base des modèles et de l’architecture de la plate-forme, dont les différents services sont implémentés par des agents pour un maximum de flexibilité. Le noyau de Madkit se caractérise par sa légèreté et n’assure que les services nécessaires à la mise en place de ces agents : la gestion des groupes et des rôles, un ordonnancement synchrone, et une infrastructure d’échange de messages entre agents locaux.
Par défaut MadKit associe un thread à chaque agent autonome présent dans le système. Pour éviter l’utilisation de milliers de threads dans le cas de nombres importants d’agents, il est possible de créer des agents découplés de l’ordonnanceur, gérés et mis à jour par un ou plusieurs agents observateurs associés à des threads d’exécution. Ce modèle multi-thread permet une parallélisation aisée des agents en mémoire partagée.
La parallélisation du modèle en mémoire distribuée est rendue possible par la possibilité de lancer plusieurs noyaux MadKit et de surcharger le service d’échange de messages pour permettre à toutes ces simulations de communiquer [GF00b]. Cette surcharge d’un service système est per- mise par la présence de points d’accroche (hook) permettant de surveiller les messages échangés ou de remplacer un service particulier. Un agent permettant ce fonctionnement nommé Communi- catorest fourni par défaut avec MadKit. Chaque noyau exécute alors une instance de cette agent Communicator pour gérer l’échange des messages. Un nouveau mécanisme de distribution per- mettant le dialogue par le biais d’un agent réseau sans connaître l’emplacement des instances distantes, NetComm [RHK06], a depuis également été proposé. Ces mécanismes de communica- tion permettent soit une distribution maître-esclave, où un noyau possède le modèle de référence mis à jour par les agents distants, soit sur une duplication du modèle sur chaque instance. Ces deux approches de distribution sont étudiées plus en détail dans [MBF02].
3.2.2 JADE
La plate-forme JADE [BCG07] est une plate-forme multi-agents développée en Java par le groupe de recherche CSELT (partie de Gruppo Telecom). Elle permet la réalisation de systèmes multi-agents conformes à la norme FIPA [fip].
Les services FIPA sont fournis directement par la plate-forme JADE, ce qui rend le support de la norme transparent pour le concepteur de modèle.
L’intégration d’un nouvel agent dans un modèle JADE en cours d’exécution est décomposée
1. http://www.madkit.org
en plusieurs étapes :
— L’enregistrement de l’agent auprès de la plate-forme agent. — L’attribution d’un nom et d’une adresse unique à l’agent.
— L’utilisation des services de recherche et de communication pour s’interfacer avec les autres agents.
Ce découplage des agents de leur emplacement physique rend possible la migration d’agents entre machines en cours d’exécution, au moyen d’un ensemble d’outils prenant en charge le dé- ploiement et le suivi du modèle. La distribution est assurée par l’utilisation des threads et une interface de communication proposée par JADE. Cette interface repose sur le protocole RMI pro- posé par Java pour communiquer entre instances distantes [VQC02].
JADE ne prend en charge que la création, l’évolution et la communication entre agents, et ne propose aucune structure de données pour la représentation de l’environnement ou d’autres données partagées. La représentation de ces éléments est néanmoins possible sous forme d’ob- jets indépendant ou d’agents spécifiques dans la simulation. Il est ensuite possible d’utiliser des messages pour envoyer ou recevoir des informations sur ces structures partagées.
En prenant en compte toutes les communications, JADE facilite l’utilisation d’une architecture en mémoire partagée ou distribuée pour la simulation multi-agents. Cette plate-forme se limite toutefois à ce rôle, et ne propose pas de mécanisme de synchronisation ou de partage automatique des données entre instances d’exécution : cette gestion reste de la responsabilité du concepteur du modèle, en utilisant les structures de données fournies par le langage Java.
3.2.3 FLAME
FLAME3[HCS06] est un générateur de simulations multi-agents parallélisées. Il se base pour cela sur la description des modèles sous la forme de machines à états (X-Machine) en XMML, version étendue du XML. Cette description abstraite permet de découpler l’exécution du système multi-agents de toute plate-forme d’exécution spécifique.
La description d’un modèle FLAME repose sur la spécification d’un état initial, d’un ensemble d’états intermédiaires et d’un ou plusieurs état finaux. Le passage entre ces états est décrit sous forme de fonctions de transition, exécutées pour chaque agent à chaque pas de temps de la simu- lation. Une itération, ou pas de temps, est définie comme la fenêtre de temps nécessaire à chaque agent pour progresser de son état initial à l’un des états finaux du graphe de transitions. Ce proces- sus est reproduit à chaque itération.
En parallèle de ces états représentant les stades d’exécution de chaque agent, FLAME associe à chaque agent une mémoire pouvant contenir des variables lues et modifiées par les différentes fonctions de transition.
La communication entre agents est assurée par la possibilité d’envoyer et de recevoir des mes- sages au niveau de ces mêmes fonctions de transition. Leur transmission est réalisée de manière synchrone, pour garantir la réception simultanée de chaque message par tous ses destinataires : cette synchronisation est particulièrement importante lors de l’exécution d’un modèle sur une ar- chitecture distribuée HPC pour permettre qu’aucun agent ne soit favorisé ou défavorisé par son ordre de passage. Les messages sont distribués à l’ensemble des agents du modèle par la biblio- thèque Libmboard basée sur MPI pour les échanges de messages [KRH+10]. Il est ensuite possible à chaque agent de filtrer les seuls messages le concernant.
La modélisation d’un modèle en FLAME est décomposée en quatre étapes : — La description de chaque agent et de sa fonction.
— La description des états correspondant à leur évolution à chaque itération
— L’identification des variables utilisées pour le déclenchement et dans le traitement de chaque fonction de transition définie dans le modèle.
— L’identification des messages émis ou reçus par ces fonctions de transition.
Ce processus peut être représenté sous la forme d’un diagramme de transition. La Figure 3.2 illustre une représentation possible d’un modèle d’essaim (Swarm) avec FLAME.
début de la positionDiffusion état 1 autres positionsRéception état 2 Mise à jourposition fin
Nouvelle itération
Figure 3.2 – Représentation conceptuelle d’une itération de modèle Swarm
L’implémentation du modèle économique européen EURACE, mettant en jeu des agents inter- venants sur plusieurs marchés économiques, prévoit d’utiliser ces mécanismes [DvdHD08].
La plate-forme FLAME permet de s’abstraire totalement de la démarche de parallélisation en mémoire partagée ou en mémoire distribuée, en prenant en charge la totalité de la génération de la simulation. Cette abstraction dépend toutefois d’une description très fine du modèle et de ses interactions par le concepteur, qui contraint fortement la définition des modèles.
3.2.4 Repast HPC
Repast HPC [CN11] est une bibliothèque dédiée au calcul sur architectures hautes perfor- mances. Elle propose une implémentation des concepts fondamentaux de RepastSimphony sur des architectures mémoire distribuées et plus particulièrement sur les clusters de calculs. Le dévelop- pement de modèles agents avec Repast HPC peut être effectué directement à l’aide des composants de la bibliothèque ou en manipulant des concepts d’emplacements et de tortues inspirés de Logo.
L’implémentation des agents est réalisée sous forme d’instances de classes C++ encapsulées dans un Contexte représentant leur environnement. Leur organisation dans le modèle est assurée par la définition de Projections. Une projection grille place ainsi les agents dans une structure grille où chaque agent correspond à une cellule, tandis qu’une projection réseau permet la mise en place de relations entre agents. Une simulation Repast HPC est ainsi composée d’agents, d’au moins un contexte, et de zéro ou plusieurs projections.
La distribution des agents en Repast HPC est basée sur un parallélisme à mémoire distribuée. Les agents du modèle sont répartis entre plusieurs processus responsables du traitement de leurs agents locaux. L’interaction avec un agent distant requiert sa copie en mémoire locale, la mo- dification de cette copie, puis sa synchronisation avec l’agent original, pendant que l’exécution de l’agent distant est suspendue [rep]. Pour faciliter la gestion de ces copies, chaque agent est identifié de manière unique par trois informations : un identifiant attribué par l’utilisateur, l’index de son processus de lancement et son type. Chaque agent stocke également l’index du processus
l’exécutant actuellement.
La synchronisation et l’échange des agents entre processus sont assurés via le protocole de communication MPI [rep] par le biais de son implémentation BoostMPI4.
Ce mécanisme de découpage permet à Repast HPC de prendre en charge de nombreuses pro- blématiques de la parallélisation en mémoire distribuée et en particulier la copie et l’exécution des agents présents sur les différents noeuds d’exécution.
3.2.5 D-MASON
La plate-forme D-MASON [CCC+12] est une version parallèle de la bibliothèque MASON, ajoutant une couche supplémentaire permettant la distribution de la simulation en mémoire distri- buée sur des machines hétérogènes.
La distribution de la simulation en D-MASON est basée sur trois blocs fonctionnels, un gestion- naire, des travailleurs (workers) correspondant à des threads Java et des communications. Le rôle de gestionnaire est assuré par une application maîtresse qui prépare la simulation et gère ensuite son déroulement en pas de temps synchrones en coordonnant les différents processus travailleurs. Cette répartition des tâches repose sur le partitionnement de l’espace à simuler en régions pou- vant être assignées à un worker particulier. Chaque worker est ensuite responsable de l’exécution des agents présents dans sa région, ainsi que de la synchronisation des traitements ou de la mi- gration des agents entre régions. Les échanges requis pour ces opérations sont gérés par le biais de JMS [CCM+11], une interface de programmation permettant d’envoyer et de recevoir des mes- sages asynchrones entre composants Java.
Cette répartition automatique de l’environnement par la plate-forme, associée à celle de l’or- donnancement et des traitements, permet la gestion des trois approches de parallélisation de sys- tèmes multi-agents. D-MASON se caractérise de manière générale par la volonté d’introduire la distribution à tous les niveaux du système, plutôt que de se focaliser uniquement sur les perfor- mances, pour résoudre les limitations en ressources, en particulier mémoires, de manière transpa- rente pour le concepteur.
3.2.6 Pandora
Une dernière plate-forme permettant la distribution d’un système multi-agents sur plusieurs noeuds de cluster est Pandora [pan]. Cette plate-forme permet le prototypage rapide de modèles à l’aide du langage de programmation Python, ou la réalisation de modèles plus complexes à l’aide de C++. Ces deux langages d’implémentation partagent la même interface de programmation et les mêmes concepts, de manière à faciliter l’adaptation de modèles entre les deux syntaxes. Il est plus particulièrement conçu pour la simulation de milliers d’agents dans un espace géographique. La distribution en mémoire partagée des systèmes Pandora repose sur la distribution de por- tions de l’environnement et des agents sur chaque noeud du système à l’aide de OpenMP et de MPI [ASÁ01]. La parallélisation locale de la simulation est basée sur l’observation par ses concep- teurs d’une décomposition standard du cycle agent dans de nombreux modèles multi-agents :
— Évaluation de l’environnement et des stimulis. — Prise de décision quant à l’action à effectuer. — Réalisation de l’action.
— Mise à jour des variables internes.
Pandora permet la parallélisation de l’évaluation de l’environnement et de la prise de décision de manière automatique avec OpenMP. La suite des traitements est séquentialisée pour garantir la cohérence des mises à jour du modèle. L’originalité de cette plate-forme réside dans la gestion automatique de la distribution et de la copie des informations situées à la frontière de deux portions voisines de l’environnement à l’aide des champs d’action [WRC12].