De ette faço , l algo ith e, pou t ou e le sultat d u e it atio su u e o figu atio donnée, est très simple :
- Si le résultat a déjà été calculé, le retourner. - Sinon, le calculer, le sauvegarder et le retourner.
Ai si, le sultat d u e it atio pou u e o figu atio do e est al ul u u e fois. Pou les o figu atio s peu ou a tes, e a is e est pas e table en termes de temps de calcul mais dès lors que la configuration réapparait souvent dans une simulation, les gains en temps peuvent être très importants.
Le p o l e est u e l a se e de la o aissa e des ellules oisi es d u e configuration, il est impossible de connaitre le nouvel état des cellules sur le bord de la configuration. La taille de la configuration de cellules sauvegardées comme résultat
96 Configuration résultant d’une itération. Configuration de cellules ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Figure 2-13 : Configurations de cellules avec leurs configurations résultantes sauvegardées après une itération.
Pou et ou e le ou el tat d u e o figu atio de ellules d u auto ate ad e ouge da s l e e ple de la Figure 2-14), il va donc être nécessaire de travailler sur une
o figu atio se si le e t plus g a de ad e leu da s l e e ple sui a t . Éta t do ue l o utilise u uadt ee, la o figu atio sup ieu e poss de a toujou s u ôt deu fois plus g a d da s l e e ple sui a t, la o figu atio sup rieure est de taille 8x8 pour calculer une configuration de 4x4).
97 À pa ti de ette o figu atio de taille sup ieu e la leue , il est pas possi le de et ou e le œu e alisa t u si ple al ul pa u sio su les uat e fils a elui-ci ne mène pas au résultat souhaité. E appli ua t u algo ith e s ue tiel à l auto ate de la Figure 2-15Figure 2-15, les quatre fils (en vert) fourniraient dans un premier temps comme sultat leu s œu s espe tifs e o a ge . Or ces quatre zones en orange ne permettent pas de e o stitue le œu de l auto ate i itial e ouge , elles so t disjoi tes et t op éloignées du centre.
Pour disposer du résultat souhaité, il est nécessaire de créer quatre nouvelles configurations temporaires de cellules, de la e taille ue la o figu atio ue l o he he à tudie e rouge), décalées respectivement en haut et à gauche, en haut et à droite, en bas et à gauche, et en bas et à d oite da s l e e ple sui a t, il s agit des uat e o figu atio s de cellules rouges dans la deuxième étape du schéma). Une fois ces quatre configurations accessibles (créées ou récupérées dans la table de hachage), la fusion de leur calcul à l it atio sui a te u ot s de u à uat e da s l e e ple sui a t pe et de fo e la
98 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 1 2 2 3 3 4 4
Figure 2-14 : Création de quatre configurations temporaires (au milieu) pour disposer, après fusion du sultat d’u e it atio su ha u e de es o figu atio s du ouvel tat de la o figu atio à
99
Figure 2-15 : Échec d'une récursion simple sur les quatre fils.
Le su oût de es diff e ts a is es lo s du al ul de l it atio sui a te lo s ue e sultat est pas d jà o u est lai e e t appa e t. Pou auta t, le fait de pouvoir accéder au résultat directement (u e fois u il a d jà t al ul ) permet de contrebalancer tous es oûts da s le as où l o et ou e suffisa e t sou e t les es o figu atio s de cellules (ce point sera développé plus en détail par la suite).
Mais l algo ith e Hash-Life e se o te te pas de sau ega de le sultat de l it atio suivante, il peut sauvegarder le résultat de plusieurs itérations. Bien entendu, pour chaque it atio , le œu du u e a t e u peu plus petit. Da s l e e ple de la Figure 2-14, étant do ue l o ne s i t esse u au e t e du u e de pa et ue ous a o s t a aill avec un contour de deux cellules en utilisant le parent (de 8 par 8), il est alors possible de sauvegarder le résultat après deux itérations.
De a i e g ale, ta t do ue l o a ipule u uadt ee, le œu se a toujou s d u e taille deu fois oi d e ue l espa e i itial da s l e e ple de la Figure 2-14, un espa e de de ie t u espa e de . Il est alo s possi le d effe tue N / it atio s à l a a e sa s pe d e d i fo atio s où N est le ôt de l espa e initial. Cette technique est t s puissa te pou u u e de pa , o pou a alise it atio s d u oup , elle pe et de alise t s ite le al ul d u g a d o e d it atio s. Pou auta t, ette te h i ue est ia le ue lo s ue les résultats intermédiaires ne sont pas nécessaires.
100 U e e pli atio o pl te e a glais de l i pl e tatio de l algo ith e est a essi le su le site DrDobbs8ou à t a e s l i pl e tatio li e du logi iel Goll 9.
2.2.3 Limites de l’algorithme Hash-Life
Selon les as d utilisatio , l algo ith e peut- t e d u e g a de effi a it , ou peu e ta le, pénalisant en terme de vitesse de calcul voire même inutilisable.
Son efficacité va dépendre de la réapparition de configurations de cellules. Si celles-ci sont souvent et ou es, le su oût du t aite e t i itial pou le al ul de l it atio sui a te ou des itérations suivantes) est rapidement compensé. Plus il y a de nouvelles configurations
ui appa aisse t guli e e t et plus l effi a it de l algo ith e a huter.
La appa itio des o i aiso s a do a oi u effet p i o dial su l effi a it d u tel algorithme. La proportion de réapparitions, si elle e peut pas t e ta lie à l a a e sa s o ait e l tat i itial de l auto ate peut t e esti e. Ai si, plusieurs facteurs connus à priori vont avoir un impact sur la réapparition des configurations de cellules :
- Le o e d tats possi les pour une cellule.
Il est bien évident que, plus le o e d tats a epta les pou u e ellule lo s d u e simulation est faible, plus le nombre de combinaisons est limité, et donc plus les chances de retrouver une configuration déjà rencontrée sont grandes.
Un espace de 16 cellules possédera ainsi N16 configurations différentes (où N est le o e d tats diff e ts ue peut prendre une cellule). On a donc 65 536 o figu atio s diff e tes da s le as d u auto ate à deu tats o e le Jeu de la Vie . Si le o e d tats augmente, le nombre de configurations différentes augmente très rapidement : pour N = 4, on a déjà plus de quatre milliards de configurations différentes (4 294 967 296).
- Les gles de l auto ate ellulai e.
Si le o e d tats possi les pou u e ellule i flue fo te e t la appa itio des configurations, les règles sont toutes aussi importantes. En effet, selon les règles utilisées, le nombre de combinaisons pouvant apparaître au cours de la simulation
8
http://drdobbs.com/high-performance-computing/184406478?pgno=1 : Dernier accès le 07/11/2011 (les liens vers les figures ne sont plus correct, accéder à celles- i ia les pages sui a tes e as de l a ti le .
101 peuvent être limitées et donc les réapparitions de configurations de cellules déjà connues seront plus courantes.
Pou ep e d e u e ou elle fois l e e ple du jeu de la vie, hormis à l i itialisatio , une configuration 4x4 ne pourra jamais comprendre une totalité de cellules vivantes. Pou l algo ith e Wi eWo ld, la ueue de l le t o e se a ja ais sui ie de la t te de l le t o , es o t ai tes di i ua t d auta t le o e de o figu atio s possibles.
Pa ailleu s, u i o ie t ajeu de l algo ith e a tuel est u il est pas adapt au od les d auto ates ellulai es sto hasti ues. E effet, Hash-Life epose su l utilisatio de la mémoïzation et sau e le sultat du al ul d u e ou plusieu s it atio s. O , a e u modèle stochastique, ce résultat peut t e diff e t à ha ue fois u il de ait t e al ul . La mémoïzation et do l algo ith e Hash-Life so t do i utilisa les, e l tat, a e des modèles stochastiques.
Conclusion
L tude de la modélisation des systèmes complexes pose de nombreux problèmes aux i fo ati ie s. Les o t ai tes de la od lisatio , u elles soient multi-échelles ou non, se retrouvent e out de haî e lo s de l i pl e tation informatique. Ainsi, les différentes formes de modélisation des problèmes nécessitent des solutions différentes. Pour pouvoir résoudre plus simplement ces problématiques variées, il est ainsi nécessaire de disposer d u outil de od lisatio et de simulation le plus générique possible. La PGMS a été développée dans ce but. Si la PGMS est pour le moment cantonnée à des problèmes simples, l o je tif d u tel outil est de pe ett e la si ulatio d u g a d o e de s st es, e particulier les systèmes complexes.
M e lo s u u e appli atio fi ie d u d eloppe e t optimal, les contraintes matérielles limitent ses performances. Il est alors parfois obligatoire, pour simuler des systèmes plus importants, d a oi e ou s à la pa all lisatio de l application pour disposer de pe fo a es aiso a les. Si l utilisatio de luste s ou de g illes de calcul permet de dispose d i e ses puissances de al ul, l utilisatio des GPU pou alise des al uls scientifiques est une alternative de plus en plus séduisante. La puissance de ces derniers ne cesse en effet de croire alors même que celle des microprocesseurs conventionnels a
102 te da e à stag e . D aut e pa t, l apparition d API pe etta t d effe tue des al uls généralistes simplement sur de telles cartes (CUDA et OpenCL e pa ti ulie à l aide de l app o he SIMT Si gle I st u tio Multiple Th ead a g a de e t a l le d eloppe e t d appli atio s g alistes su GPU. Dans notre contexte nous avons retenu cette solution qui se révèle tout à fait adaptée à la problématique de performance obtenue sur une machine de table.
Pou auta t, la pa all lisatio de l appli atio est pas toujours la seule solution existante pou a lio e les pe fo a es d u e appli atio . Pour bien des problèmes, un ha ge e t d algo ith e peut fortement fai e a ie les pe fo a es. C est pa e e ple le cas des automates cellulaires où l algo ith e Hash-Life permet dans de très nombreux cas une amélioration drastique des performances.
Dans le contexte de la PGMS, la si ulatio d auto ates e trois dimensions est essentielle, nous avons cependant constaté que les meilleures implémentations o t alheu euse e t été étudiées que dans le cas de modèles en deux dimensions. En effet, les recherches sur des modèles en trois dimensions sont rares.
Mo t a ail a do po t su plusieu s a es, l e jeu esta t toujou s l a lio atio des pe fo a es de l appli atio . Des t a au o t ai si t effe tu s su les auto ates cellulaires et le calcul de champs afi d a lio e les performances de modèles utilisant ces outils. Dans ce but et pou pe ett e à l appli atio d t e la plus effi a e possi le, différentes options ont été étudiées : optimisation du code existant, la modification de l algo ith e utilis ou la parallélisation sur GPU.
Étant do l usage p i il gi da s es t a au de la parallélisation à base de GPU pour améliorer les performances de la PGMS, nous avons souhaité présenter l API CUDA de façon pédagogique dans le chapitre qui suit. L e pli atio du hoi de ette API plutôt u u e aut e et la présentation complète de celle-ci sont le sujet du prochain chapitre.
103
Développement sur architecture hybride
à l’aide de l’API CUDA
104
3 Développement sur architecture hybride à l’aide de l’API CUDA
Introduction
Si le potentiel des cartes graphiques en termes de performances brutes est plus à démontrer, il est cependant nécessaire de disposer des bons outils et d u e o e formation pour pouvoir en tirer le meilleur. Dans le but de faciliter la tâche des développeurs, u o e i po ta t d API pe etta t la alisatio de al uls sur GPU est aujou d hui dispo i le. Au début de ma thèse, en 2009, deux API majeures étaient disponibles pour la réalisation de calculs su a hite tu e h ide. Il s agissait de l API CUDA proposée par NVIDIA et de l API Ope CL p oposée par Khronos. Dans notre contexte de thèse CIFRE, le choix s est po t su la pa all lisatio su GPU à l aide de l API p opos e pa NVIDIA.
Les raisons de e hoi so t ultiples. Tout d a o d, u e des do es les plus i po ta tes a bien entendu été la performance des deux API. Or, pour une même application, les pe fo a es des appli atio s alis es à l aide de CUDA taient nettement plus performantes que elles alis es à l aide d Ope CL (qui étaient parfois jus u à % plus lente) (Karimi, Dickson et Hamze 2010). Cette différence était majoritairement due à une volonté de NVIDIA de mettre en avant son API et donc d optimise l utilisatio de ses a tes graphiques pour son API. Cette mentalité a fortement évolué depuis le début de ma thèse et les nouveaux « drivers » OpenCL pour les cartes graphiques NVIDIA sont beaucoup plus performants.
La production par NVIDIA de cartes graphiques très performantes dédiées au calcul généraliste a également largement contribué au choix final. En effet, aussi performante u elle soit, l API CUDA est pou le o e t utilisa le u a e des GPU NVIDIA. Il est donc nécessaire de disposer du matériel le plus adapté pour obtenir les meilleures performances. En 2008, NVIDIA proposait déjà du matériel très performant spécialisé dans le calcul généraliste : la carte Tesla M1060 pour les serveurs et la carte C1060 pour les stations de travail fournissaient déjà 240 unités de calcul en virgules flottantes cadencées jus u à 1,44GHz.
De plus, u plus g a d o e d outils taie t dispo i les pour aider au développement d appli atio s à l aide de l API CUDA alors que pou Ope CL l off e tait oi s toff e à
105 l po ue. E pa ti ulie , la p se e d u d ogueu i spi de gd et d u p ofileu a t très précieuse lors de l opti isatio de la parallélisation de notre application. Enfin, la popula it plus i po ta te de l API CUDA a permis de disposer de davantage de ressources ; e ui est loi d t e gligea le lo s ue l o t a aille su u e API e o e t s jeune dans un contexte limité par le temps.
Ce so t es aiso s ui o t guid le hoi de l API à utilise . Pour autant, il est important de noter que le but a toujours t de este le plus g i ue possi le e li ita t l utilisatio de toutes les fonctions propres à l API CUDA. Pa e e ple, les fo tio s proposées par CUDA afin de simplifier le traitement des e eu s o t pas t utilis es afi de o se e u d oupage a i u pa appo t à l API CUDA. Ai si, si le hoi e ait u jou à être fait de po te la pa all lisatio depuis CUDA e s Ope CL, u i i u d effo ts serait nécessaire. La suite de ce chapitre va donc détailler les p i ipes de la p og a atio su GPU à l aide de l API CUDA. U e p e i e pa tie t aite a de l utilisatio des th eads, des lo s de th eads et des g illes de lo s au sei de l API CUDA a a t d i t odui e assez si ple e t l ordonnancement de tous ces éléments par le GPU. La seconde partie décrira les différentes oi es dispo i les su u GPU et la faço de les utilise à l aide de CUDA. Enfin, dans une de i e pa tie, des l e ts o pl e tai es de l API CUDA se o t p se tés : la gestion des erreurs, le calcul en nombres flottants et les flux asynchrones.
3.1 Gestion des threads
Pou e pas a oi à se sou ie des d tails d i pl e tatio du pa adig e SIMT p se t e dans la partie 2.1.4.2 - L app o he Single Instruction Multiple Thread (SIMT)L app o he Single Instruction Multiple Thread (SIMT)) et da hite tu e p se t e da s la pa tie 2.1.4.3 - L a hite tu e des processeurs graphiques à but génériqueL a hite tu e des processeurs graphiques à but générique), une API la plus simple possible a donc été p opos e pa NVIDIA. Pou pe ett e u e utilisatio si ple, CUDA s appuie su le préprocesseur nvcc qui permet de générer, depuis un fichier écrit en CUDA, un fichier C++ u il est possi le de o pile a e g++ (NVIDIA 2008). Cette st at gie a l a a tage de pe ett e à CUDA d utilise des ots l s et des s ta es pa ti uli es pou la o eption et l appel de th eads CUDA.
106 3.1.1 Principe des Grilles, Blocs et Threads
Pour exploiter les o euses u it s de al ul p se tes su le GPU, il est pas essai e de créer manuellement autant de threads ue l o souhaite e e ute et d affe te ha u d eu à u e u it de al ul. Il suffit, lo s de l appel d u e fo tio à e ute su le GPU (appelée kernel dans la terminologie CUDA), de préciser quel est le nombre de threads qui doit se charger de son exécution. Ce nombre est fourni en renseignant la dimension des
blocs (le nombre de threads compris dans un bloc) et la dimension de la grille (le nombre de blocs compris dans la grille).
3.1.1.1 Threads
Les deux notions de bloc et de grille seront détaillées plus tard, il suffit pour le moment de o p e d e u u bloc contient un certain nombre de threads et que la grille contient un certain nombre de blocs.
Les appels sont donc de la forme suivante :
ma_fonction<<< dimension_de_la_grille, dimension_des_blocs >>>(
mes_parametres );