Expérimentation avec le modèle d’évaluation des SMA parallèles

Le modèle d’évaluation des SMA parallèles utilisé pour les expérimentations est basé sur une grille de 300x300 où 10000 agents sont initialement positionnés de manière aléatoire. De la même

● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● 0 20000 40000 60000 80000 0 500 1000 1500 2000 Number of timesteps Number of agents

● _{GRASS SHEEP WOLF}

Figure 3.17 – Résultats d’exécution du modèle proie-prédateur utilisant les Nested Graph sur 128 cœurs et 2000 pas de temps (Jeu de valeurs 1 de la Table 3.2)

● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● 0 10000 20000 30000 40000 0 500 1000 1500 2000 Number of timesteps Number of agents

● _{GRASS SHEEP WOLF}

Figure 3.18 – Résultats d’exécution du modèle proie-prédateur utilisant les Nested Graph sur 128 cœurs et 2000 pas de temps (Jeu de valeurs 2 de la Table 3.2)

manière que pour le modèle proie-prédateur, par souci de reproductibilité, la même configuration initiale est utilisée pour toutes les exécutions des simulations et pour toutes les plateformes, seule la graine varie d’une exécution à une autre. A l’exception de la plateforme RepastHPC qui n’utilise pas de fichiers d’initialisation mais propose une méthode d’initialisation unique qui sera exécutée sur chacun des processus participant à la simulation. Le champ de perception des agents est de rayon 3. En ce qui concerne les choix aléatoires (choix de la cellule voisine pour le déplacement et l’initialisation de la table DFT), tous sont basés sur des lois uniformes. Le calcul

●● ● ● ● ● ● 0 10 20 30 0 50 100 Number of cores Speed−up

● FPMAS (PP Grass 30) FPMAS (PP Grass 8)

(a) Speed-up ● ● ● ● ● _● ● 0 5000 10000 15000 0 50 100 Number of cores

Running time (sec.)

● FPMAS (PP Grass 30) FPMAS (PP Grass 8)

(b) Running time

Figure 3.19 – Extensibilité et temps d’exécutions pour la plateforme FractalPMAS avec le modèle proie-prédateur basé sur la structure de Nested Graph de 2 à 128 cœurs pour 2000 pas de temps

de DFT pour générer une charge interne à chaque agent est effectué sur un tableau de taille 128. Pour finir les simulations sont exécutés durant 200 pas de temps. La Table 5.1 présente les jeux de paramètres détaillés pour les expérimentations du modèle d’évaluation des SMA parallèles.

Sur les Figures 3.20 chaque point est une valeur moyenne de dix exécutions. Comme précé- demment le coefficient de variation entre les résultats d’exécution est faible, compris entre 0,1% et 0,7%. Nous ne l’avons donc pas reporté sur les graphiques.

Les Figures 3.20 montre l’extensibilité (Figure 3.20(a)) et les temps d’exécutions (Figure 3.20(b)) des plateformes avec l’exécution du modèle de référence. Comme pour le précédent modèle proie- prédateur, le temps de référence pour calculer le speed-up est basé sur 2 cœurs. A partir de ces figures, nous pouvons conclure que les trois plateformes sont extensibles jusqu’à 32 cœurs même si RepastHPC à tendance à croître plus lentement que les autre plateformes après 64 cœurs.

Paramètres Jeu de valeurs 1 Environnement 300x300 Nb. Agent 10000 Chp. perception 3 Taille DFT 128 Nb. pas de temps 200

Table3.3 – Jeux de paramètres pour les expérimentations du modèle de référence

●●● ● ● ● ● 0 10 20 30 40 0 50 100 Number of cores Speed−up ● Flame FPMAS RHPC (a) Speed-up ● ● ● ● ● _● ● 0 10000 20000 30000 0 50 100 Number of cores

Running time (sec.)

● Flame FPMAS RHPC

(b) Running time

Figure 3.20 – Extensibilité et temps d’exécutions pour les plateformes FractalPMAS, Repas- tHPC et FLAME avec le modèle de référence de 2 à 128 cœurs pour 200 pas de temps

En ce qui concerne FPMAS elle est au dessus des autres plateformes pour des exécutions avec plus 100 cœurs. Nous obtenons cependant, un meilleur speed-up avec ce modèle qu’avec le proie- prédateur. Cela nous permet de valider notre approche basé sur les Nested Graph pour modéliser

les simulations multi-agents.

Comme la plateforme FPMAS n’est qu’à l’état de preuve de concept, il reste probablement encore beaucoup d’optimisations à effectuer. Cependant, il est encourageant de noter que FP- MAS surpasse les autres plateformes lors de l’utilisation de plus de 100 cœurs. Cela signifie que notre approche de Nested Graph est adaptée pour les implémentations parallèles de simulations multi-agents.

Après avoir expliqué les différents principes utilisés pour modéliser, distribuer et exécuter notre simulation sur plusieurs processus, nous abordons les problèmes de cohérences de données, ou plutôt d’accès concurrents inhérents aux systèmes parallèles, dans le chapitre suivant où nous détaillons l’impact de la synchronisation sur l’exécution des modèles multi-agent parallèle.

Chapitre 4

Les pistes de synchronisation et leurs

impacts sur les modèles

Sommaire

4.1 Quand synchroniser ? . . . 84 4.2 Analyse des modèles . . . 85 4.3 Les politiques de synchronisation . . . 86 4.4 Expérimentations . . . 88 4.4.1 Analyse de l’extensibilité . . . 88 4.4.2 Analyse de la montée en charge . . . 93 4.4.3 Analyse de l’impact de la synchronisation sur les résultats . . . 95 4.5 Discussion . . . 98

Pour simuler plusieurs centaines de milliers d’agents, et donc des millions d’interactions entre agents, il est nécessaire de distribuer la simulation multi-agents afin de l’exécuter sur plusieurs processus. L’une des manières pour l’effectuer est d’utiliser une politique de synchronisation forte (Strong Synchronisation). Mais cette synchronisation implique un coût en communications pour maintenir les processus dans état cohérent qui a un impact direct sur les temps d’exécution des simulations. Cette synchronisation forte permet d’éviter les problèmes de cohérence de don- nées ou d’accès concurrents inhérents aux systèmes parallèles (HPC), les systèmes multi-agents parallèles sont donc soumis aux mêmes règles.

La synchronisation semble être un des points clefs pour une exécution efficace d’une simu- lation multi-agents parallèle du fait des nombreux échanges et dépendances temporelles qu’elle induit. Notre objectif dans ce chapitre est donc d’étudier l’impact de la synchronisation sur les temps d’exécution, mais aussi l’impact sur les résultats de simulations si nous relaxons la synchronisation dans les simulations. En effet, la synchronisation mise en place lors de l’implé- mentation dépend du modèle lui-même. Par exemple, si nous implémentons un modèle où les agents n’ont pas d’interaction, directe ou indirecte (à travers l’environnement), alors aucune synchronisation n’est nécessaire. D’autre part, les systèmes multi-agents permettent l’émergence de comportements globaux basés sur les interactions entre les entités qui composent le modèle. Par conséquent, l’observation d’un phénomène s’effectue au niveau macroscopique et non micro- scopique. Étant donné que de grandes quantités d’agents sont simulées, on peut supposer que cette quantité d’agents compense les synchronisations erronées ou fausses.

Premièrement, le problème est de savoir si la quantité d’agents permet de compenser le manque de synchronisation en offrant des résultats avec une tendance macroscopique identique. Deuxièmement, nous cherchons à quantifier le surcoût du à la synchronisation.

Dans la suite de ce chapitre, nous abordons dans un premier temps, les points de synchronisa- tion nécessaires pour le bon déroulement d’une simulation agents parallèles, puis nous définissons plusieurs politiques de synchronisation afin d’évaluer leur impact sur les résultats et le temps d’exécution à l’aide d’expérimentations.

4.1

Quand synchroniser ?

La synchronisation dans une simulation distribuée a pour objectif de garantir l’accès à des données à jour mais aussi de garantir la cohérence des actions qui sont effectuées, c’est à dire que les règles du modèle à simuler soit respectées. Par exemple, dans le cas du modèle proie- prédateur, deux loups, ne peuvent pas manger le même mouton. Ceci est une violation des règles du modèle.

De manière générale il existe deux modes de fonctionnement de simulations : le mode Ghost et le mode non Ghost comme précédemment expliqué dans le Chapitre 1 à la section 1.2.2. Pour rappel, le mode Ghost consiste à utiliser les données calculées auparavant, au pas de temps ou à l’itération précédente, pour réaliser le calcul. Les résultats des calculs sont, eux, mémorisés dans une copie de travail. De ce fait, les processus sont obligés de conserver à la fois ces données calculées auparavant, le Ghost, et les résultats des calculs, la copie de travail. De cette manière, les informations du Ghost ne sont accessibles qu’en lecture et ne sont pas les dernières valeurs calculées. Dans le cadre des systèmes multi-agents, l’utilisation d’un modèle Ghost est possible uniquement avec certains modèles. Les modèles concernés sont ceux ne nécessitant pas d’écriture. En effet, utiliser le mode Ghost avec des écritures n’a que peu de sens car cela conduirait à la situation énoncée précédemment pour le modèle proie-prédateur : deux loups pourraient manger la même proie. En contraste, le mode non Ghost consiste à ne disposer que d’une seule instance des données, dans laquelle les résultats sont directement reportés. De ce fait certains calculs sont réalisés directement avec la version des données calculée lors du pas de temps ou de l’itération courante. Avec ce mode, les informations sont accessibles en lecture et en écriture mais nécessitent des mécanismes de synchronisation pour les données détenues par d’autres processus. Pour les simulations multi-agents parallèles, plusieurs points de synchronisation sont donc nécessaires au bon déroulement de la simulation qui sont les suivants :

La fin d’un pas de temps : lorsque l’on exécute la simulation en parallèle, chaque pas de temps est exécuté par tous les processus qui participent à la simulation. A la fin de chaque pas de temps une étape de synchronisation est nécessaire pour garantir que chaque processus exécute le même pas de temps et le même point de synchronisation.

La migration d’un agent : lorsqu’un agent doit se déplacer d’un processus à un autre pour continuer à exécuter ses comportements, une synchronisation est nécessaire pour migrer l’agent. En effet, le fait de transférer des données d’un processus à un autre implique que chaque processus doit exécuter le même pas de temps. De ce fait, une synchronisation dans la partie où l’on effectue la migration des données est nécessaire pour garantir que les processus concernés sont dans le même état.

La mise à jour des zones de recouvrement : pour garder la continuité des champs de per- ception des agents lors de la distribution de l’environnement sur plusieurs processus, un point de synchronisation est obligatoire pour mettre à jour les zones de recouvrement. Ces zones sont composées d’une copie partielle des cellules voisines. Lors de la mise à jour de ces zones de re- couvrement, la synchronisation permet de garantir, de la même manière que pour la migration, que les différents processus concernés exécutent bien le même pas de temps et le même point de

synchronisation.

Ces trois points de synchronisation, sont nécessaires au bon déroulement d’une simulation agent parallèle qu’elle soit en mode Ghost ou non Ghost. Cependant, pour le mode non Ghost, ces points de synchronisation ne sont pas suffisants car ils ne permettent pas de gérer les écritures dans les zones de recouvrement. En effet, lors de l’exécution d’une simulation en mode Ghost, les actions du pas de temps n sont effectuées sur les données obtenues au pas de temps n − 1 c’est à dire au pas de temps précédent, les problèmes d’écritures ne sont donc pas à gérer. En revanche, dans une simulation en mode non Ghost, les calculs sont effectués sur les données courantes, c’est à dire au pas de temps n. L’accès aux données doit être géré pour garantir qu’aucune incohérence (ou biais) n’est injectée dans la simulation et que les informations sont à jour. Dans les modèles agents, il existe des modèles qui nécessitent uniquement de la lecture, d’autres de la lecture et de l’écriture. Nous analysons les différents types de modèles dans la section suivante.