Jonathan Passerat-Palmbach

Transcription

1 Techniques de Génie Logiciel au service des Simulations de Monte Carlo : cas de la distribution des nombres Pseudo-Aléatoires dans un environnement de Calcul à Haute Performance Jonathan Passerat-Palmbach Résumé : Les simulations dites 'stochastiques', du grec 'stochos', utilisent astucieusement le hasard, et sont de plus en plus répandues dans les supercalculateurs. Cette thèse propose des techniques logicielles et des outils pour paralléliser la génération de nombres pseudo-aléatoires sur des architectures à base de GPU (Graphics Processing Units). Ces dernières sont massivement utilisées pour accélérer très sensiblement les temps de calcul. Notre approche conserve la rigueur scientifique nécessaire à la reproductibilité des expériences et à l'évitement de biais, ce qui n'était actuellement pas le cas. 1 Utilisation du hasard dans les modèles : les simulations stochastiques Lorsque l'homme ne comprend pas un processus, il le représente sous une autre forme et produit ainsi un modèle de la réalité. On en distingue plusieurs catégories selon les problèmes que l'on cherche à modéliser. Généralement, le cœur du modèle consiste à résoudre un ensemble d'équations plus ou moins complexes. Toutefois, lorsque l'outil mathématique ne permet pas d'obtenir une représentation suffisamment précise de la réalité, on utilise le hasard pour palier ce manque. On parle alors de modèle stochastique, du grec stochos signifiant hasard. L'outil informatique a apporté une dimension supérieure à la modélisation en lui permettant de plonger les modèles dans le temps : on parle alors de simulation numérique. De nos jours, la simulation numérique est employé dans de nombreux domaines allant de la chimie et la biologie à l'industrie automobile. La puissance de calcul des ordinateurs permet d'explorer les paramètres à la fois au cours du temps mais aussi de faire varier Les simulations à base de modèles stochastiques sont communément connues sous le nom de simulation de Monte Carlo. Cette dénomination rappelle bien évidemment les jeux de hasard et de casinos. Une simulation dite de Monte Carlo doit malgré tout être considérée comme une expérience scientifique à part entière. Comme toute expérience scientifique, une simulation numérique se doit d'être reproductible : les résultats obtenus dans des conditions particulières doivent être retrouvés dès lors que l'on place la simulation dans des conditions identiques. Le défi est donc de manipuler le hasard pour l'utiliser à des fins de modélisation, tout en étant capable de rejouer le même scénario au fil des expériences. 1

2 2 Manipulation du hasard : les générateurs de nombres aléatoires Un outil informatique, le générateur de nombres pseudo-aléatoires, permet d'obtenir un tel résultat. Il s'agit d'un algorithme produisant une séquence de nombres d'apparence parfaitement aléatoire. En réalité, ces générateurs sont l'expression de suites mathématiques complexes mimant le hasard, mais restent tout à fait déterministes pour celui qui connaît l'ensemble de leurs paramètres. On parle ainsi de pseudo-hasard et de nombres pseudo-aléatoires pour les différencier des véritables séquences purement aléatoires basées sur des processus quantiques. On peut représenter un générateur de nombre aléatoires de manière très simple à l'aide d'un cercle et ainsi décrire ses propriétés. La Figure 1 montre cette analogie. Le cercle représente l'ensemble de la séquence aléatoire générée par un ensemble de paramètres donnés. On retrouve l'élément courant qui n'est autre que le dernier nombre produit, et son successeur, rappelant le côté purement déterministe des générateurs pseudoaléatoires. Sur le cercle, le point de départ dans la séquence, appelée germe ou graine, peut se trouver n'importe où. Enfin l'analogie du cercle représente idéalement le fait que la séquence générée est cyclique : une fois l'intégralité des nombres tirés, on boucle sur la même séquence. La longueur de la séquence produite par un générateur est appelée période. Figure 1 Représentation d une séquence pseudo-aléatoire sous forme de cercle Le caractère facilement reproductible des générateurs de nombres pseudo-aléatoires fait d'eux un outil au cœur des simulations numériques. Différents algorithmes de génération existent et présentent chacun des propriétés différentes. Il existe bien évidemment une classification des algorithmes, certains étant de meilleur qualité statistique que d'autres. Le plus important lors du choix de l'algorithme est avant tout de considérer son utilisation au sein de l'application visée. Si l'utilisation des générateurs est bien maitrisée au sein des applications séquentielles, c'est à dire les programmes informatiques exécutant leurs actions les unes après les autres, les applications parallèles ne peuvent pas en dire autant. 2

3 3 Applications parallèles et nombres pseudo-aléatoires Pour donner un ordre de grandeur, les simulations récentes utilisent parfois des milliards de nombres pseudo-aléatoires [2]. Dans ce contexte, le temps d'exécution de la simulation peut être prohibitif sans traitement parallèle. Cependant, les processeurs classiques dont nous disposons ont montré leur limite. Les fabricants de processeurs ne parviennent plus à respecter la loi de Moore [3], qui prévoyait de doubler le nombre de transistors dans les processeurs tous les 18 mois (voire la Figure 2, et par conséquent d'augmenter la fréquence des processeurs. Figure 2 La loi de Moore suggère que le nombre de transistors dans les processeurs double tous les 18 mois [Source wikipedia] Doubler la densité de transistors sur une puce associée à l'augmentation de leur fréquence de fonctionnement a la malencontreuse propriété d'augmenter la consommation énergétique de la puce, ainsi que la chaleur qu'elle dissipe. La course à l'augmentation de la fréquence des processeurs n'est donc pas viable et une autre solution se devait d'être trouvée pour continuer d'accroître les performances des machines. L'idée est de profiter du nombre élevée de transistors pour dupliquer dupliquer l'ensemble des éléments matériels nécessaires à l'exécution d'un programme, au sein d'une seule et même puce. On appelle cette technologie les processeurs multi-coeurs. En multipliant le nombre de cœurs sur un processeur, on lui ajoute la capacité d'exécuter plusieurs applications ou tâches en parallèle. Les ordinateurs grand public possèdent de nos jours de 4 à 8 cœurs et sont donc potentiellement capables d'exécuter des applications parallèles ou plusieurs applications séquentielles en même temps. La stratégie de la parallélisation, si elle est utilisée à bon escient, permet d'améliorer la puissance de calcul d'une machine, tout en réduisant sa consommation énergétique. En 3

4 Figure 3 Comparaison entre CPU simple et multi-cœurs effet, à fréquence de fonctionnement identique, le nombre de cœurs agissant en parallèles permet de réaliser plus d'opérations qu'avec un processeur d'ancienne génération. Il n'est donc plus nécessaire d'élever la fréquence de fonctionnement des processeurs, diminuant ainsi son impact énergétique. Il existe principalement deux types d'applications parallèles : lorsqu'une application est capable de réaliser plusieurs actions indépendantes en même temps, on parle de parallélisme de tâches. Si l'on compare ce type de parallélisme à la vie courante, on peut imaginer une personne capable de tenir une conversation téléphonique tout en travaillant sur son ordinateur. Les deux tâches sont parfaitement indépendantes mais réalisées en parallèle. Par opposition au parallélisme de tâches, on parle de parallélisme de données quand plusieurs processeurs réalisent la même tâche sur des données différentes. Pour reprendre l'analogie précédente, on imaginera cette fois-ci une personne capable de peindre avec deux pinceaux en même temps. Chacune de ses mains sera chargée de peindre une partie d'une toile. Parmi les applications les plus friandes de parallélisation, on retrouve au premier rang les simulations numériques, nécessitant toujours plus de puissance de calcul pour supporter des modèles toujours plus ambitieux. La nature même des simulations de type Monte Carlo engendre une augmentation significative des temps d'exécution. Le fait d'utiliser le hasard dans ces simulations nous obligent à répéter l'expérience un grand nombre de fois de manière à moyenner l'impact du hasard sur les résultats. Quelques propriétés théoriques doivent cependant être respectées pour que les résultats issus de la simulation ne souffrent pas d'un biais potentiel. Premièrement, toutes les réplications de la simulation doivent utiliser le même algorithme de génération de nombres aléatoires. Seuls ses paramètres seront réglés différemment d'une réplication à l'autre. Dans un second temps, il faudra s'assurer que les séquences aléatoires utilisées sont hautement indépendantes. Elles ne doivent pas posséder de lien évident entre elles : ce qui est le cas si chaque élément d'une séquence A est le double de l'élément correspondant dans la séquence B par exemple. Dans le même esprit, deux séquences possédant des portions communes se chevauchent et ne sont donc pas indépendantes. 4

5 4 Gestion des nombres pseudo-aléatoires dans les applications parallèles Paralléliser une application n'est pas tâche facile. Comme nous l'avons vu précédemment, le but de cette opération est d'améliorer les performances de l'application originale, et donc d'accélérer son temps d'exécution. On répartit pour cela les actions à effectuer sur les différents cœurs du processeur à l'aide de threads. Les threads sont les outils manipulés par le programmeur pour paralléliser une application. Chaque thread dispose de son propre contexte d'exécution, et regroupe l'ensemble des opérations représentant une action particulière de l'application. Dans le cas d'un parallélisme de tâches, chaque thread aura une fonction bien précise à réaliser, comme «téléphoner» si l'on reprend l'analogie précédente. En se plaçant à présent dans le contexte d'un parallélisme de données, chaque thread regroupera les actions permettant de traiter un certain groupe de données. On imaginera qu'un thread est chargé de peindre la moitié inférieure d'un tableau, tandis qu'un second se charge de la moitié inférieure. Figure 4 Chaque thread parallèle effectue une série de tâches indépendamment des autres Les threads sont donc l'outil qui permet au programmeur d'accéder au degré parallèle introduit par les multiples cœurs des processeurs. Tout n'est malheureusement pas aussi simple que ça, et de nombreux choix évidents dans le cas d'une application séquentielle le deviennent beaucoup moins dans un contexte parallèle. Prenons les générateurs de nombres pseudo-aléatoires qui nous intéressent tant. Une simulation de Monte Carlo séquentielle utilise un unique générateur pour subvenir à ses besoins en nombres aléatoires. Que se passe-t-il maintenant si l'on parallélise cette même simulation à l'aide de threads et que chaque thread a besoin d'avoir accès à une source de hasard pour réaliser les actions qui lui ont été attribuées? Avant de se prononcer, rappelons les contraintes introduites par les simulations de Monte Carlo : les séquences aléatoires utilisées entre deux réplications aux paramètres différents doivent être indépendantes, et les exécutions répétées d'une même instance de simulation doivent être reproductibles. Les threads doivent donc accéder aux mécanismes de génération de nombres aléatoires en parallèle, tout en obtenant la même séquence de nombre à chaque exécution. 5

6 Sans aucune prise en charge particulière de ce problème, le résultat serait totalement indéterministe et impossible à reproduire. En effet chaque thread accéderait à l'unique générateur de l'application indépendamment et obtiendrait donc le nombre courant de la séquence aléatoire. Rien n'assure que l'ordre d'accès des threads à cette séquence sera le même d'une exécution à l'autre. Il se pourrait même que deux threads accèdent exactement au même moment au générateur et tirent le même nombre aléatoire! Cette situation ne respecte en rien les contraintes que nous avons exposées et n'est donc pas satisfaisante. Si l'indépendance n'est pas établie, les qualités intrinsèques statistiques ne sont plus garanties, et les conséquences pourraient être importantes, allant jusqu'à impacter significativement les résultats de la simulation. Nous avons pu constater un tel problème dans le cas d'une application de médecine nucléaire permettant de détecter des tumeurs. La Figure 5 compare les résultats obtenus pour la même simulation en prenant soin de gérer correctement la distribution des nombres pseudo-aléatoires entre les threads ou non. On constate que le résultat obtenu en appliquant les bonnes pratiques de distribution est très proche de l idéal, alors que l absence de distribution correcte produit un résultat erroné. Figure 5 En haut, le résultat idéal de la simulation. En bas, le résultat d une simulation parallèle avec (à gauche) et sans (à droite) prise en charge correcte de la distribution des nombres pseudo-aléatoires entre les threads. Depuis une vingtaine d'années, plusieurs techniques ont été mises au point pour répartir correctement les nombres aléatoires issus d'un même générateur entre différents threads parallèles. Les générateurs sont sensibles à la manière dont les séquences aléatoires qu'ils produisent sont partagées entre les threads. On doit donc s'assurer que la technique choisie pour répartir correctement les nombres aléatoires au sein d'une application parallèle convient au générateur utilisé. Notre vision du problème est telle que le couple { générateur ; application} devient de ce fait un ensemble de propriétés { générateur ; application ; technique de distribution} caractérisant la simulation. Il devient donc extrêmement complexe de faire les bons choix d'outils lorsque l'on conçoit une simulation de Monte Carlo. Par ailleurs, les scientifiques concevant ce genre de simulations sont bien évidemment des experts de leur domaine, mais pas forcément dans la gestion de nombres aléatoires en parallèle. S'il s'agit d'un domaine de recherche pour nous, ce doit être un outil simple à utiliser pour le reste de la communauté. En informatique, on appelle bibliothèque, une collection d'utilitaires visant à répondre à une pro- 6

7 blématique précise. Dans notre cas, on peut regrouper dans une bibliothèque l'ensemble des fonctions gérant la distribution des nombres aléatoires, sans que le concepteur de simulations n'ait à maîtriser toute la théorie sous-jacente. Des bibliothèques très performantes sont disponibles pour les applications parallèles utilisant des threads sur les processeurs multi-coeurs. Il s'avère toutefois que les processeurs multi-coeurs sont excessivement onéreux dès lors que l'on souhaite en acquérir une grande quantité pour augmenter sa puissance de calcul. Les instituts de recherche et les universités ont donc l'habitude de regrouper leur moyens de calculs au sein de centres contentant un grand nombre de machines dédiées au calcul scientifique à haute performance. On désigne par le terme de supercalculateurs les machines regroupant un nombre considérable de cœurs de calcul. Ces machines surpuissantes ont vu leur consommation énergétique, et la facture électrique résultant, augmenter avec le nombre de processeurs. Dans ce contexte, les scientifiques ont cherché de nouvelles architectures, plus parallèles, moins couteuses, et consommant mois d'énergie. Dernièrement, une possibilité de réduire le temps d'exécution des simulations est apparue à travers les processeurs graphiques généralistes : les GP-GPU (General Purpose Graphics Processing Units), également appelé GPU pour des raisons de simplicité. Ces dispositifs ouvrent de nouvelles possibilités pour la parallélisation, mais elles introduisent également de nouvelles difficultés de programmation. 5 Les GPU et l'émergence de l'informatique hybride pour la simulation Un GPU n'est autre que la carte graphique que tout un chacun possède au coeur de son ordinateur pour supporter les jeux vidéos ou les films en haute définition. À la différence des processeurs classiques, les GPU ne sont pas génériques mais optimisés pour réaliser une tâche bien précise : le traitement d'images. En effet, que l'on profite d'un jeu vidéo ou que l'on visionne un film en haute définition, les actions réalisées par la machine sont relativement similaires. Il s'agit de traiter et d'afficher à l'écran une succession d'images le plus rapidement possible, de manière à ce que l'oeil humain les considère comme un flux continu, un film. Une image est composée d'éléments atomiques appelés pixels, qui portent les caractéristiques d'un point de l'image et apparaitront à l'écran. Appliquer une opération sur une image, consiste en réalité à appliquer cette opération sur chacun des pixels qui la forment. On peut dont facilement réaliser cette opération en parallèle et on se trouve alors dans le cadre d'un parallélisme de données. Les GPU sont donc des processeurs spécifiquement optimisés pour réaliser des traitements parallèles sur les données. Ils diffèrent des processeurs traditionnels (CPU pour Central Processing Unit, en anglais) du fait qu'ils possèdent 100 à 1000 fois plus de cœurs que les CPU. Cependant, la fréquence à laquelle chacun de ces cœurs fonctionne est bien plus faible que pour un processeur classique, mais celle-ci est compensée par le nombre de cœurs présents. En guise de comparaison, les cœurs d'un CPU sont cadencés aux alentours de 3GHz, tandis que ceux d'un GPU fonctionnent à 1GHz. Dans l'histoire des processeurs, on retrouve des processeurs fonctionnant à 1GHz au début des années Comme le dit si bien 7

8 l'adage : le nombre fait la force et les GPU sont capables de réaliser une même action en parallèle sur des données différentes, plus vite qu'un processeur multi-coeur et en consommant moins d'énergie. Ces caractéristiques ont donné l'idée à des scientifiques issus du domaine de la physique d'utiliser les GPU pour réaliser des opérations autres que le traitement d'images. En effet, de nombreux problèmes peuvent bénéficier d'un parallélisme de données et donc exploiter la puissance de calcul d'un GPU. La technique du General Purpose GPU (processeur graphique à usage générique) était née. Cette première initiative et celles qui ont suivies, étaient plus à ranger du côté des études de faisabilité, sans être réellement utilisables par la communauté scientifique. Les GPU ne sont pas parmi les processeurs les plus simples à programmer, qui plus est pour des applications pour lesquels ils n'ont pas été conçus. La plupart des développeurs ne sont pas familiers avec la façon dont ils fonctionnent. L'adoption de la programmation GPU au sein de la communauté des développeurs parallèle n'est due qu'à l'intervention du fabricant NVIDIA, qui a introduit un nouveau langage de programmation appelé CUDA (Compute Unified Device Architecture) [4]. CUDA réutilise la notion de threads familières aux utilisateurs de processeurs multi-coeurs au lieu des fonctions et structures de données issues du monde du traitement d'images. Grâce à cette initiative, la programmation parallèle GPU est devenue plus semblable à la programmation parallèle sur des CPU multi-coeurs. Bien que l'on dispose désormais d'un langage de programmation permettant de développer des applications comme sur un processeur classique, la nature même des GPU en fait des plateformes spécifiques pour lesquelles la conception d'applications fonctionnelles reste complexe. Tout d'abord, là où les applications ayant vocation à être exécutées sur CPU manipulent une seule zone mémoire pour stocker leurs données, les GPU doivent gérer pas moins de 6 zones aux propriétés différentes! Ces zones sont traditionnellement représentées sous la forme d'une hiérarchie pour évoquer leurs différences en terme de temps d'accès aux données et de contenance. En outre, pour être efficaces, les applications doivent être capable de répartir leurs tâches afin d'exploiter à la fois CPU et GPU. Les deux processeurs ont des caractéristiques différentes et certaines tâches sont donc plus adaptées à l'un qu'à l'autre. Ce paradigme est connu sous le nom d'informatique hybride, ou calcul hybride, et est partie prenante des applications de calcul à haute performance modernes. Tous ces paramètres font qu'il reste extrêmement difficile de tirer parti de la puissance de calcul des GPU. Dans le même temps, la course à la performance ne doit pas occulter la nécessité d'obtenir des résultats corrects. Ma thèse ciblait cette problématique et visait dans un premier temps à étudier des techniques pour gérer les nombres pseudosaléatoires dans une application exécutée sur GPU. Dans un second temps, nous nous sommes fixés pour objectif de fournir à la communauté un outil permettant de masquer cette même théorie aux utilisateurs finaux : les scientifiques concevant des modèles de simulation. Les propositions qui en résultent regroupent deux domaines de recherche en informatique, à savoir le génie logiciel et le calcul à haute performance, dans le but de les mettre au service de l'ensemble de la communauté scientifique. 6 De la nécessité des bonnes pratiques de génie logiciel Le génie logiciel est souvent assimilé à tort à la programmation d'applications, alors 8

9 qu'il regroupe au contraire les théories permettant aux programmeurs d'être efficaces et aux applications d'être de bonne qualité. Il offre également des outils de modélisation visant à proposer des solutions fiables en amont de la programmation d'une application. Comme nous l'avons vu précédemment, les simulations s'exécutant seulement sur CPU peuvent profiter d'une large gamme de générateurs de bonne qualité statistique regroupés dans des bibliothèques. Un tel outil faisait cependant défaut les GPU, que ce soit au niveau des générateurs disponibles ou des outils fournis pour les manipuler. De nombreuses tentatives ont été faites pour proposer des versions de générateurs pour GPU. Des études antérieures comme [1] ont défriché la génération de nombres pseudo-aléatoires sur GPU. De nombreuses stratégies ont été adoptées pour tirer au mieux parti des caractéristiques des GPU et en particulier de leur différentes zones de mémoire. Peu d'entre elles proposent des apports suffisants pour se distinguer. Ainsi la prise en compte des GPU nous a conduit ajouter un quatrième élément à l'ensemble des paramètres à prendre en compte pour caractériser une simulation de Monte Carlo sur GPU. À l'ensemble précédent, on ajoute la manière d'implanter le générateur sur le GPU (quelles zones mémoires sont utilisées,...), qui devient donc : { générateur ; application ; technique de distribution ; technique d'implantation}. Reste maintenant à traduire ce modèle théorique régissant la génération de nombres aléatoires en outil concret. Les récents langage de programmation tels que CUDA ont permis de produire des applications beaucoup plus ambitieuses sur GPU. Il est désormais possible de bénéficier de certaines techniques de génie logiciel, tels que la conception orientée objet ou la programmation générique dans les applications GPU. Grâce à ces développements, nous avons pu placer la source de hasard au premier plan de la simulation. Le générateur devient un objet à part entière de la simulation. Il est manipulable, paramétrable et interchangeable comme tous les autres éléments de l'environnement simulé. Au delà de la souplesse et de la simplicité offertes au développeur, cette apport est scientifiquement intéressant. Notre proposition permet en effet d'explorer plusieurs paramètres pour la génération de nombres pseudo-aléatoires et de vérifier par exemple qu'un algorithme de génération particulier ne biaise pas les résultats de la simulation. Notre contribution se nomme ShoveRand. Il s'agit d'une bibliothèque contenant des algorithmes de génération de nombre aléatoires, mais surtout les gardes-fous traduisant nos propositions théoriques pour aiguiller le scientifique concevant une simulation sur GPU. L'utilisateur a simplement a choisir l'algorithme de génération qu'il souhaite utiliser, et ShoveRand se charge d'appliquer toutes les consignes théoriques que nous avons recensées. Nous avons plus tard appliqué ces propositions théoriques aux CPU multi-coeurs au sein d'un second outil appelé TaskLocalRandom. Il couvre quant à lui les aspects de parallélisation de tâches plus propices aux CPU. 7 Conclusion Notre contribution principale, ShoveRand, a été mise en œuvre avec succès dans un modèle de repliement de chromosomes s'exécutant entièrement sur GPU. Des travaux dans un domaine totalement distinct, la Recherche Opérationnelle, pourraient de nouveau faire appel à ses services. Ces travaux valident nos modèles théoriques régulant la distribution de nombres pseudo-aléatoires au sein de processeurs parallèles, qu'ils 9

10 soient des CPU multi-coeurs ou des GPU. Les outils qui en découlent comme Shove- Rand et TaskLocalRandom peuvent profiter à toute la communauté scientifique utilisant des nombres pseudo-aléatoires en parallèle. Ces bibliothèques sont libres et leur code source est disponible sur Internet pour quiconque veut étudier leur fonctionnement, s'en inspirer ou les améliorer. Gérer de bout en bout la distribution des nombres pseudo-aléatoires sur un GPU reste une simple brique dans l'optique de perspectives de recherche plus ambitieuses. Dans l'idéal, la majeure partie du travail de parallélisation d'une application pourrait être faite automatiquement par un autre programme, soulageant le programmeur de ce fardeau. Pour ce faire, tous les outils utilisés par l'application, comme le générateur de nombre aléatoires dans la cas d'une simulation, doivent être capables de s'adapter automatiquement au nouvel environnement parallèle. Nous espérons à l'avenir pouvoir proposer des approches de parallélisation résultant d'une automatisation de plus en plus importante. Références [1] Thomas Bradley, Jacques du Toit, Robert Tong, Mike Giles, and Paul Woodhams. Parallelization techniques for random numbers generators. In Wen-mei W. Hwu, editor, GPU Computing Gems Emerald Edition, pages Elsevier, [2] L. Maigne, David R. C. Hill, P. Calvat, V. Breton, R. Reuillon, Y. Legre, and D. Donnarieix. Parallelization of monte carlo simulations and submission to a grid environment. Parallel processing letters, 14(2) : , [3] Gordon E Moore. Cramming more components onto integrated circuits. McGraw-Hill, [4] NVIDIA. NVIDIA CUDA Programming Guide [5] Jonathan Passerat-Palmbach, Jonathan Caux, Yannick Le Pennec, Romain Reuillon, Ivan Junier, François Kepes, and David R. C. Hill. Parallel stepwise stochastic simulation : Harnessing GPUs to explore possible futures states of a chromosome folding model thanks to the possible futures algorithm (PFA). In ACM SIGSIM Conference on Principles of Advanced Discrete Simulation (PADS), pages , Montreal, Canada, [6] Jonathan Passerat-Palmbach, Claude Mazel, Bruno Bachelet, and David R. C. Hill. ShoveRand : a model-driven framework to easily generate random numbers on GP- GPU. In IEEE International Conference on High Performance Computing & Simulation, pages IEEE, [7] Jonathan Passerat-Palmbach, Claude Mazel, and David R. C. Hill. Pseudo-random streams for distributed and parallel stochastic simulations on GP-GPU. Journal of Simulation, 6(3) : , June doi : /jos [8] Jonathan Passerat-Palmbach, Claude Mazel, and David R. C. Hill. TaskLocalRandom : a statistically sound substitute to pseudorandom number generation in parallel java tasks frameworks. Concurrency and Computation : Practice and Experience, under to be published. 10