Utilisation des fonctions graphiques des GPU

3.1.3 Bilan des implémentations tout-sur-GPU . . . 39

3.2 Implémentation hybride . . . 40 3.3 Chronologie et synthèse . . . 42 3.4 Synthèse de l’utilisation du GPGPU dans les MABS . . . 44

3.4.1 Nature et généricité des modèles . . . 44 3.4.2 L’accessibilité des modèles . . . 45

3.5 Problématiques abordées dans la thèse . . . 45

Comme nous l’avons évoqué au chapitre 1, le temps d’exécution d’une simulation multi-agent est une contrainte importante qui préfigure de notre capacité à explorer et étudier le modèle si- mulé. Ainsi, plutôt que de devoir le simplifier et/ou faire des compromis (jouer sur la scalabilité du modèle et/ou sur sa visualisation), utiliser le GPGPU, afin d’améliorer les performances des si- mulations et ainsi lever une partie des contraintes liées au passage à l’échelle, peut être une piste de recherche intéressante [Che et al., 2008].

Cependant, comme énoncé au chapitre 2, le GPGPU repose sur l’utilisation d’une architecture matérielle spécifique, hautement parallèle, nécessitant une programmation particulière [Bour- goin et al., 2014] qui va forcément avoir une incidence sur la mise en œuvre des modèles multi- agents. Nous proposons donc, dans ce contexte, de réaliser un état de l’art sur l’utilisation du GPGPU dans le cadre de la simulation multi-agent [Hermellin et al., 2014, Hermellin et al., 2015] afin de souligner dans quelle mesure les spécificités de cette technologie vont impacter la modé- lisation et l’implémentation des simulations multi-agents sur GPU.

Cette question est d’autant plus pertinente que très peu des plates-formes de développement spécialisées dans la simulation multi-agent n’intègrent, en leur sein, de fonctionnalités dédiées au GPGPU ou plus généralement au calcul intensif (cf. chapitre 1). NetLogo [Sklar, 2007] conserve une implémentation séquentielle classique alors que RePast [North et al., 2007] intègre le calcul intensif via une utilisation des clusters de CPU [Collier and North, 2012]. Seul MasOn [Luke et al.,

2005] propose une intégration du GPGPU (avec même une possibilité d’utiliser plusieurs GPU [Ho et al., 2015]).

Ainsi, nous constaterons que les travaux mêlant GPGPU et simulations multi-agents sont ma- joritairement liés à des expérimentations très particulières limitant leur réutilisation. D’ailleurs, ces questions autour de la facilité de programmation et de l’accessibilité à cette technologie sont courantes dans le domaine du HPC et ne sont pas seulement propre au GPGPU. En effet, même une parallélisation d’une simulation sur CPU pose des problèmes comme le montre [McCabe et al., 2016].

Pour figurer dans l’état de l’art, que nous proposons dans ce chapitre, chacune des contribu- tions sélectionnées devra répondre aux critères suivants :

— Les contributions doivent traiter de l’utilisation du GPGPU dans un contexte multi-agent ; — Les travaux sélectionnés doivent soit introduire de nouveaux outils, frameworks, biblio-

thèques dédiées, soit présenter des études, méthodologies ou benchmarks relatifs à l’uti- lisation du GPGPU dans le contexte multi-agent.

Dans le cas ou plusieurs contributions discutent du même aspect, ou présentent un même outil, nous sélectionnons celui qui est le plus complet afin d’éviter toute redondance. Nous tenons à noter que cet état de l’art ne se veut pas exhaustif, son objectif premier est de donner un aperçu de ce qu’il se fait et est possible de faire avec le GPGPU dans la communauté multi-agent.

La présentation des différentes contributions sélectionnées est faite en fonction des choix d’implémentations et des techniques utilisées. En effet, implémenter une simulation multi-agent sur GPU peut se faire de deux manières distinctes, chacune possédant des avantages et inconvé- nients. La première consiste à exécuter entièrement la simulation sur le GPU, nous la nommons tout-sur-GPU. La seconde partage l’exécution de la simulation entre le CPU et le GPU et est classi- quement qualifiée d’hybride. Nous choisissons de suivre cette distinction afin de classer les contri- butions sélectionnées.

3.1 Implémentation tout-sur-GPU

Historiquement, l’implémentation d’une simulation multi-agent entièrement sur GPU (voir figure 3.1) se faisait via l’utilisation et le détournement des fonctions graphiques du GPU, du fait du manque d’API dédiées. Par la suite, des API spécialisées dans le GPGPU, telles que CUDA et OpenCL, ont été créées et ont eu comme objectif de rendre accessible l’utilisation de cette tech- nologie. Les détails techniques d’implémentation associés à ces deux méthodes d’utilisation du GPGPU ont été énoncés dans le chapitre 2 et sont explicités dans [Owens et al., 2007].

3.1. Implémentation tout-sur-GPU

3.1.1 Utilisation des fonctions graphiques des GPU

SugarScape est le premier SMA ayant profité d’un portage sur GPU [D’Souza et al., 2007]. C’est un modèle multi-agent très simple dans lequel des agents réactifs évoluent dans un environne- ment discrétisé en cellules contenant une ressource, le sucre, et suivent des règles comporte- mentales basiques (déplacement, reproduction, etc.). Avec cette implémentation, la simulation SugarScape permettait de voir évoluer en temps réel plus de 2 millions d’agents dans un environ- nement d’une résolution de 2 560 par 1 024. La performance était d’autant plus encourageante qu’elle a été réalisée à l’aide d’un ordinateur grand public équipé d’une carte graphique com- portant seulement 128 cœurs. D’un point de vue performance, cette adaptation GPU surpassait ainsi toutes les versions séquentielles de SugarScape tout en permettant d’avoir une population d’agents encore jamais vue dans des environnements plus larges.

LYSENKOet D’SOUZA, motivés par ces très bons résultats, se sont ensuite attaqués au problème de l’accessibilité (cf. section 1.2.4) en généralisant leur approche et en proposant un framework destiné à faciliter l’implémentation de modèle sur GPU [Lysenko and D’Souza, 2008]. Celui-ci était composé de fonctions de bases telles que la gestion de données environnementales, la gestion des interactions entre agents, des fonctions pour la naissance et mort des agents, etc. Cependant, il ne permettait que des implémentations de modèles similaires à SugarScape comportant unique- ment des agents réactifs aux comportements peu évolués du fait de la difficulté d’implémenter des architectures agents complexes sur GPU.

Suivant cette tendance, et dans le but de simplifier encore plus l’utilisation du GPGPU, le fra- mework ABGPU se proposait d’être une interface de programmation un peu plus générique (si- milaire à celle que l’on pouvait trouver sur CPU) et surtout plus accessible grâce à une utilisation transparente du GPU reposant sur un ensemble de classes C/C++ et un système de mots clés [Rich- mond and Romano, 2008]. À cela s’ajoutaient des fonctions et des classes pré-programmées, fa- cilitant d’avantage l’implémentation de comportements et fonctions agents un peu plus évoluées (fonctions de synchronisations, communications, etc). ABGPU se voulait optimisé pour des simu- lations dans lesquelles évoluaient des agents réactifs aux comportements simples (e.g. simulations de flocking). ABGPU était ainsi capable de simuler et d’afficher 65 536 agents en mouvements et en interactions en temps réel et en 3D en utilisant une carte graphique composée de 112 cœurs.

Cependant, même dans le cas d’architectures agents très simples, ces travaux pionniers sou- lignent la difficulté de mettre en place une méthode de conversion générique pour le portage de simulations multi-agents sur GPU, notamment du fait de la grande diversité des modèles. À ce propos, [Perumalla and Aaby, 2008] a étudié les contraintes associées à de telles conversions en réalisant l’implémentation de différents modèles (Mood Diffusion1, Game of Life2et Schelling Se- gregation3) sur CPU (avec NetLogo [Sklar, 2007] et Repast [North et al., 2007]), puis sur GPU. Ces cas d’études montrent bien que les spécificités de la programmation sur GPU rendent difficile, voire impossible, le processus de conversion qui est bien plus complexe qu’un simple change- ment de langage de programmation. En effet, avec le GPGPU, de nombreux concepts présents en programmation séquentielle ne sont plus disponibles. Du fait de ces difficultés, le besoin en outils et interfaces spécialisés était très grand et leur apparition va permettre une expansion du GPGPU.