C ompute U nified D evice A rchitecture Présentation d’un Template simple pour une méthode de Monte-Carlo en finance Présentation au GT GPU Laboratoire.

Présentation au sujet: "C ompute U nified D evice A rchitecture Présentation d’un Template simple pour une méthode de Monte-Carlo en finance Présentation au GT GPU Laboratoire."— Transcription de la présentation:

1 C ompute U nified D evice A rchitecture Présentation d’un Template simple pour une méthode de Monte-Carlo en finance Présentation au GT GPU Laboratoire Jacques-Louis Lions Hugues Henri Liniger, le 28 mai 2009

2 plan Présentation de CUDA - point de vue matériel - point de vue logiciel Présentation Template utilisé - contraintes - mise en œuvre Résultats des tests - exemples d’évaluations - Core 2 2.4 Ghz vs 285gtx Limites rencontrées - Il semble qu’on ne peut pas tout faire.

3 Petit historique GPGPU 90’s, utilisation du câblage spécifique ( zbuffer, rasterizer) des GPU pour des problèmes de chemins optimaux et de diagrammes de Voronoï. Problème! 2 mondes et 2 langages: Les experts GPU et les chercheurs désirant tiré parti de cette architecture parallèle. Là où un programmeur 3D parle de shader, de texture ou de fragment un adepte de la programmation parallèle parle de stream, de kernel, de scatter ou de gather. La première difficulté consiste donc à trouver des analogies entre deux mondes distincts : – un stream - flux d’éléments de même type - peut être représenté sur le GPU par une texture. En langages de programmation classiques ce n’est rien d’autre qu’un tableau. – un kernel, ou noyau est le programme qui va être appliqué à chaque élément du flux, c’est le pixel shader. Conceptuellement c’est la boucle interne d’un programme classique – pour lire le résultat de l’application d’un kernel sur un stream il faut effectuer un rendu dans une texture. Evidemment il n’y a pas d’équivalent sur un CPU qui a un accès total à la mémoire. – pour contrôler l’endroit où l’on souhaite écrire en mémoire (scatter) il faut le faire dans un vertex shader car un pixel shader ne peut modifier les coordonnées du pixel en cours de traitement – … 2000’s, apparition de BrookGPU, presenté comme « C with Streams ». BrookGPU utilise les 2 API graphiques de l’époque: Direct3D et openGL pour transformer le GPU en coprocesseur parallèle. Brook est l’ensemble d’un compilateur C++ pour les.br, et un ensemble de librairie liant le code aux drivers des API 3D et CPU ( DX9, Open GL, et x86) Les gros problèmes de Brook viennent d’une compatibilité remise en cause à chaque fois que les drivers de GPU sont mis à jours, et d’un grand nombre de couche d’abstraction ralentissant forcement le travail. Non utilisable de manière professionnel dans l’état.

4 2000: Nvidia acquière 3dfx (connaissance multi GPU, SLI..), et une partie des chercheurs de brook intègrent Nvidia. Les autres seront acheter par AMD/ATI pour créer Brook+ ( ATI Stream aujourd’hui) Objectif: se passer de l’API 3D. Petit historique GPGPU Schéma de fonctionnement de BrookSchéma de fonctionnement de CUDA

5 Présentation de CUDA 1/ définitions & point de vue matériel Langage propriétaire Nvidia. Utilisation du GPU comme d’un ensemble de coprocesseurs massivement paralléle. Terminologie propre au monde GPGPU nvidia. – Thread : un thread en CUDA consiste en un élément de base des données à traiter. – Warp : un warp est un ensemble de 32 threads, il s'agit de la taille minimale des données traitées de façon SIMD par un multiprocesseur. Mais cette granularité n'est toujours pas suffisante pour être facilement utilisable par un programmeur, ainsi en CUDA on ne manipule pas directement des warps, on travaille avec des blocs. – Bloc : un bloc peut contenir de 64 à 512 threads. Enfin ces blocs sont réunis dans des Grilles. – Kernel : un kernel ou noyau de programmation peut être vu comme une fonction appliquée à un ensemble de données subdivisé en blocs. Le nombre de blocs traités simultanément par le GPU est intimement lié aux ressources du hardware comme nous le verrons plus loin. Ainsi, le modèle de programmation en CUDA peut paraître simple : il considère une grille composée d'un ensemble de blocs qui exécutent simultanément des threads. Le nombre de blocs dans une grille permet d’abstraire totalement cette contrainte et d’appliquer un kernel à une grande quantité de threads en un seul appel, sans se soucier de ressources fixées. Le runtime CUDA se charge de décomposer le tout pour nous. Ce modèle est ainsi extrêmement extensible : si un hardware a peu de ressources il exécute les blocs séquentiellement, à l’inverse s’il dispose d’un très grand nombre d’unités il peut les traiter en parallèle. Le même code permet donc de cibler à la fois les GPU d’entrée de gamme, les GPU haut de gamme voire les GPU futurs.

6 Modèle de programmation en CUDA Présentation de CUDA 1/ point de vue matériel Exécuté par un unique multiprocesseur Partagé par tous les threads d’un bloc. Propriété pouvant être utile pour certain calcul.

7 une carte graphique Nvidia peut être vu comme une grosse unité de calcul divisée en un ensemble de microprocesseurs au niveau desquels les instructions sont exécutées par groupes de warps à travers des processeurs généraux. Présentation de CUDA 1/point de vue matériel Architecture GPU Nvidia 16 multiprocesseurs pour les G80/92, 30 pour G200 de 8 UAL Les multiprocesseurs disposent de 8192 registres, peuvent accepter jusqu’à 8 blocs actifs en même temps. Le nombre de Wrap actifs est lui limité à 24 (768 threads) optimiser un programme CUDA consiste donc essentiellement à équilibrer au mieux le nombre de blocs et leurs tailles : plus de threads par blocs s'avère utile pour mieux masquer la latence des opérations mémoires mais d'un autre côté cela diminue le nombre de registres disponibles par threads Remarque: on voit que des blocs de 512 threads seraient inefficaces ( 256 ou 128 c’est mieux)

8 Quelques extensions au langage C – qualificateurs s'appliquant aux fonctions _GLOBAL_ : placé devant une fonction indique que celle-ci est un kernel _DEVICE_ : désigne une fonction exécutée par le GPU appelée à partir du GPU (i.e. depuis une fonction _DEVICE_ ou _GLOBAL_). _HOST_ : optionnel, il désigne fonction traditionnelle – qualificateurs s'appliquant à la mémoire _SHARED_: indique que la variable sera dans la Shared Memory du bloc Présentation de CUDA 2/point de vue logiciel Une fonction sur GPU est de type Void, et ne peux gérer de mémoire globale. Une fonction __GLOBAL__ est appelée en précisant la configuration de son exécution. Concrètement le nombre de Grilles ( facultatif), Blocs et Threads.

9 Une bonne connaissance de l’architecture semble requise pour le choix du nombre de grilles, blocs et Threads. Les fonctions GPU ne gèrent pas la mémoire globale – le compilateur ne le sais pas forcement… Une simulation de Monte-Carlo est volumineuse, et la mémoire GPU limitée. Les allers retours mémoire système, mémoire GPU sont à proscrire. L’utilisation de Double est 8x plus lente que l’utilisation de Float. Calcul virgule flottante IEEE 754 uniquement à partir de génération G200. Pas de nombres aléatoires sur GPU. Présentation du Template 1/ Les contraintes

10 Problème des nombres aléatoires. – Génération de nombres pseudo aléatoire ( Monte Carlo), ou quasi-aléatoires avec des suites à discrépance faible (Quazi Monte Carlo)? Utilisation de Mersenne Twister ( déjà 4x plus rapide que rand() en C) qui est parallélisé par Nvidia ( code incomplet dans le SDK!). MT passe avec succès l’ensemble des tests d’uniformité et de non corrélation des packages DIE HARD et DIE HARDER – ce n’est pas le cas de rand(). Utilisation de suites à discrépance faible multidimensionnelles. Ex: Halton, suite du tore, Sobol… – Intérêts des suites à discrépance faible. Pas besoin de code. Asymptotiquement meilleures que les suites pseudo aléatoire: Présentation du Template 2/ Mise en œuvre

11 Problème des nombres aléatoires – Inconvénients des suites à discrépance faible Difficile d’avoir un intervalle de confiance Dégradation des propretés avec la dimension. Ici la dimension c’est le nombre de pas de temps. regardons les corrélations entre dimensions n et n+1 pour Halton, suite du tore, et Sobol. Présentation du Template 2/ Mise en œuvre

12 Problème des nombres aléatoires – Inconvénients des suites à discrépance faible Difficile d’avoir un intervalle de confiance Dégradation des propretés avec la dimension. Ici la dimension c’est le nombre de pas de temps. Regardons une application du théorème avec f(X) = (x1 +.. +Xd ) / d, pour d dans [|1;200|], avec Halton, suite du tore, et Sobol: Présentation du Template 2/ Mise en œuvre

13 Problème des nombres aléatoires Mersenne twister – voir site officiel et papier de Victor Podlozhnyuk chez Nvidia. Dans mon code, il y a la fonction « vectrand » qui sort des variables aléatoires de loi U)0,1( et N(0,1), sous forme float ou Hexadécimal pour les tests DIE HARD et DIE HARDER. Mersenne twister s’améliore avec la taille de l’échantillon. En gros 200x plus rapide sur 285gtx que la même demande avec Rand() sur CPU. 16000 nombres 100000 nombres Kurtosys 0.09, coef d’assymetrie 0.007, JB: 42Kurtosys 1, coef d’assymetrie -0.7, JB: 163 JB: 300 Présentation du Template 2/ Mise en œuvre

14 Limitation mémoire GPU – 1GO sur 285 GTX, déjà partiellement utilisée ( pas d’indication sur l’utilisation en cours) – Solution temporaire: ce limiter à 750MO de données… – Le volume requit peut être supérieur à 750 MO, utilisation de tableau de stockage de taille réduite dans le GPU. – Générer des SEEDS MT indépendantes. Schéma du modèle – Initialisation CUDA et MT : recherche de la carte, chargement des paramètres initiaux pour MT parallèle, démarrage d’un timer pour génération de SEEDS indépendantes – Calcul des besoins en mémoire pour répondre au problème – Création des tableaux sur GPU pour stockage des résultats réduits du problème. – Choix du nombre de blocs et threads ( limité le nombre de thread pour conserver suffisamment de registres, ne pas prendre trop de thread par bloc) – Découper le nombre de tests en morceaux requérant la mémoire limite, exécuter le premier morceau, sauver les résultats dans les tableau de stockage, nettoyer de la mémoire les données du premier morceau de test, etc. – Transfert des tableaux de stockage de résultats réduits sur mémoire centrale. – Traitement des données, et nettoyage mémoire. Présentation du Template 2/ Mise en œuvre

15 Résultats des tests 1/ exemple d’évaluations Réduction de variance: – Variables antithétiques – Variables de Contrôle : d’espérance nulle et, on peut optimiser avec Pour un call europeen on utilise la parité Call Put: et le paramètre minimisant est Cette variable de contrôle permet un recentrage, mais les formules du calcul de grecque par processus tangent et calcul de Malliavin changent un peu. ( voir compte rendu projet DEA) – Echantillonnage d’importance: C’est l’utilisation de la formule de changement de probabilité de Girsanov pour appliquer un drift permettant de centrer la diffusion sur les endroits ou il y a de l’information, c’est-à-dire dans la monnaie.

16 Comparaison des Schéma de discrétisation Euler / Mihlstein Euler ( naïf) : Mihlstein : Call 1 ans, spot 100, strike 100, risk free 5%, volatilité 20%, 10000 tests : Résultats des tests 1/ exemple d’évaluations

17 Calcul des Grecques du call – Différence finie à pas fixe choix de ε est compromis entre biais ( augmente avec ε ) et variance ( diminue avec ε ) – Différence finie à pas décroissant. ε devient une suite optimale. – Processus tangent: dérivation sous E du paramètre donné Il faut des pay off régulier Résultats des tests 1/ exemple d’évaluations

18 Calcul des Grecques du call – Malliavin – Propriétés: – Pour le call: Résultats des tests 1/ exemple d’évaluations

19 Comparons les méthodes Processus tangent et plus intéressant pour les pay-offs réguliers: pas d’erreur de discrétisation Malliavin a utilisé uniquement dans les cas ou on a pas le choix.

20 Pseudo Monte Carlo vs Quasi Monte Carlo – Sobol & Halton: convergence rapide, et pas besoin de recalculer les suites. Mais pas d’Intervalle de confiance simple, et mauvaise propriétés d’autocorrélation avec la dimension. – Pseudo Monte carlo: possibilité de donner des intervalles de confiance facilement. MT quasiment illimité en taille d’échantillon Résultats des tests 1/ Exemple d’utilisation

21 Utilisation de L’importance Sampling. – priçons un put 1 ans de strike 110, spot 100, volatilité 30% et taux sans risque 5%. on utilise un schéma d’Euler, avec 100 pas, et on indique la valeur selon là ou le drift nous emmène. Résultats des tests 1/ Exemple d’utilisation

22 Utilisation de L’algorithme proposé Résultats des tests 2/ CPU vs GPU

23 Tous doit être parallélisé, et évitons les transferts pendant le calcul – Calcul des moyennes sont CPU à 100%, et transfert à chaque fois que la mémoire est pleine: Résultats des tests 2/ CPU vs GPU

24 Tous doit être parallélisé, et évitons les transferts pendant le calcul – Calcul des moyennes sont CPU à 100%, et transfert à chaque fois que la mémoire est pleine Résultats des tests 2/ CPU vs GPU

25 Limites rencontrées Obligation technique de travailler avec des Floats Gestion de mémoire globale par GPU impossible – heureusement- mais gestion de Shared Memory inadaptée aux structure de données non standard. Pas de débuggeur réel. Pas de gestion des overflows: risque de plantage fréquent parce qu’on ne sait pas ce qu’il y a dans la mémoire graphique. Documentation sans doute non à jour: performance étrange entre CUDA1 et CUDA 2….

26 Remerciement & Liens Merci Victor Podlozhnyuk et Hyungon Ryu de Nvidia Utilitaires DIE HARD(ER): http://i.cs.hku.hk/~diehard/index.html http://www.stat.fsu.edu/pub/diehard/ http://www.phy.duke.edu/~rgb/General/dieharder.php Informations Nvidia CUDA http://www.nvidia.fr/object/cuda_what_is_fr.html http://www.presence-pc.com/tests/CUDA-CPU-GPU-22788/4/ http://www.presence-pc.com/tests/GeForce-GTX-260-280-22792/6/