Methodologie pour la modelisation et l’implementation

de simulations multi-agents utilisant le GPGPU

Emmanuel Hermellin, Fabien Michel

To cite this version:

Emmanuel Hermellin, Fabien Michel. Methodologie pour la modelisation et l’implementation desimulations multi-agents utilisant le GPGPU. JFSMA: Journees Francophones sur les SystemesMulti-Agents, Sep 2016, Saint-Marin du Vivier, France. Cepadues, 24e Journees Francophonessur les Systemes Multi-Agents, 2016, <http://jfsma2016.litislab.fr/>. <lirmm-01377521>

HAL Id: lirmm-01377521

https://hal-lirmm.ccsd.cnrs.fr/lirmm-01377521

Submitted on 7 Oct 2016

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinee au depot et a la diffusion de documentsscientifiques de niveau recherche, publies ou non,emanant des etablissements d’enseignement et derecherche francais ou etrangers, des laboratoirespublics ou prives.

Méthodologie pour la modélisation etl’implémentation de simulations multi-agents utilisant

le GPGPUE. Hermellina

hermellin@lirmm.frF. Michela

fmichel@lirmm.fr

aLaboratoire Informatique Robotique et Microéléctronique de Montpellier (LIRMM),Université de Montpellier, France

RésuméL’utilisation du GPGPU (General-Purposecomputing on Graphics Processing Units) dansle cadre de la simulation multi-agent permet delever, en partie, les contraintes liées au passageà l’échelle. Cependant, à cause de l’architecturemassivement parallèle des GPU (Graphics Pro-cessing Units) sur laquelle repose le GPGPU,les modèles voulant bénéficier des avantages decette technologie doivent être adaptés au préa-lable. Prenant le parti de ne pas suivre le cou-rant actuel qui vise à rendre transparent l’uti-lisation du GPGPU dans le but de simplifierson usage, le principe de délégation GPU pro-pose plutôt de transformer un modèle afin qu’ilbénéficie des avantages du GPGPU mais sanscacher la technologie utilisée. Dans cet article,nous présentons une méthodologie basée sur ladélégation GPU pour le développement de si-mulations multi-agents. L’idée est de proposerune généralisation du processus d’applicationdu principe de délégation GPU que nous expéri-menterons ensuite sur deux cas d’études afin dedéfinir quels sont les avantages et limites d’unetelle approche.Mots-clés : Simulation multi-agent, GPGPU,Méthodologie, Délégation GPU

AbstractUsing General-Purpose computing on GraphicsProcessing Units (GPGPU) in Multi-Agent Ba-sed Simulation (MABS) appears to be very pro-mising as it allows to use the massively parallelarchitecture of the GPU (Graphics ProcessingUnits) to improve the scalability of MABS mo-dels. However, this technology relies on a highlyspecialized architecture, implying a very speci-fic programming approach. So, it turns out thatMAS models need to be adapted if they wantto benefit from GPU power. Contrary to somerecent research works that propose to hide GPUprogramming to ease the use of GPGPU, wepresent in this paper a methodology for mode-ling and implementing MABS using GPU pro-

gramming. The idea is to be able to consider anykind of MABS rather than addressing a limitednumber of cases. This methodology defines theiterative process to be followed to transform andadapt a model so that it takes advantage of theGPU power without hiding the underlying tech-nology. We experiment this methodology on twoMABS models to test its feasibility and highlightthe advantages and limits of this approach.Keywords: MABS, GPGPU, Methodology, GPUdelegation

1 Introduction

Dans le cadre de la simulation multi-agent, lepassage à l’échelle et les performances d’exé-cution représentent souvent des obstacles qui li-mitent fortement le cadre dans lequel un modèlepeut être étudié [12].

Par ailleurs, le GPGPU (General-Purpose com-puting on Graphics Processing Units) est au-jourd’hui reconnu comme un moyen efficaced’accélérer les logiciels qui nécessitent beau-coup de puissance de calcul [3]. Cependant,dans le cadre des simulations multi-agents, l’uti-lisation de cette technologie apparait comme as-sez difficile car elle repose sur l’architecturemassivement parallèle des GPU (Graphics Pro-cessing Units) qui s’accompagne d’un contextede développement très spécifique. Ainsi, pourêtre efficiente, une implémentation utilisant leGPGPU exige que le modèle considéré soitau préalable adapté voire transformé. En effet,alors que la simulation multi-agent (et plus gé-néralement les systèmes multi-agents) utilisentfréquemment des fonctionnalités de la program-mation orientée objet, ces dernières ne sont plusdisponibles dans un contexte de programmationGPU [2, 11]. De nombreux travaux se sont doncintéressés à la simplification du GPGPU dans lecontexte des simulations multi-agents.

Parmi ces travaux, la plupart d’entre eux ont

choisi de le faire au travers d’une utilisationtransparente de cette technologie. Cependant,cette approche nécessite d’abstraire un certainnombre de parties du modèle agent, ce qui limitele champ d’application des solutions proposéescar elles reposent sur des éléments de modéli-sation prédéfinis (e.g. Flame GPU contient desprimitives agents pré-programmés [15]).

Afin d’offrir une approche plus générique, nousavons étudié le principe de délégation GPUcomme solution d’implémentation pour des si-mulations multi-agents voulant bénéficier duGPGPU [6]. Ce principe repose sur une uti-lisation directe du GPGPU qui se fait au tra-vers d’une adaptation et transformation du mo-dèle considéré. Prenant le parti de ne pas ca-cher la technologie sous-jacente, les différentscas d’études menés sur ce principe [10, 5, 6] ontconfirmé les avantages conceptuels d’une telleapproche ainsi que les bénéfices en terme deperformance.

L’objectif de cet article est de proposer une gé-néralisation du principe de délégation GPU sousla forme d’une méthodologie. Pour ce faire,nous allons dans un premier temps résumer tousles cas d’études basés sur le principe de délé-gation GPU pour ensuite s’intéresser à la défi-nition de la méthodologie. Ensuite, nous propo-sons de l’expérimenter sur deux nouveaux mo-dèles afin de souligner ses avantages et ses li-mites. La section 2 propose un retour d’expé-rience et une analyse du principe de délégationGPU. La section 3 introduit la méthodologie ba-sée sur ce principe. La section 4 expérimentecette méthodologie sur deux nouveaux modèles.La section 5 conclut l’article et énonce les pers-pectives de recherche associées.

2 Le principe de délégation GPU

2.1 Énoncé du principe

Inspiré d’autres travaux liés au génie logicielorienté agent, le principe de délégation GPU uti-lise l’environnement comme une abstraction depremier ordre [17] et arbore un point de vueenvironnement-centré. Ainsi, à l’instar d’autresapproches telles que EASS (Environment As Ac-tive Support for Simulation) [1], IODA (Interac-tion Oriented Design of Agent simulations) [8]et l’approche des artefacts [14], la délégationGPU consiste à réifier une partie des calculs ef-fectués dans le comportement des agents dansde nouvelles structures (e.g. dans l’environne-

ment) dans le but de répartir la complexité ducode et de modulariser son implémentation.

Proposé dans [10], le principe de délégationGPU est basé sur une approche hybride (CPU+ GPU) et vise à répondre, en partie, aux diffi-cultés occasionnées par le GPGPU [7]. En effet,les spécificités de la programmation GPU ainsique l’architecture matérielle sur laquelle elle re-pose font qu’il est très difficile d’implémenterune simulation multi-agents sur GPU. Surtout sion considère comme essentiel des aspects telsque l’accessibilité, la généricité et la reutilisa-bilité. D’ailleurs, [13] conclut dans son étudequ’une recherche de performance pure ne peutse faire qu’au détriment de ces aspects dans uncontexte GPGPU.

Avec pour objectif d’obtenir des gains de perfor-mances grâce au GPU mais aussi pour conser-ver l’accessibilité et la facilité de réutilisationd’une interface de programmation orientée ob-jet, le principe de délégation GPU consiste enla réalisation d’une séparation explicite entre lecomportement des agents, géré par le CPU, etles dynamiques environnementales traitées parle GPU. En effet, la spécificité du GPGPU faitque les comportements des agents sont difficilesà traduire en code GPU car ils comportent gé-néralement de nombreuses structures condition-nelles qui ne sont pas adaptées à la program-mation sur GPU. Au contraire, les calculs cor-respondant à l’application des dynamiques envi-ronnementales se prêtent beaucoup mieux à uneparallélisation sur architecture parallèle car ilsconsistent généralement à appliquer de manièreuniforme un calcul dans tout l’environnement.

Ainsi, l’idée sous-jacente est d’identifier dansle modèle agent des calculs qui peuvent êtretransformés en dynamiques environnementalesafin qu’ils puissent bénéficier de la puissancedu GPU. Le principe de délégation GPU peutêtre énoncé de la manière suivante : "Tout calculde perception agent qui n’implique pas l’état del’agent peut être transformé en une dynamiqueendogène de l’environnement, et ainsi considérépour une implémentation dans un module GPUindépendant".

2.2 Retour d’expérience

Le principe de délégation GPU a été appliquépour la première fois sur un modèle d’émer-gence multi-niveaux (MLE) 1[10]. Cette expéri-mentation a rempli deux objectifs : (1) garderl’accessibilité du modèle agent dans un contexte

GPU (le modèle originel n’a pas été modifié)et (2) augmenter la taille de l’environnementainsi que le nombre d’agents. Cette étude a aussimontré que la délégation GPU permet d’aborderla question de la généricité en favorisant la réuti-lisation des modules GPU créés, car ils peuventêtre réutilisés dans d’autres contextes.

Suite à ces premiers résultats, la délégation GPUa été appliquée sur le modèle des boids de Rey-nolds 1 [5] dans le but de mettre à l’épreuve lafaisabilité et la généricité de l’approche. Ce casd’étude a montré que la délégation GPU permetde prendre en compte des modèles très diffé-rents et a occasionné une évolution du critèrede sélection du principe. En effet, lors de cetteexpérimentation, nous avons vu qu’il est aussipossible d’identifier des calculs de perceptionsne modifiant pas les états des agents. Ces der-niers peuvent être transformés en dynamiquesenvironnementales et donc considérés pour uneimplémentation en module GPU.

Pour continuer d’expérimenter ce principe, il aensuite été appliqué sur quatre autres modèles(Game of Life, Schelling’s segregation, Fire etDLA) 1 [6] . Cette expérimentation a soulignéune nouvelle fois la capacité de réutilisation desmodules GPU produits par le principe de délé-gation GPU : il a été possible de réutiliser desmodules GPU issus des précédents cas d’études.De plus, grâce à la modularité apportée par l’ap-proche hybride utilisée, les modules GPU créésreposent sur des kernels 2 très simples (compor-tant seulement quelques lignes de code dans laplupart des cas) améliorant de ce fait l’accessi-bilité du GPGPU.

2.3 Bilan actuel

Toutes les applications du principe de déléga-tion GPU ont mené à des diminutions du tempstotal d’exécution et cela quelque-soit le mo-dèle considéré. De plus, au-delà des gains deperformance obtenus, ces expérimentations ontconfirmé les avantages de l’approche par rap-port à des aspects souvent négligés dans le cadrede l’utilisation du GPGPU pour les simulationsmulti-agents.

Ainsi, au vu de ces différentes preuves deconcept, le principe de délégation a rempli sesobjectifs initiaux tant d’un point de vue des

1. http://www.lirmm.fr/~hermellin/Website/simu.html

2. Un kernel est un noyau de calcul exécuté par le GPU.

performances que d’un point de vue concep-tuel en améliorant l’accessibilité, la généricité etla réutilisabilité des outils créés. Pourtant, ellesfont également apparaître quelques autres ques-tions, dont nous rediscuterons, telles que la dif-ficulté de mise en œuvre pour un utilisateur no-vice en GPGPU ou bien sur quels types de mo-dèles la délégation GPU pourrait être appliquée.

2.4 Vers une généralisation de l’approche

Sur ces différents cas d’études, le principe dedélégation GPU a été appliqué de manière adhoc : l’objectif était de réaliser des preuvesde concepts. Cependant, durant ces différentesexpérimentations, nous avons observé une ré-currence dans le processus d’implémentation.L’objectif de cet article est donc de généraliserce processus d’adaptation afin de proposer uneméthodologie basée sur la délégation GPU pourle développement de simulations multi-agents.

En plus d’améliorer le champ d’application duprincipe, cette méthodologie a pour objectifsde : (1) simplifier l’utilisation du GPGPU dansle contexte des simulations multi-agents en dé-crivant le processus de modélisation et d’implé-mentation à suivre, (2) définir une approche gé-nérique pouvant être appliquée sur une grandevariété de modèles, (3) promouvoir la réutili-sabilité des outils créés ou des modèles trans-formés (par exemple en réutilisant les modulesGPU déjà développés) et (4) aider les utilisa-teurs potentiels à décider s’ils peuvent bénéfi-cier du GPGPU compte tenu de leurs modèles.

3 Définition de la méthodologie

De la généralisation du processus d’applicationet d’implémentation du principe de délégationGPU, nous avons extrait une méthodologie di-visée en 5 phases distinctes (voir figure 1) :

1. La première étape consiste en la décomposi-tion de tous les calculs qui sont utilisés dans lemodèle.

2. La deuxième étape consiste à identifier, parmiles calculs précédemment listés, ceux répondantaux critères du principe de délégation GPU.

3. La troisième étape consiste à vérifier si lescalculs identifiés comme compatibles avec leprincipe de délégation GPU ont déjà été trans-formés en dynamiques environnementales etdonc si il existe un module GPU dédié pouvantêtre réutilisé.

FIGURE 1 – Diagramme de la méthodologie

4. La quatrième étape consiste à établir la com-patibilité des calculs sélectionnés avec l’archi-tecture d’un GPU. L’idée étant de choisir etd’appliquer le principe de délégation unique-ment sur les calculs qui vont apporter le plus degain une fois traduits en modules GPU.

5. La cinquième étape consiste à implémenterconcrètement le principe de délégation GPU surles calculs respectant l’ensemble des contraintesprécédentes.

3.1 Étape 1 : décomposition des calculs

Cette phase consiste à décomposer tous les cal-culs qui sont utilisés par le modèle. L’intérêtd’une telle décomposition réside dans le faitqu’un certain nombre de calculs présents dansle modèle ne sont pas explicites. Expliciter lescalculs nécessaires à la réalisation des diffé-rents comportements des agents, en les décom-posant en le plus de primitives possibles, va per-mettre d’augmenter l’efficacité de l’applicationdu principe de délégation GPU sur le modèleconsidéré. En effet, l’intérêt d’une telle décom-position permet de ne pas avoir un seul "gros"kernel contenant tous les calculs GPU, mais decapitaliser sur l’aspect modulaire et hybride duprincipe de délégation GPU avec plusieurs ker-nels très simples mais qui tirent partis de la dé-composition des calculs : chaque calcul (com-patible) peut alors prétendre à avoir son propre

kernel. Ainsi, la délégation GPU sera d’au-tant plus efficace qu’il va être possible de dé-composer le modèle en calculs "élémentaires".D’ailleurs, dans le contexte de l’utilisation duGPGPU pour les simulations multi-agents, cettedécomposition des actions a également été iden-tifiée comme cruciale dans [4]. En introduisantune nouvelle division des actions des agents quilimite les accès concurrents aux données, [4]montre qu’il a été possible d’augmenter signi-ficativement les performances globales des mo-dèles qui utilisent le GPGPU.

3.2 Étape 2 : identification des calculs com-patibles

L’identification des calculs compatibles est uneétape essentielle car elle consiste à vérifier quelssont les calculs qui répondent aux critères duprincipe de délégation GPU et qui pourront ainsibénéficier du GPGPU. Les calculs sont identi-fiés comme compatibles si :

- Pour l’environnement : si l’environnementn’est pas statique et qu’il contient des dyna-miques, ces dernières doivent (1) ne pas conte-nir de processus décisionnels, (2) s’appliquersur tout l’environnement et (3) avoir un impactglobal 3. Dans ce cas, leur compatibilité est éta-

3. L’impact des dynamiques est un paramètre important. Prenonsl’exemple d’une dynamique environnementale qui consiste à faire appa-

blie et leur traduction en modules GPU est pos-sible et pertinente.

- Pour les agents : si des calculs de percep-tions ne modifient pas les états des agents, ilspeuvent être considérés comme compatibles ettransformés en dynamiques environnementalespour être implémentés dans des modules GPUindépendants. L’idée est de transformer un cal-cul de perception réalisé de manière locale enune dynamique environnementale s’appliquantglobalement dans l’environnement.

Si aucune partie du modèle n’est conforme auxcritères d’application du principe de délégationGPU, il est inutile de continuer à suivre cetteméthodologie car, dans un tel cas, les gains ap-portés par le GPGPU pourraient être insigni-fiants voire même négatifs (voir [9]).

3.3 Étape 3 : réutilisation des modules GPU

Un des objectifs de la méthodologie est depromouvoir la réutilisabilité des modules GPUcréés. En effet, comme vu précédemment, leprincipe de délégation GPU sur lequel se basela méthodologie, se distingue par la création demodules GPU génériques pouvant être réutili-sés dans des contextes différents de ceux pourlesquels ils ont été créés. Ainsi, il convient devérifier que les calculs sélectionnés n’aient pasdéjà un module GPU dédié. Si c’est le cas, il estpossible de passer directement à l’étape 5 afind’adapter les structures de données au moduleexistant.

3.4 Étape 4 : évaluation de l’adaptation descalculs sur l’architecture des GPU

Avant d’appliquer concrètement la délégationGPU sur les calculs identifiés comme compa-tibles, il est nécessaire d’évaluer si ces calculsvont pouvoir s’adapter à l’architecture massive-ment parallèle des GPU. Ainsi, la compatibilitéd’un calcul avec les critères du principe de délé-gation GPU n’implique pas forcement une amé-lioration des performances une fois ce principeappliqué. Il est donc nécessaire d’évaluer empi-riquement la pertinence d’appliquer la déléga-tion GPU sur les calculs identifiés.

Cette phase de vérification peut être réalisée enrépondant à trois questions :raitre de manière stochastique dans l’environnement, à chaque x pas detemps, une source de nourriture à une position donnée. Cette dynamiqueva bien s’appliquer sur tout l’environnement mais ne va avoir qu’un im-pact très localisé. Dans ce cas, traduire cette dynamique dans un moduleGPU n’est pas justifié car les gains espérés seront nuls (voir négatifs).

Est-ce que les calculs identifiés vont pouvoirêtre distribués sur le GPU ?En effet, les calculs doivent être indépendants etsimples et ne pas contenir de trop nombreusesstructures conditionnelles, ces dernières pou-vant causer des problèmes de divergence desthreads ou des ralentissements lors de l’exécu-tion. Des calculs contenant des boucles itéra-tives s’adaptent mieux aux architectures paral-lèles [16].

Est-ce que les calculs identifiés sont réalisés demanière globale (par un grand nombre d’agentsou appliqués sur un grand nombre de cellules del’environnement) ?En raison des coûts très élevés (en temps) qu’oc-casionnent les transferts de données entre GPUet CPU, des calculs rarement utilisés vont ac-croitre le temps de calcul général du modèle.

Est-ce que les structures de données associéesaux calculs identifiés vont pouvoir s’adapteraux contraintes d’une utilisation sur GPU ?En l’occurrence, il s’agit principalement des’assurer que les données peuvent être distri-buées sur le GPU (en tenant compte des spéci-ficités des différents types de mémoire) et trai-tées avec un degré élevé d’indépendance afind’avoir une implémentation GPU efficace ([2]donne plus d’informations sur cet aspect).

Pour donner un exemple, en se basant sur nosdifférents cas d’étude, il est possible d’utili-ser, dans le cas d’environnements discrétisés,des structures de données (des tableaux parexemple) de la taille de l’environnement ce quiles rend très adaptées à l’architecture du GPU.En effet, chaque cellule de l’environnement auraainsi un thread qui lui sera entièrement dédié.La figure 2 illustre comment ces structures dedonnées peuvent être utilisées lors d’une appli-cation du principe de délégation GPU sur unmodèle possédant un environnement discrétisé.

3.5 Étape 5 : implémentation

Les calculs étant identifiés, sélectionnés et éva-lués, il convient d’appliquer sur chacun d’entreeux la délégation GPU. Cette application est di-visée en trois étapes :

1. Création des modules GPU ;2. Adaptation des structures de données ;3. Création des interfaces entre la partie

CPU du modèle et les modules GPU.L’application de la délégation GPU commencepar la création des modules GPU contenant les

FIGURE 2 – Structuration et utilisation des données pour un environnement discrétisé

kernels de calculs (la traduction des calculs sé-quentiels en version parallèle). Grâce à la dé-composition effectuée précédemment, ces ker-nels ne nécessitent que peu de connaissancesen GPGPU et tiennent en seulement quelqueslignes de code. En général, ces modules sontdivisés en quatre parties : (1) initialisation duthread qui va servir au calcul, (2) test condition-nel sur la position du thread dans la grille glo-bale du GPU pour l’accès aux données corres-pondantes, (3) réalisation du calcul et (4) écri-ture du résultat dans le tableau correspondant(e.g. voir [6]).

Ensuite, les structures de données doivent êtreadaptées aux modules GPU créés. Cette adapta-tion est basée sur la nature des calculs effectuéset sur le type d’environnement utilisé (des ta-bleaux correspondant à la discrétisation de l’en-vironnement sont le plus souvent utilisés).

Enfin, ces nouveaux éléments doivent être inté-grés et reliés à la partie CPU du modèle. Pour cefaire, de nouvelles versions des fonctions de per-ceptions qui encapsulent l’utilisation du GPUdoivent être créées pour permettre aux agents età l’environnement de recueillir et d’utiliser lesdonnées calculées par les modules GPU. La plu-part du temps, ces fonctions sont de simples pri-mitives d’accès aux données.

4 Expérimentation

Dans cette section, nous expérimentons la mé-thodologie proposée sur les modèles Heatbugset Proie/Prédateur. L’application de la métho-dologie sur le modèle Heatbugs est détailléeétape par étape avec, à la fin, des résultats deperformance. Quant à l’application sur le mo-dèle Proie/Prédateur, elle se concentre principa-lement sur certains aspects de la méthodologiequi nécessitent des améliorations. Nous com-mençons par présenter quelques notions de baserelatives à la programmation GPU.

4.1 Notions relatives au GPGPU

Pour comprendre le principe de programma-tion associé au GPGPU, il faut avoir à l’espritqu’il est fortement lié à l’architecture matériellemassivement multicœurs des GPU. Pour utili-ser les capacités GPGPU de notre carte gra-phique, nous utilisons CUDA 4 (Compute Uni-fied Device Architecture, l’interface de program-mation dédiée fournie par Nvidia) et JCUDA 5,une librairie permettant d’utiliser CUDA au tra-vers de Java. La philosophie de fonctionnementde cette interface de développement est la sui-vante : le CPU (host) gère la répartition desdonnées et exécute les kernels : des fonctionsspécialement créées pour s’exécuter sur le GPU(device). Le GPU est capable d’exécuter unkernel de manière parallèle grâce aux threads.Ces threads sont regroupés par blocs (les pa-ramètres blockDim.x, blockDim.y définissent lataille de ces blocs), qui sont eux-mêmes rassem-blés dans une grille globale. Chaque thread ausein de cette structure est identifié par des coor-données uniques 3D (threadIdx.x, threadIdx.y,threadIdx.z) lui permettant d’être localisé. Dela même façon, un bloc peut être identifié parses coordonnées dans la grille (respectivementblockIdx.x, blockIdx.y, blockIdx.z). Les threadsexécutent le même kernel mais traitent des don-nées différentes selon leur localisation spatiale.Dans la suite de ce document, les identifiantsdes threads dans la grille globale du GPU se-ront notés i et j (environnements 2D).

4.2 Le modèle Heatbugs

Dans le modèle Heatbugs, les agents tententde maintenir une température optimale autourd’eux. Plus précisément, les agents se déplacentdans un environnement 2D discrétisé en cel-lules. Un agent ne peut pas occuper une cellule

4. e.g. https ://developer.nvidia.com/what-cuda5. e.g. http ://www.jcuda.org

déjà occupée par un autre agent. Un agent émetde la chaleur qui se diffuse dans l’environne-ment. Enfin, chaque agent possède une tempéra-ture idéale qu’il cherche à atteindre. Ainsi, plusla température de la case sur laquelle il se trouveva être différente de sa température idéale etplus l’agent va être mécontent. Lorsque un agentn’est pas satisfait (sa case est trop froide ou tropchaude), il se déplace aléatoirement pour trou-ver une meilleur place. La figure 3 résume cescomportements.

FIGURE 3 – Comportement des agents dans lemodèle Heatbugs

Application de la méthodologie.Étape 1 : décomposition.- Dans l’environnement : diffusion de la chaleur(C1).- Pour les agents : déplacement (C2), émissionde chaleur (C3), calcul des différences de tem-pérature (C4) et calcul du bonheur (C5).

Étape 2 : identification.C1 est une dynamique globale de l’environne-ment, elle est donc compatible et peut être im-plémentée dans un module GPU. C4 consisteà percevoir la température de la case sur la-quelle se trouve l’agent et calculer la différenceentre cette température et la température idéalede l’agent. Ce calcul ne modifie pas les états del’agent, il est donc compatible et peut être trans-formé en une dynamique environnementale. C2,C3 et C5 modifient les états des agents, nous neles considérerons donc pas pour la suite.

Étape 3 : réutilisation.C1 est un calcul de diffusion et a déjà été ef-fectué dans le modèle Fire [6], nous réutilisonsdonc le module GPU correspondant.

Étape 4 : compatibilité.Au contraire de C1, C4 est réalisé pour la pre-mière fois, nous devons donc effectuer cettephase de vérification. Ainsi, C4 consiste en la

réalisation d’une différence, il peut être facile-ment distribué sur la grille de threads du GPU.De plus, tous les agents calculent cette diffé-rence à chaque pas de simulation. Transformerce calcul est donc pertinent car réalisé de trèsnombreuses fois. Enfin, les données utiliséespour ce calcul peuvent être stockées dans destableaux à deux dimensions s’adaptant parfaite-ment aux contraintes des architectures GPU.

Étape 5 : implémentation.Pour C1, nous utilisons le tableau 2D déjà dé-fini contenant la chaleur pour chaque cellule. Ilest ensuite envoyé au GPU qui calcule simulta-nément la diffusion de la chaleur sur tout l’envi-ronnement. Plus précisément, pour chaque cel-lule, un thread calcule la somme de la chaleurdes cellules voisines qui est ensuite modulée parune variable de diffusion. L’algorithme 1 pré-sente l’implémentation du kernel de calcul cor-respondant.

Algorithme 1 : Kernel : diffusion de la chaleurentrées : width, height, heatArray, radiussortie : resultArray (la quantité de chaleur)

1 i = blockIdx.x ∗ blockDim.x+ threadIdx.x ;2 j = blockIdx.y ∗ blockDim.y + threadIdx.y ;3 sumOfHeat = 0 ;4 si i < width et j < height alors5 sumOfHeat = getNeighborsHeat(heatArray[i, j], radius);6 fin7 resultArray[i, j] = sumOfHeat ∗ heatAdjustment ;

Après l’exécution de ce kernel, la chaleur dechaque cellule est utilisée pour calculer la diffé-rence entre cette valeur et la température idéalede l’agent qui se trouve sur la cellule. Pour cefaire, chaque agent dépose, en fonction de sa po-sition, sa température idéale dans un tableau 2D(correspondant à la taille de l’environnement).Les deux tableaux sont envoyés au GPU qui ef-fectue le calcul de la différence. L’algorithme2 présente l’implémentation du calcul dans unkernel. Les agents utilisent ces résultats pourcalculer leur valeur de bonheur, donc à partird’une perception qui est précalculée par un ker-nel GPU.

Algorithme 2 : Kernel : calcul de différenceentrées : width, height, heatArray, idealTemperatureArraysortie : resultArray (la différence de température)

1 i = blockIdx.x ∗ blockDim.x+ threadIdx.x ;2 j = blockIdx.y ∗ blockDim.y + threadIdx.y ;3 diff = 0 ;4 si i < width et j < height alors5 diff = heatArray[i, j]− idealTemperatureArray[i, j];6 fin7 resultArray[i, j] = diff ;

Performance du modèle.Pour évaluer les performances, nous comparonsles exécutions CPU puis hybride du modèle 6.Pour chacune des versions, nous simulons plu-sieurs tailles d’environnement et avons fixé ladensité des agents à 40%. La figure 4 présenteles résultats obtenus.

256 512 1,024 2,048

0.9

0.95

1

1.05

Taille de l’environnement

Coe

f.de

perf

orm

ance

Comportement des agents

256 512 1,024 2,048012345678

Taille de l’environnement

Coe

f.de

perf

orm

ance Dynamiques environnementales

FIGURE 4 – Coefficient d’accélération entre uneexécution CPU et hybride du modèle Heatbugs

De ces graphiques, nous notons que le gainobtenu pour le calcul de l’environnement estd’autant plus important que l’environnement estgrand. Cependant, le gain correspondant au cal-cul des agents reste faible (environ 5%). Nousexpliquons ces résultats de la façon suivante :la dynamique de diffusion (C1) est appliquéeà toutes les cellules alors que seule une petitepartie des calculs effectués par les agents a ététransformée (C4).

4.3 Le modèle Proie/Prédateur

Dans notre modèle Proie/Prédateur, les agentsévoluent dans un environnement 2D discrétiséen cellules. Les prédateurs, tout comme lesproies, sont placés aléatoirement. Tous les pré-dateurs possèdent un champ de vision (Field Of

6. Notre configuration de test est composée d’un processeur IntelCore i7 (génération Haswell, 3.40GHz) et d’une carte graphique NvidiaQuadro K4000 (768 cœurs).

FIGURE 5 – Comportement des agents dans lemodèle Proie/Prédateur

View, FOV) de dix cellules autour d’eux. Si uneproie se trouve dans ce FOV, ils la ciblent et sedirigent vers elle, sinon ils se déplacent aléatoi-rement. Les proies se déplacent aussi de manièrealéatoire. Lorsqu’un prédateur se trouve dans leFOV d’une proie (qui est de 6), cette dernièretente de s’échapper en s’enfuyant dans la direc-tion opposée. Une proie meurt quand elle estciblée par un prédateur et quand ce dernier setrouve sur la même case qu’elle. La figure 5 ré-sume ces comportements.

Application de la méthodologie.Étape 1 : décomposition.- L’environnement est statique et ne possède au-cune dynamique environnementale ;- Agents : les prédateurs (C1) déterminent la di-rection vers la proie la plus proche et (C2) sedéplacent. Les proies (C3) calculent leur direc-tion de fuite et (C4) se déplacent.

Étape 2 : identification.C1 et C3 consistent à calculer la direction defuite des proies face aux prédateurs (C1) et ladirection vers la proie ciblée pour les préda-teurs (C3). Ces deux calculs peuvent être penséscomme une perception pré-calculée par une dy-namique environnementale. Dans ce cas, cettedynamique calculera pour chaque cellule del’environnement les directions vers les proies etles prédateurs les plus proches mais aussi les di-rections opposées. La transformation de ces cal-culs en dynamiques environnementales traitéespar un module GPU est possible car ces modulesne modifient pas les états des agents.

Étape 3 : réutilisation.Concernant C1 et C3, il est possible de réutili-ser le module GPU field perception créé pour lemodèle MLE [10]. En effet, ce module calculepour chaque cellule la direction vers des cel-lules voisines possédant la plus grande / faiblequantité d’une variable donnée. Ce calcul est

similaire à C1 et C3 qui calculent les direc-tions maximum (direction d’interception) et mi-nimum (direction de fuite) vers des agents : lavariable donnée est donc ici l’orientation desagents.

Étape 4 : compatibilité.Vu que nous réutilisons un module déjà exis-tant et qu’aucun nouveau calcul n’a été identifiécomme compatible, nous pouvons directementpasser à l’étape 5.

Étape 5 : implémentation.Pour implémenter le module dédié à C3, deuxtableaux 2D sont utilisés : chacun dédié a untype d’agent et contenant une marque de pré-sence (plus il y a d’agents et plus la marque estforte. Ils sont envoyés au GPU qui calcule res-pectivement la direction vers le prédateur le plusproche et la direction opposée pour chaque cel-lule de l’environnement. Les agents utilisent cesrésultats pour déterminer leur orientation et sedéplacer dans la bonne direction.

Performance du modèle.Avec ce modèle, et parce qu’il n’y a pas dedynamique environnementale, il est difficile dedire à l’avance quels vont être les gains de per-formance envisageables. En effet, les perfor-mances du modèle vont fortement dépendre dela configuration matérielle utilisée ainsi que descaractéristiques du modèle considéré, comme lenombre d’agents par exemple. Si ce nombre estfaible, le gain peut être négatif. En fait, noussommes ici confrontés au problème de l’éva-luation des performances : lorsqu’un modèle neprésente aucune dynamique environnementaleet que seuls des calculs de perceptions peuventêtre transformés, nous ne pouvons prévoir àl’avance si le modèle va bénéficier du GPGPUen terme de performances. Nous rediscutons decet aspect dans la section suivante.

Cependant, la figure 6 montre que pour ce mo-dèle les résultats obtenus sont très bons avec uneexécution jusqu’à 4 fois plus rapide comparée àla version séquentielle du modèle.

5 Conclusion et perspectives

Depuis son apparition, le GPGPU est considérécomme une technologie innovante profitant àde nombreux domaines où les temps de calculpeuvent être critiques (e.g. finance, physique,biologie, etc.). Cependant, dans le domaine dessimulations multi-agents (et plus généralementdes systèmes multi-agents), nous remarquons

256 512 1,024 2,0480

5001,0001,5002,0002,5003,0003,5004,0004,500

Taille de l’environnement

Tem

pspa

rité

r.[m

s] CPU Hybride

FIGURE 6 – Modèle Proie-prédateur, résultatsde performance (densité des agents : 20 %).

que cette technologie peine à s’imposer et celamalgré les besoins en puissance de calcul tou-jours plus importants. Des études ont montréque le manque d’accessibilité, de réutilisabilitéet de généricité pouvaient expliquer ce manqued’intérêt de la part de notre communauté [13].

Ainsi, depuis plusieurs années, nous présentonsdes travaux pour répondre à ces différents pro-blèmes. Présenté au départ sous la forme d’unprincipe de conception (le principe de déléga-tion GPU [10, 5]), nous avons proposé dans cetarticle une méthodologie utilisant ce principepour le développement de simulations multi-agents. Extraite de diverses expérimentations[6], l’objectif de cette méthodologie est de pro-mouvoir un cadre à l’utilisation de la program-mation GPU dans le contexte des simulationsmulti-agents tout en (1) ne cachant pas la tech-nologie utilisée à l’utilisateur et (2) mettant enavant un processus de modélisation itératif mo-dulaire prônant la réutilisabilité des outils créés.

Sur la base des deux expérimentations présen-tées dans cet article, nous avons vu qu’un desprincipaux avantages de notre méthodologie estl’accessibilité. En effet, il a été très facile, ensuivant la méthodologie, d’identifier des partiesdes différents modèles qui ont pu être transfor-mées pour bénéficier du GPGPU. De plus, cetteméthodologie produit des modules génériquesréutilisables (cf. section 4.3).

Un autre avantage de la méthodologie est sa po-lyvalence dans le sens où elle peut être appli-quée sur une grande variété de modèles, commele montre les différentes expérimentations me-nées jusqu’ici : MLE [10], les boids de Rey-nolds [5], Game Of Life et Schelling’s Segre-gation [6], Heatbugs, Proie/Prédateur, etc.

Cependant, il nous faut modérer ce dernier avan-

tage. S’il est vrai que nous avons appliqué ceprincipe sur une grande variété de comporte-ments, tous nos cas d’études ont porté sur desmodèles possédant un environnement discrétisépour lequel le principe de délégation GPU estfacilement applicable (en terme d’implémenta-tion). Ainsi, un de nos objectifs futurs sera deconsidérer d’autres types de modèle sur les-quels appliquer notre méthodologie (e.g. possé-dant des environnements continus) afin de ren-forcer son champ d’application.

Autre limite actuelle, il est pour l’instant diffi-cile d’évaluer précisément les gains de perfor-mance avant l’application de la méthodologie.En effet, même si un modèle valide la deuxièmeétape (éligibilité des calculs), les gains de per-formance peuvent ne pas être intéressants carces derniers dépendent fortement de la configu-ration matérielle utilisée ainsi que des caracté-ristiques du modèle considéré.

Une solution pourrait être de proposer un bench-mark qui permettrait de définir l’intérêt d’appli-quer notre méthodologie sur le modèle consi-déré en fonction du nombre d’agents et de laconfiguration matérielle utilisée. Ainsi, une desperspectives de recherche serait de développercette solution logicielle qui, une fois exécutée,donnerait ainsi une idée du seuil au-dessus du-quel une implémentation GPU pourrait être ef-ficiente. L’idée étant de proposer un outil im-plémentant un ensemble de fonctions agents ré-currentes réutilisant les modules GPU déjà créésgrâce à notre méthodologie.

Références[1] Fabien Badeig and Flavien Balbo. Définition

d’un cadre de conception et d’exécution pour lasim. multi-agent. Revue d’Intelligence Artificielle,26(3) :255–280, 2012.

[2] Mathias Bourgoin, Emmanuel Chailloux, and Jean-Luc Lamotte. Efficient Abstractions for GPGPUProgramming. International Journal of ParallelProgramming, 42(4) :583–600, 2014.

[3] Shuai Che, Michael Boyer, Jiayuan Meng, DavidTarjan, Jeremy W. Sheaffer, and Kevin Skadron. Aperformance study of general-purpose applicationson graphics processors using CUDA. Journal ofParallel and Distributed Computing, 68(10) :1370–1380, 2008.

[4] Simon Coakley, Paul Richmond, Marian Gheor-ghe, Shawn Chin, David Worth, Mike Holcombe,and Chris Greenough. Intelligent Agents in Data-intensive Computing, chapter Large-Scale Simula-tions with FLAME, pages 123–142. Springer Inter-national Publishing, Cham, 2016.

[5] Emmanuel Hermellin and Fabien Michel. Dé-légation GPU des perceptions agents : Applica-tion aux boids de reynolds. In Laurent Vercouter

and Gauthier Picard, editors, Environnements socio-techniques - JFSMA 15 - Vingt-troisièmes Jour-nées Francophones sur les Systèmes Multi-Agents,Rennes, France, pages 185–194. Cépaduès Éditions,2015.

[6] Emmanuel Hermellin and Fabien Michel. GPU De-legation : Toward a Generic Approach for Develop-ping MABS Using GPU Programming. In Procee-dings of the 2016 International Conference on Auto-nomous Agents & Multiagent Systems, AAMAS ’16,pages 1249–1258, Richland, SC, 2016. InternationalFoundation for Autonomous Agents and MultiagentSystems.

[7] Emmanuel Hermellin, Fabien Michel, and JacquesFerber. État de l’art sur les sim. multi-agents etle GPGPU. Revue d’Intelligence Artificielle, 29(3-4) :425–451, 2015.

[8] Yoann Kubera, Philippe Mathieu, and Sébastien Pi-cault. Ioda : an interaction-oriented approach formulti-agent based simulations. Autonomous Agentsand Multi-Agent Systems, 23(3) :303–343, 2011.

[9] Guillaume Laville, Kamel Mazouzi, ChristopheLang, Nicolas Marilleau, and Laurent Philippe.Using GPU for Multi-agent Multi-scale Simula-tions. In Distrib. Computing and Artificial Intelli-gence, volume 151 of Advances in Intelligent andSoft Computing, pages 197–204. Springer BerlinHeidelberg, 2012.

[10] Fabien Michel. Délégation GPU des percep-tions agents : intégration itérative et modulaire duGPGPU dans les simulations multi-agents. Applica-tion sur la plate-forme TurtleKit 3. Revue d’Intelli-gence Artificielle, 28(4) :485–510, 2014.

[11] John D. Owens, David Luebke, Naga Govindaraju,Mark Harris, Jens Krà 1

4ger, Aaron E. Lefohn, andTimothy J. Purcell. A Survey of General-PurposeComputation on Graphics Hardware. ComputerGraphics Forum, 26(1) :80–113, 2007.

[12] Hazel R. Parry and Mike Bithell. Large scaleabm : A review and guidelines for model sca-ling. In Alison J. Heppenstall, Andrew T. Crooks,Linda M. See, and Michael Batty, editors, Agent-Based Models of Geographical Systems, pages 271–308. Springer Netherlands, 2012.

[13] Kalyan S. Perumalla and Brandon G. Aaby. Data pa-rallel execution challenges and runtime performanceof agent simulations on GPUs. Proceedings ofthe 2008 Spring simulation multiconference, pages116–123, 2008.

[14] Alessandro Ricci, Michele Piunti, and Mirko Viroli.Environment programming in MAS : an artifact-based perspective. Autonomous Agents and Multi-Agent Systems, 23(2) :158–192, 2011.

[15] Paul Richmond, Dawn Walker, Simon Coakley, andDaniela M. Romano. High performance cellular le-vel agent-based simu. with FLAME for the GPU.Briefings in bioinformatics, 11(3) :334–47, 2010.

[16] Jason Sanders and Edward Kandrot. CUDA parl’exemple. Pearson, 2011.

[17] Danny Weyns and Fabien Michel. Agent Environ-ments for Multi-Agent Systems IV, 4th Internatio-nal Workshop, E4MAS 2014 - 10 Years Later, Paris,France, May 6, 2014, Revised Selected and InvitedPapers, volume 9068 of LNCS. Springer, 2015.