Calcul de VaR par Monte-Carlo sur GPU

952 vues

Publié le

Rapport de projet encadré à l'INRIA Sophia Antipolis sur le sujet du calcul de Value-at-risk financier

Publié dans : Économie & finance
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
952
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
21
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Calcul de VaR par Monte-Carlo sur GPU

  1. 1. PFE sur la Monte-Carlo VaR Pierre Aït-Tahar – Paraita Wohler 7 mars 2013
  2. 2. VaR Monte-Carlo sur GPU Table des figures 1.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Histogramme de 1966080 tirages gaussiens . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3 Temps cumulé suivant l’optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4 Répartition du temps avec le prototype optimisé . . . . . . . . . . . . . . . . . . . . . 13 1.5 Répartition du temps avec la RNG sur GPU . . . . . . . . . . . . . . . . . . . . . . . 14 1.6 Comparatif des 2 versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1 résultat des benchmarks sur NEF - partie 1 . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 résultat des benchmarks sur NEF - partie 2 . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3 résultat des benchmarks sur NEF - partie 3 . . . . . . . . . . . . . . . . . . . . . . . . 21Pierre Aït-Tahar Paraita Wohler 1Master IMAFA - 2012/2013
  3. 3. VaR Monte-Carlo sur GPU Introduction0.1 Description de la VaR La VaR (de l’anglais value at risk, ou « valeur sous le risque ») est une notion utilisée généralementpour mesurer le risque de marché d’un portefeuille d’instruments financiers. Elle correspond au mon-tant des pertes qui ne devrait pas être dépassé avec une probabilité fixée sur un horizon temporel donné. Elle a été importée à la fin des années 1980 sur les marchés financiers aux États-Unis par la banqueBankers Trust et popularisée par la banque JP Morgan en 1993 et son service (gratuit et public) Risk-metrics puis adoptée sous une forme embryonnaire par le Comité de Bâle (Bâle II) pour les banqueset Solvabilité II pour les assurances. De nos jours, son utilisation est fortement demandé et deviendra obligatoire avec les accords deBâle III. La VaR d’un portefeuille dépend essentiellement de trois paramètres : – la distribution des résultats des portefeuilles. Souvent cette distribution est supposée normale, mais beaucoup d’acteurs financiers utilisent des distributions historiques. La difficulté réside dans la taille de l’échantillon historique : s’il est trop petit, les probabilités de pertes élevées sont peu précises, et s’il est trop grand, la cohérence temporelle des résultats est perdue (on compare des résultats non comparables) – le niveau de confiance choisi (95 ou 99 % en général) – l’horizon temporel choisi D’une manière générale, la VaR donne une estimation des pertes qui ne devrait pas être dépasséesauf évènement extrême sur un portefeuille pouvant être composé de différentes classes d’actifs.0.2 Description de la méthode de Monte Carlo L’appellation "méthode de Monte-Carlo" désigne toute méthode visant à calculer une valeur nu-mérique en utilisant des procédés aléatoires, c’est-à-dire des techniques probabilistes. Le nom de cetteméthode, vient des jeux de hasard pratiqués à Monte-Carlo. Elle a été inventée en 1947 par NicholasMetropolis, et publié pour la première fois en 1949 dans un article co-écrit avec Stanislaw Ulam. La méthode de simulation de Monte-Carlo permet d’introduire une approche statistique du risquedans une décision financière. Dans notre cas le calcul de VaR. La VaR-Monte-Carlo permet de simulerles valeurs historiques de nos actifs. Cependant ces simulations sont couteuses en temps de calcul.0.3 But du projet Pour le calcul d’une VaR Monte-Carlo, une majeur partie du temps est consacrée à la généra-tion des variables aléatoires. Les méthodes de Monte-Carlo demandent beaucoup de simulations parexemple pour un portefeuille de 100 actifs sans corrélation, sur une durée de 3 mois et 10 millions desimulations nous devrons générer 100 ∗ 90 ∗ 106 = 9 ∗ 109 variables aléatoires. Ce qui est considérablePierre Aït-Tahar Paraita Wohler 2Master IMAFA - 2012/2013
  4. 4. Simulation de la VaR Monte-Carlo sur GPUtout comme le temps d’exécution. Pour tenter de diminuer le temps d’exécution nous allons utiliser les cartes graphiques (GPU 1 ),leur coût d’achat et leur consommation sont inférieurs aux CPU et leur puissance de calcul ( en FLOP) est très nettement superieure. Pour programmer sur GPU nous avons besoin d’écrire dans un premier temps un code hôte dansnotre cas en C++, qui lancera a son tour le programme sur le GPU en OpenCL. L’utilisation de GPU nécessite un temps de lancement, entre la copie du code et le temps derapatrier les résultats. Pour compenser ces pertes nous allons toujours calculer un grand nombre desimulations ( au moins dans l’ordre du million ). 1. Graphical Processing UnitPierre Aït-Tahar Paraita Wohler 3Master IMAFA - 2012/2013
  5. 5. VaR Monte-Carlo sur GPU Partie 1 Var Monte-Carlo1.1 Simulation d’un actif sur une journée Nous sommes dans le modèle de Black & Sholes et nous allons utiliser un mouvement browniengéométrique : dSt = rSt dt + σSt dWT S0 > 0 La discrétisation est donnée par : σ2 )∗(ti+1 −ti )+σ∗dWt Sti+1 = Sti e(r− 2 On nous a demandé d’utiliser le mouvement brownien géométrique car il permet d’avoir des résul-tats plus précis.1.2 Précison de la distribution liée au Simulation de Monte-Carlo Nous allons simuler pour chaque actif une variation par jour jusqu’à l’horizon avec un Brownienqui suit une loi N (0; δt) avec δt qui correspond à un jour. La somme de ces estimations nous donneune estimation de la valeur de portefeuille : P a Cependant nous devons savoir combien de variablealéatoire nous devons simuler. Nous savons grâce au théorème de la loi des grands nombres ainsi que le théorème central limite,que : √ Pa − µ L a Pn = n n −→ N (0; 1) σ n−→∞ Avec a P n = E[P a ] On obtient l’intervalle de confiance de µ, au niveau de confiance α : a cα σ a cα σ µ ∈]P n − √ ; P n + √ [ n n cα représente le quantile de la loi Normale : α cα = Φ−1 (1 − ) 2 où Φ est la fonction de répartition de la loi Normale. Dans la majeur partie des cas, nous voulons un intervalle de confiance de niveau de confianceα = 0, 95 ou α = 0, 99, donc cα = 1, 92 ou cα = 1, 96.Pierre Aït-Tahar Paraita Wohler 4Master IMAFA - 2012/2013
  6. 6. Simulation de la VaR Monte-Carlo sur GPU La variance étant inconnue, on calcule un estimateur sans biais de celle-ci : n n 2 1 a a 1 a n a Sn = ((Pn )i − P n )2 = (Pn )2 − i (P )2 n−1 i=1 n−1 i=1 n−1 n De plus nous voulons une précision de 0.01% il faut donc que le rapport cαn < 0.01. Le problème √σest que nous calculons la variance pour un nombre de variables fixé par avance, il est fréquent que lenombre de variables aléatoires soit insuffisant pour la précision voulue. Nous devons donc re-simulerd’autres variables tant que l’inégalité n’est pas réalisée.Dans la pratique, avec le nombre très important de variables aléatoires que nous utilisons liés àutilisation de GPU, ( < 1 000 000 par actifs ) nous avons toujours un intervalle de confiance inferieurà 0.01%.1.3 Architecture du code Sur la figure 1.1 on peut voir l’architecture orientée objet de notre programme.Même si le framework OpenCL est écrit en C, le projet nécessitait d’utiliser le langage C++. Leprincipal avantage est la réutilisabilité de nos classes, en particulier le CLManager qui pourra êtreutilisé dans d’autres projets ou domaines. Aussi la compréhension de notre code est plus aisée cartoute la mécanique OpenCL est cachée à l’utilisateur de cette classe.Pierre Aït-Tahar Paraita Wohler 5Master IMAFA - 2012/2013
  7. 7. Simulation de la VaR Monte-Carlo sur GPU Figure 1.1 – Diagramme de classes En fait, OpenCL met à disposition une surcouche C++ vers le framework C mais il est encore àl’état d’ébauche et n’est pas vraiment utilisable (accès limité aux infos des devices par exemple).1.3.1 Mécanisme OpenCL OpenCL est à la fois un langage de programmation, qui sera exécuté sur un périphérique compatibleOpenCL, mais aussi un framework, c’est à dire un ensemble de fonctions utilisées pour envoyer descommandes OpenCL. L’idée est de pouvoir faire exécuter du calcul de manière parallèle en profitant du nombre importantde coeurs disponibles sur un GPU. OpenCL pousse l’abstraction plus loin en permettant de ne plusdifférencier le périphérique en lui même mais de ne voir que les coeurs (ou Comput Unit en termeOpenCL). Ainsi il est possible de parler à plusieurs GPU et même des CPU, OpenCL se démocratisantmême aux processeurs ARM. Lorsqu’on veut exécuter du code OpenCL, il est nécessaire dans un premier temps d’interroger lamachine pour connaître les différents périphériques compatibles. Il faut donc récupérer les platforms 1 , 1. pilote OpenCLPierre Aït-Tahar Paraita Wohler 6Master IMAFA - 2012/2013
  8. 8. Simulation de la VaR Monte-Carlo sur GPUen général le pilote d’affichage du GPU, mais si on possède plusieurs GPU de marques différentes,ont aurait alors plusieurs plateformes. Pour chacune des plateformes, il faut récupérer les devices 2 quisont composés de plusieurs Comput Units, eux mêmes composés de plusieurs processeurs. Une fois que l’on sait à qui on va donner du travail, il faut instancier une file de commande ainsiqu’un contexte, qui feront le lien entre la machine hôte et le GPU. L’exécution se fait en donnant le nombre de work-items 3 , pour simplifier un work-item = un thread.On peut grouper un ensemble de work-items (un work-group), ainsi tout les work-items d’un mêmework-group peuvent se partager des données, données qui seront stockées localement au ComputUnit, donc plus rapides. Néanmoins un Comput Unit possède une limite de taille maximale, taille quipeut être récupérée via une requête au device adéquat. Maximiser la taille des work-groups permetd’occuper au mieux le GPU, et l’accès aux données se fait plus rapidement. Aussi il faut garder entête que tous les work-items ne travaillent pas magiquement tous en même temps mais par paquetsde 32, ce paramètre est apelé la warp chez Nvidia et wavefront chez AMD. Les données circulant de l’hôte au GPU ont besoin d’être allouées explicitement, car tous les para-mètres sont passés par pointeurs. De même pour rappatrier un résultat, la mémoire allouée sur l’hôteaccueillera le résultat du calcul effectué sur le GPU. Une fois le calcul OpenCL effectué et le résultat récupéré, il faut relacher la main sur les ressourcesOpenCL, dans l’ordre suivant : 1. vidage de la file de commande 2. fermeture de la file de commande 3. désallocation des kernels utilisés 4. désallocation des kernels compilés (ou cl_program) 5. désallocation des buffers des paramètres des kernels 6. release de la main sur la file de commande 7. release de la main sur le contexte OpenCL Autant de mécanismes qui peuvent facilement amener à des erreurs, bugs, et autres problèmes decompréhension du code. En pratique on s’est rendu compte que le nombre de lignes pour le dialoguede l’hôte au GPU était presque 4 fois supérieur au nombre de ligne d’un kernel. D’ou cette volontéd’abstraire toute cette mécanique à l’aide de classes. 2. les périphériques pouvant effectuer du calcul OpenCL 3. instanciation du kernelPierre Aït-Tahar Paraita Wohler 7Master IMAFA - 2012/2013
  9. 9. Simulation de la VaR Monte-Carlo sur GPU1.3.2 Langage OpenCL Le langage OpenCL est dérivé du langage C, et est exécuté sur les devices compatibles. Il fautsavoir qu’une fois un kernel terminé, toute la mémoire utilisée est flushée, donc il n’est plus possibled’accéder aux mêmes données d’une exécution à l’autre. Voici un exemple de code OpenCL :__kernel void addition(__global int *v1, __global int *v2, __global int *res) { int id = get_global_id(0); res[id] = v1[id] + v2[id]; }Ce code fait l’addition de deux vecteurs, le résultat est stocké dans un troisième vecteur. Les librairies comme la stdlib.h ou time.h par exemple n’existent pas dans OpenCL, d’où la nécessitéde devoir implémenter soi même beaucoup de code, dans notre cas la génération de valeurs aléatoires.1.3.3 CLManager Le CLManager, lors de son instanciation, va récupérer auprès du framework toutes les platformset leurs devices respectifs. Une fois instancié, il faut spécifier le device nous allons utiliser avec l’appel à CLManager::init()(à ce moment on peut même spécifier si on souhaite chronométrer le temps que le calcul mettra surle GPU). En fait il est même possible d’utiliser plusieurs devices, mais avec la contrainte de tempsimposée, nous n’avons pas voulu plus approfondir dans ce sens. Ensuite il faut donner au CLManager le chemin vers le(s) kernel(s) 4 avec l’appel àCLManager::loadKernels(). Cette manière de charger le code métier OpenCL permet de travaillersur le code OpenCL sans avoir à recompiler l’ensemble de l’application. Une fois chargé, on compile ce code avec l’appel CLManager::compileKernel() qui prend en para-mètre le nom du kernel que l’on veut exécuter (si le fichier comprend plusieurs kernels par exemple). Il faut donner les paramètres d’appel du kernel, dans l’ordre où ils apparaissent dans la signaturedu kernel, avec CLManager::setKernelArg(). Enfin on lance l’exécution du kernel avec l’appel à CLManager::executeKernel() en lui spécifiantle nombre de work-items ainsi que le nom du kernel à exécuter. Le résultat de l’exécution se récupère avec l’appel à CLManager::getResultat(), qui va copier lerésultat depuis la mémoire du GPU vers la mémoire RAM de l’ordinateur, dans la variable que l’onaura instanciée auparavant. 4. c’est le nom qu’on donne à une fonction qui tournera sur GPUPierre Aït-Tahar Paraita Wohler 8Master IMAFA - 2012/2013
  10. 10. Simulation de la VaR Monte-Carlo sur GPU Voici un exemple d’utilisation :CLManager clm;clm.init(0,0);clm.loadKernels("meskernels.cl");clm.compileKernel("addition");int *v1 = (int *) calloc(10, sizeof(int));int *v2 = (int *) calloc(10, sizeof(int));int *resultat = (int *) calloc(10, sizeof(int));clm.setKernelArg("addition", 0, 10, sizeof(int), v1, false);clm.setKernelArg("addition", 1, 10, sizeof(int), v2, false);clm.setKernelArg("addition", 2, 10, sizeof(int), resultat, true);clm.executeKernel(10, "addition");clm.getResultat(); Ce code va donc faire l’addition de 2 vecteurs, comme la taille du vecteur est connue, je spécifie donclors de l’appel à clm.executeKernel() que je ne vais utiliser que 10 work-items. Aussi la méthodesetKernelArg() prend en paramètre : – le nom du kernel ("addition") – le numéro du paramètre (qui commence à 0) – le nombre d’élements de mon paramètre (il y a 10 entiers dans mon vecteur) – la taille d’un élement (la taille d’un entier en mémoire) – le pointeur vers la donnée qu’on va envoyer au kernel – false si c’est un paramètre d’entrée, true si c’est un paramètre de sortieLe résultat sera lisible dans la variable resultat. Le CLManager nous a permis de réduire considérablement le nombre de lignes dans le code applicatif,et ainsi de réduire les erreurs de code. Le constructeur de CLManager va demander les différentes ressources OpenCL disponibles sur lamachine, le destructeur quant à lui va relacher la main sur le périphérique.1.3.4 Portefeuille La classe Portefeuille contient les actifs d’un portefeuille, d’ailleurs on l’instancie avec le chemind’accès vers un fichier au format csv 5 , avec la structure suivante :<nom>;<rendement>;<volatilité>;<taux d’intérêts> Ce qui permet de charger dynamiquement un portefeuille sans avoir à coder le portefeuille en durdans le code. De plus la classe Portefeuille permet de récupérer aisément les caractérisques de celui ci,on peut donc récupérer : – l’ensemble des rendements sous forme d’array – l’ensemble des volatilités des actifs – l’ensemble des taux d’intérêts – le rendement total du portefeuille – le nombre d’actifs constituant ce portefeuille 5. Comma Separated Value : format où on sépare des données par un espace, une tabulation, un virgue ou unpoint-virgulePierre Aït-Tahar Paraita Wohler 9Master IMAFA - 2012/2013
  11. 11. Simulation de la VaR Monte-Carlo sur GPU1.3.5 Actif La classe Actif permet de représenter un actif au sens financier avec : – le nom du sous jacent sur quoi porte l’actif – le rendement du sous jacent – la volatilité – le taux d’intérêtsDans notre cas d’utilisation, nous nous limitons aux actions simples.1.4 Simulation des Variables Aléatoires Comme nous l’avions dit précédemment, c’est la génération des variables aléatoires qui prend leplus de temps. Dans un premier temps nous avions utilisé l’implémentation de Mersenne Twisterdonnée par la librairie Boost 6 , et qui nous a permis de nous concentrer sur le tirage des trajectoiressur GPU. Nous nous sommes rendus compte que l’algorithme de Mersenne Twister, même s’il était très rapideet bénéficiait d’une très grand période (219937 − 1), prenait beaucoup de place en mémoire, sachant quesi chaque work-item devait posséder son propre générateur, il nous faudrait sur le GPU une mémoirede l’ordre de #(work − items) ∗ 624 ∗ 4 octets, ce qui n’est pas envisageable. Nous nous sommes donc tournés vers l’algorithme MWC 7 , en particulier une implémentation exis-tante fonctionnant sur OpenCL, MWC64X 8 . La particularité de cette implémentation est que legénérateur n’occupe que 4 octets, pour une période de 232 . Si on est toujours limités en nombre dework-items, il est néanmoins possible de calculer la VaR sur un horizon très lointain, car le mêmegénérateur est utilisé jusqu’à l’horizon. Un article de l’auteur 9 de l’implémentation permet de vérifierla solidité de son générateur, et nous avons nous même vérifié que les valeurs aléatoires générées puistransformées en gaussiennes étaient cohérentes, voir la figure 1.2. On voit que le générateur est debonne qualité, dans la figure on a fait 1966080 tirages.1.5 Analyse des performances Pour la figure 1.3 la machine utilisée possède le matériel suivant : – CPU : iCore 7 avec 4 coeurs logiques – CPU : 8 Go de RAM – GPU : Geforce 330M – GPU : 6 Comput Units – GPU : 512 Mo de RAM – GPU : taille max de work-items par workgroup : 256 Dans la première barre, nous avons repris le code du prototype montré lors de la pré-soutenance,c’est à dire sans optimisation. La génération des valeurs aléatoires est faite côté CPU, le calcul destrajectoires sur le GPU, et le tri sur le CPU. 6. http://www.boost.org/doc/libs/1_53_0/doc/html/boost_random.html 7. Multiply-With-Carry de Marsaglia 8. http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html 9. http://cas.ee.ic.ac.uk/people/dt10/research/publications.htmlPierre Aït-Tahar Paraita Wohler 10Master IMAFA - 2012/2013
  12. 12. Simulation de la VaR Monte-Carlo sur GPU Figure 1.2 – Histogramme de 1966080 tirages gaussiens Figure 1.3 – Temps cumulé suivant l’optimisationPierre Aït-Tahar Paraita Wohler 11Master IMAFA - 2012/2013
  13. 13. Simulation de la VaR Monte-Carlo sur GPU Dans la deuxième barre, nous avons profité du fait que la mémoire dite globale dans la RAM duGPU pouvait être mise en cache, l’accès y est donc plus rapide, mais la quantité moins importante.Plus précisement cela s’est fait aisément sur la signature du kernel.Avant :__kernel void calcul_trajectoires(__global const float *RENDEMENTS, __global const float *VOLS, __global const float *TI, __global const float *ALEA, __global float *rendement, __global float *TIRAGES, __global const int *nb_actions, __global const int *horizon) {Après :__kernel void calcul_trajectoires(__global const float *RENDEMENTS, __global const float *VOLS, __global const float *TI, __global const float *ALEA, __constant float *rendement, __global float *TIRAGES, __constant int *nb_actions, __constant int *horizon) { Pour la troisième barre, nous avons décidé d’ajuster le nombre de tirages selon l’architecture duGPU, dans notre cas il fallait que le nombre de tirages soit multiple de : – 32 car c’est la taille de la warp chez NVidia – 6 car c’est le nombre de Comput Unit sur le GPU – 256 car c’est le nombre maximal de work-items dans un workgroupPour cela le CLManager demande la taille max de work-items dans un workgroup au pilote OpenCL,le reste des calculs se fera avec ce paramètre. Enfin pour la dernière barre nous avons réunit les 2 optimisations précédentes. L’optimisation laplus remarquable est bien évidemment l’ajustement du nombre de tirages. Pour le reste des tests, nous avons utilisé le réseau NEF mis en place par l’INRIA et qui met àdisposition plusieurs machines dont certaines équipées de GPU performants. La machine que nousavons donc utilisé est la suivante : – CPU : Intel Xeon 24 coeurs – CPU : 32 Go de RAM – GPU : NVidia Tesla C2050 – GPU : 2 x 3 Go de RAM – GPU : 2 x 12 Comput Units – GPU : taille max de work-items par workgroup : 1024Nous nous sommes néanmoins limité à l’utilisation d’un seul des GPU sur la Tesla C2050, mais OpenCLpermet l’utilisation de plusieurs GPU en même temps.Pierre Aït-Tahar Paraita Wohler 12Master IMAFA - 2012/2013
  14. 14. Simulation de la VaR Monte-Carlo sur GPU Figure 1.4 – Répartition du temps avec le prototype optimisé1.5.1 Répartition du temps dans l’application Sur la figure 1.4 on voit la répartition du temps dans l’application lorsqu’on a l’architecture suivante : – RNG 10 sur CPU – calcul des trajectoires sur GPU – tri sur CPUQui est en fait l’optimisation de notre prototype. Sur la figure 1.5 on voit la répartition du temps lorsqu’on bascule la génération des valeurs aléatoiressur le GPU. Ce qu’on qualifie de temps autre n’est que le reste du temps où le programme fait l’instanciationdes objets, des variables, l’écriture sur STDOUT, etc...On voit évidemment après avoir passé la RNG sur le GPU, ce qui nous ralentit encore est le tri quilui est resté sur CPU. En passant le tri sur GPU (dans l’état de l’art c’est un problème déjà résoluet des solutions bien optimisées existent déjà). Malheureusement nous n’avons pas eu le temps d’alleraussi loin dans l’implémentation.1.5.2 Passage à l’échelle Sur un nombre de plus en plus important de tirages, comment se comporte notre application ? Ilfaut garder à l’esprit que la taille limitée de la RAM côté GPU impacte grandement le nombre detirages, sur la figure 1.6 on voit néanmoins le temps pris par, en bleu le prototype optimisé (RNG surCPU), et en rouge la version finale que nous avons codé (RNG sur GPU). 10. Random Number GenerationPierre Aït-Tahar Paraita Wohler 13Master IMAFA - 2012/2013
  15. 15. Simulation de la VaR Monte-Carlo sur GPU Figure 1.5 – Répartition du temps avec la RNG sur GPU Figure 1.6 – Comparatif des 2 versionsPierre Aït-Tahar Paraita Wohler 14Master IMAFA - 2012/2013
  16. 16. Simulation de la VaR Monte-Carlo sur GPU La dernière version que nous avons codé passe non seulement sur un plus grand nombre de tirages,mais nous pouvons aussi calculer la VaR sur un horizon plus lointain (de la taille de la période denotre générateur). La place utilisée en mémoire n’est pas proportionnelle à l’horizon.Pierre Aït-Tahar Paraita Wohler 15Master IMAFA - 2012/2013
  17. 17. VaR Monte-Carlo sur GPU Partie 2 Conclusion2.1 Travail effectué Au cours de ce projet nous avons appris sur la difficulté de la programmation gpu,GPU commentutiliser les différentes mémoires, la répartition des workgroup, l’interaction entre le code GPU et lastructure de la carte. Nous avons implémenté un CLManager qui permet d’abstraire tous les appels OpenCL, et rendreainsi le code plus lisible et plus facile à débugger. Nous faisons la génération des gaussiennes ainsi que les calculs des trajectoires, seul le tri se faitcoté CPU.2.2 Évolutions possibles2.2.1 Gestion plus propre des erreurs Par manque de temps, pour debugger nous utilisons un mode de compilation dans lequel nousenvoyons le numéro de l’erreur avec une trace qui correspond au nom de la méthode qui l’a lancé.Pour l’utilisateur final, ça ne présente aucun problème car la gestion des erreurs actuelle est interne àla classe.Autrement nous aurions implémenté un système d’Exception, plus propre architecturalement parlant.2.2.2 La classe Actif Dans un cadre plus général il serait préférable d’avoir la classe Actif qui serait une interface, queplusieurs types d’actifs devraient implémenter, par exemple une Action serait un actif particulier. Lesimplémentations devraient pouvoir retourner leur rendement respectif.2.2.3 Spécialisation du CLManager Une classe CLManagerFi qui hériterait de CLManager permettrait de spécialiser le comportementde celui ci par exemple en prenant directement le portefeuille en paramètre, et selon la nature del’actif, chargerait le kernel adéquat.2.2.4 Optimisation plus poussée du découpage du travail Dans l’état actuel, CLManager ne gère qu’un seul device à la fois, il serait intéressant de pouvoirspécifier un ensemble de devices, et ainsi encore diminuer le temps de calcul. Par exemple sur NEF 1 ,qui est la plateforme qui nous a été mise à disposition, la machine que nous utilisions bénéficiait de 2devices, théoriquement nous aurions pu calculer 2 fois plus vite. 1. http://www-sop.inria.fr/dream/Cluster/OverViewPierre Aït-Tahar Paraita Wohler 16Master IMAFA - 2012/2013
  18. 18. Simulation de la VaR Monte-Carlo sur GPU2.2.5 Utilisation des variables antithétiques Suite au cours de M. Tanré nous avons vu l’intéret des variables antithétiques. Dans notre cas nous savons que : WT ∼ N (0, T ) σWT ∼ N (0, σ 2 T ) −σWT ∼ N (0, σ 2 T ) On peut en conclure qu’en utilisant cette propriété pour un même nombre de simulation nouspouvons générer 2 fois moins de variables aléatoires, ce qui représente un grand gain de temps. Uneautre utilisation aurait été si notre générateur de variables aléatoires avait une faible cyclicité, maisce n’est pas cas.2.2.6 Utilisation d’actifs correlés Dans notre cahier des charges nous avons comme hypothèse que tous nos actifs ne sont pas corrélés.Dans le cas contraire nous devons faire un changement de repère pour avoir une base où les actifs nele sont pas. La matrice de corrélation est par définition symétrique. Nous pouvons l’exprimer dans une base devecteurs propres. La librairie Boost possède des fonctions permettant de faire cette transformation.2.3 Gestion de projet2.3.1 Planning de travail Pour faire ce projet nous avons eu 2 mois où nous avons réparti les tâches de la manière suivante : Semaine 1 Analyse de la problématique Semaine 2 Analyse des problèmes liés à la programmation GPU Semaine 3 Début de la programmation Semaine 4 Fin d’implémentation Mersenne Twister Semaine 5 Simulation d’un actif sur une horizon Semaine 6 Calcul de la Var Monte-Carlo ( un actif ) Semaine 7 Calcul de la Var Monte-Carlo ( plusieurs actifs ) Semaine 8 Améliorations ( précisions de calculs, temps de calcul ) Nous avons réussi à respecter le planning prévisionnel, néanmoins nous regrettons de ne pas avoirpu bénéficier de plus de temps pour implémenter le tri sur GPU.2.4 Références – Options, futures et autres actifs dérivés - John Hull – Monte Carlo Methods in Financial Engineering - Paul Glasserman – http ://en.wikipedia.org/wiki/Mersenne_twister – http ://fr.wikipedia.org/wiki/Méthode_de_Box-Muller – http ://developer.amd.com/resources/heterogeneous-computing/opencl-zone/ – https ://developer.nvidia.com/opencl – http ://www.khronos.org/opencl/ – http ://www.giref.ulaval.ca/ãfortin/mat17442/documents/splines.pdf – http ://en.wikipedia.org/wiki/CUDA#Supported_GPUsPierre Aït-Tahar Paraita Wohler 17Master IMAFA - 2012/2013
  19. 19. VaR Monte-Carlo sur GPU Annexe Voici les résultats des benchmarks réalisés sur NEF :Pierre Aït-Tahar Paraita Wohler 18Master IMAFA - 2012/2013
  20. 20. Calcul1 Calcul2 RNG CPU seuil confiance 0,99 RNG GPU seuil confiance 0,99 Tirages GPU horizon 1 Tirages GPU horizon 1 Tri CPU Tri CPU nb tirages rendement spot VaR temps RNG (ms) temps tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) temps tirages+RNG nb tirages rendement spot VaR temps RNG+tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) 393 216 687,09 -657,83 540,92 0,98 82,34 4 371,03 3 746,80 541,90 393 216 687,09 -790,94 47,02 80,96 3 614,66 3 486,69 393 216 687,09 -657,83 537,87 0,98 82,00 4 294,06 3 673,21 538,84 393 216 687,09 -790,94 47,01 80,95 3 704,23 3 576,27 393 216 687,09 -657,83 536,86 0,98 81,99 3 850,97 3 231,14 537,84 393 216 687,09 -790,94 47,02 80,94 3 459,92 3 331,97 393 216 687,09 -657,83 543,73 0,98 82,01 3 974,90 3 348,19 544,71 393 216 687,09 -790,94 47,01 80,94 3 285,11 3 157,16 393 216 687,09 -657,83 537,43 0,98 82,00 3 843,52 3 223,11 538,41 393 216 687,09 -790,94 47,01 80,95 3 788,73 3 660,77 393 216 687,09 -657,83 539,55 0,98 81,99 3 858,07 3 235,54 540,53 393 216 687,09 -790,94 47,02 80,95 3 803,78 3 675,82Master IMAFA - 2012/2013 393 216 687,09 -657,83 539,69 0,97 81,99 3 901,74 3 279,09 540,66 393 216 687,09 -790,94 47,01 80,97 3 441,89 3 313,91 393 216 687,09 -657,83 538,04 0,98 81,98 4 065,55 3 444,55 539,02 393 216 687,09 -790,94 47,01 80,94 3 679,25 3 551,29 393 216 687,09 -657,83 537,85 0,98 82,00 4 034,53 3 413,71 538,83 393 216 687,09 -790,94 47,00 80,96 3 797,85 3 669,89Pierre Aït-Tahar Paraita Wohler 393 216 687,09 -657,83 539,63 0,97 82,00 4 048,23 3 425,62 540,61 393 216 687,09 -790,94 46,96 81,01 3 725,63 3 597,66 moyenne 539,16 0,98 82,03 4 024,26 3 402,10 540,13 moyenne 47,01 80,96 3 630,11 3 502,14 nb tirages rendement spot VaR temps RNG (ms) temps tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) temps tirages+RNG nb tirages rendement spot VaR temps RNG+tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) 786 432 687,09 -753,54 1 076,64 1,91 172,39 4 492,47 3 241,53 1 078,55 786 432 687,09 -790,94 97,01 171,01 3 810,88 3 542,86 786 432 687,09 -753,54 1 076,40 1,91 172,58 4 682,35 3 431,46 1 078,31 786 432 687,09 -790,94 97,04 171,05 3 767,23 3 499,14 786 432 687,09 -753,54 1 076,23 1,92 172,56 4 677,95 3 427,25 1 078,15 786 432 687,09 -790,94 97,02 171,67 3 905,55 3 636,86 786 432 687,09 -753,54 1 077,19 1,91 172,56 4 815,54 3 563,88 1 079,10 786 432 687,09 -790,94 97,02 171,07 3 555,40 3 287,32 786 432 687,09 -753,54 1 081,59 1,92 172,34 4 544,08 3 288,22 1 083,51 786 432 687,09 -790,94 97,02 171,23 3 702,35 3 434,10 786 432 687,09 -753,54 1 076,06 1,93 172,39 4 417,12 3 166,74 1 077,99 786 432 687,09 -790,94 97,02 171,05 3 463,30 3 195,23 786 432 687,09 -753,54 1 076,44 1,90 172,30 4 813,91 3 563,27 1 078,34 786 432 687,09 -790,94 97,02 171,11 3 532,03 3 263,90 786 432 687,09 -753,54 1 071,66 1,92 172,36 4 542,19 3 296,25 1 073,58 786 432 687,09 -790,94 97,03 171,77 3 978,40 3 709,60 786 432 687,09 -753,54 1 061,18 1,91 172,33 4 465,71 3 230,29 1 063,09 786 432 687,09 -790,94 97,05 171,06 3 554,09 3 285,98 19 786 432 687,09 -753,54 1 077,28 1,92 172,87 4 850,97 3 598,90 1 079,20 786 432 687,09 -790,94 97,03 171,03 3 596,08 3 328,03 moyenne 1 075,07 1,91 172,47 4 630,23 3 380,78 1 076,98 moyenne 97,03 171,20 3 686,53 3 418,30 nb tirages rendement spot VaR temps RNG (ms) temps tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) temps tirages+RNG nb tirages rendement spot VaR temps RNG+tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) 1 572 864 687,09 -789,48 2 037,10 3,80 363,06 5 536,64 3 132,68 2 040,90 1 572 864 687,09 -802,37 202,94 359,79 4 007,89 3 445,15 1 572 864 687,09 -789,48 2 006,92 3,79 364,05 5 883,81 3 509,05 2 010,71 1 572 864 687,09 -802,37 202,91 360,05 3 875,29 3 312,33 1 572 864 687,09 -789,48 1 957,04 3,79 363,10 5 532,39 3 208,46 1 960,83 1 572 864 687,09 -802,37 202,91 359,86 3 861,20 3 298,43 1 572 864 687,09 -789,48 1 980,81 3,78 363,61 5 737,60 3 389,40 1 984,59 1 572 864 687,09 -802,37 202,90 359,78 3 895,96 3 333,28 1 572 864 687,09 -789,48 1 880,00 3,81 363,43 5 540,76 3 293,52 1 883,81 1 572 864 687,09 -802,37 202,92 359,22 3 765,10 3 202,96 1 572 864 687,09 -789,48 2 006,87 3,79 363,42 5 547,46 3 173,38 2 010,66 1 572 864 687,09 -802,37 202,94 359,45 4 276,55 3 714,16 1 572 864 687,09 -789,48 2 129,92 3,78 363,67 5 873,55 3 376,17 2 133,70 1 572 864 687,09 -802,37 202,91 359,82 3 844,67 3 281,94 1 572 864 687,09 -789,48 2 000,65 3,79 363,52 5 685,67 3 317,71 2 004,44 1 572 864 687,09 -802,37 202,90 359,84 3 837,00 3 274,25 1 572 864 687,09 -789,48 2 105,73 3,79 364,10 5 867,23 3 393,61 2 109,52 1 572 864 687,09 -802,37 202,87 359,87 3 964,82 3 402,08 1 572 864 687,09 -789,48 2 094,55 3,80 363,32 5 681,53 3 219,86 2 098,35 1 572 864 687,09 -802,37 202,91 359,94 3 969,72 3 406,87 moyenne 2 019,96 3,79 363,53 5 688,66 3 301,38 2 023,75 moyenne 202,91 359,76 3 929,82 3 367,15 Figure 2.1 – résultat des benchmarks sur NEF - partie 1 Simulation de la VaR Monte-Carlo sur GPU
  21. 21. Calcul1 Calcul2 RNG CPU seuil confiance 0,99 RNG GPU seuil confiance 0,99 Tirages GPU horizon 1 Tirages GPU horizon 1 Tri CPU Tri CPU nb tirages rendement spot VaR temps RNG (ms) temps tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) temps tirages+RNG nb tirages rendement spot VaR temps RNG+tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) 3 145 728 687,09 -818,02 3 957,13 7,50 756,83 7 971,34 3 249,88 3 964,63 3 145 728 687,09 -879,44 423,97 749,95 4 731,18 3 557,26 3 145 728 687,09 -818,02 3 960,48 7,54 756,79 8 310,86 3 586,05 3 968,02 3 145 728 687,09 -879,44 423,93 716,56 4 387,72 3 247,24 3 145 728 687,09 -818,02 4 072,80 7,52 757,08 5 290,33 452,92 4 080,32 3 145 728 687,09 -879,44 423,83 749,92 4 814,97 3 641,22 3 145 728 687,09 -818,02 3 839,85 7,53 756,74 7 751,54 3 147,42 3 847,38 3 145 728 687,09 -879,44 423,91 750,34 4 472,41 3 298,17 3 145 728 687,09 -818,02 3 972,88 7,49 756,70 8 407,07 3 670,00 3 980,37 3 145 728 687,09 -879,44 423,90 750,17 4 668,71 3 494,65 3 145 728 687,09 -818,02 3 853,18 7,47 756,81 8 079,46 3 462,00 3 860,65 3 145 728 687,09 -879,44 423,81 750,84 4 480,11 3 305,46Master IMAFA - 2012/2013 3 145 728 687,09 -818,02 3 827,64 7,50 756,79 7 834,32 3 242,39 3 835,14 3 145 728 687,09 -879,44 423,56 749,83 4 606,90 3 433,51 3 145 728 687,09 -818,02 4 018,78 7,50 756,64 8 009,93 3 227,01 4 026,28 3 145 728 687,09 -879,44 423,58 749,97 4 782,17 3 608,62 3 145 728 687,09 -818,02 3 819,75 7,54 756,93 7 780,17 3 195,95 3 827,29 3 145 728 687,09 -879,44 423,91 750,39 4 836,94 3 662,64Pierre Aït-Tahar Paraita Wohler 3 145 728 687,09 -818,02 3 756,29 7,51 757,06 7 789,71 3 268,85 3 763,80 3 145 728 687,09 -879,44 423,88 750,56 4 449,23 3 274,79 moyenne 3 907,88 7,51 756,84 7 722,47 3 050,25 3 915,39 moyenne 423,83 746,85 4 623,03 3 452,35 nb tirages rendement spot VaR temps RNG (ms) temps tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) temps tirages+RNG nb tirages rendement spot VaR temps RNG+tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) 6 291 456 687,09 -824,05 7 768,01 14,99 1 570,28 12 612,00 3 258,72 7 783,00 6 291 456 687,09 -911,11 882,78 1 477,70 5 701,70 3 341,22 6 291 456 687,09 -824,05 7 478,21 14,98 1 570,53 12 701,00 3 637,28 7 493,19 6 291 456 687,09 -911,11 882,75 1 486,75 5 523,17 3 153,67 6 291 456 687,09 -824,05 7 841,44 14,99 1 467,63 12 554,00 3 229,94 7 856,43 6 291 456 687,09 -911,11 882,77 1 478,01 5 705,41 3 344,63 6 291 456 687,09 -824,05 7 653,26 14,93 1 452,07 12 478,00 3 357,74 7 668,19 6 291 456 687,09 -911,11 882,94 1 436,68 5 912,27 3 592,65 6 291 456 687,09 -824,05 7 730,33 14,96 1 570,97 12 943,50 3 627,24 7 745,29 6 291 456 687,09 -911,11 882,79 1 458,74 5 831,12 3 489,59 6 291 456 687,09 -824,05 7 546,97 14,99 1 570,53 12 419,90 3 287,41 7 561,96 6 291 456 687,09 -911,11 882,85 1 481,90 5 548,90 3 184,15 6 291 456 687,09 -824,05 7 480,56 14,92 1 567,62 12 465,90 3 402,80 7 495,48 6 291 456 687,09 -911,11 882,92 1 490,22 5 485,74 3 112,60 6 291 456 687,09 -824,05 7 493,26 14,96 1 570,60 12 274,60 3 195,78 7 508,22 6 291 456 687,09 -911,11 882,71 1 368,85 5 476,67 3 225,11 6 291 456 687,09 -824,05 7 666,38 14,98 1 554,54 12 709,80 3 473,90 7 681,36 6 291 456 687,09 -911,11 882,87 1 370,94 5 500,93 3 247,12 20 6 291 456 687,09 -824,05 7 813,94 14,99 1 570,30 12 704,60 3 305,37 7 828,93 6 291 456 687,09 -911,11 882,79 1 466,22 5 769,56 3 420,55 moyenne 7 647,24 14,97 1 546,51 12 586,33 3 377,62 7 662,20 moyenne 882,82 1 451,60 5 645,55 3 311,13 nb tirages rendement spot VaR temps RNG (ms) temps tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) temps tirages+RNG nb tirages rendement spot VaR temps RNG+tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) 12 582 912 687,09 -843,35 15 244,50 29,94 3 060,21 21 717,40 3 382,75 15 274,44 12 582 912 687,09 -911,11 1 839,26 2 854,58 8 091,06 3 397,22 12 582 912 687,09 -843,35 15 311,10 29,92 3 071,71 21 706,30 3 293,57 15 341,02 12 582 912 687,09 -911,11 1 838,98 2 851,97 8 355,97 3 665,02 12 582 912 687,09 -843,35 15 066,70 29,89 2 956,66 21 325,90 3 272,65 15 096,59 12 582 912 687,09 -911,11 1 838,95 2 868,62 8 318,63 3 611,06 12 582 912 687,09 -843,35 15 086,00 29,97 3 074,99 19 462,50 1 271,54 15 115,97 12 582 912 687,09 -911,11 1 838,94 2 854,32 8 209,10 3 515,84 12 582 912 687,09 -843,35 14 999,10 29,92 2 868,99 21 254,50 3 356,49 15 029,02 12 582 912 687,09 -911,11 1 838,97 2 852,52 7 990,98 3 299,49 12 582 912 687,09 -843,35 15 393,30 29,85 3 027,77 21 859,10 3 408,18 15 423,15 12 582 912 687,09 -911,11 1 839,17 2 851,50 8 297,00 3 606,33 12 582 912 687,09 -843,35 15 177,20 29,86 3 072,93 21 559,90 3 279,91 15 207,06 12 582 912 687,09 -911,11 1 839,03 2 851,90 8 007,41 3 316,48 12 582 912 687,09 -843,35 15 393,20 29,96 3 058,19 21 923,90 3 442,55 15 423,16 12 582 912 687,09 -911,11 1 838,97 2 852,15 7 820,83 3 129,71 12 582 912 687,09 -843,35 15 031,10 29,94 2 954,56 21 298,20 3 282,60 15 061,04 12 582 912 687,09 -911,11 1 839,03 2 851,25 8 064,58 3 374,30 12 582 912 687,09 -843,35 15 228,40 29,92 3 042,78 21 819,80 3 518,70 15 258,32 12 582 912 687,09 -911,11 1 838,99 2 851,16 8 081,35 3 391,20 moyenne 15 193,06 29,92 3 018,88 21 392,75 3 150,89 15 222,98 moyenne 1 839,03 2 854,00 8 123,69 3 430,67 Figure 2.2 – résultat des benchmarks sur NEF - partie 2 Simulation de la VaR Monte-Carlo sur GPU
  22. 22. Calcul1 Calcul2 RNG CPU seuil confiance 0,99 RNG GPU seuil confiance 0,99 Tirages GPU horizon 1 Tirages GPU horizon 1 Tri CPU Tri CPU nb tirages rendement spot VaR temps RNG (ms) temps tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) temps tirages+RNG nb tirages rendement spot VaR temps RNG+tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) 25 165 824 687,09 -843,35 29 921,50 59,84 6 079,38 39 656,40 3 595,68 29 981,34 25 165 824 687,09 -937,20 3 824,59 5 874,88 13 107,70 3 408,23 25 165 824 687,09 -843,35 30 309,40 59,81 6 096,70 39 917,60 3 451,69 30 369,21 25 165 824 687,09 -937,20 3 824,54 5 874,68 13 014,00 3 314,78 25 165 824 687,09 -843,35 30 404,00 59,80 5 980,93 39 895,50 3 450,77 30 463,80 25 165 824 687,09 -937,20 3 824,53 5 874,43 13 245,70 3 546,74 25 165 824 687,09 -843,35 30 016,20 59,59 6 074,10 39 777,90 3 628,01 30 075,79 25 165 824 687,09 -937,20 3 824,60 5 874,29 13 127,00 3 428,11 25 165 824 687,09 -843,35 30 072,30 59,83 6 087,09 39 736,70 3 517,48 30 132,13 25 165 824 687,09 -937,20 3 824,69 5 873,85 13 192,20 3 493,66 25 165 824 687,09 -843,35 30 053,60 59,69 6 098,51 39 645,90 3 434,10 30 113,29 25 165 824 687,09 -937,20 3 824,55 5 872,85 13 158,90 3 461,50Master IMAFA - 2012/2013 25 165 824 687,09 -843,35 30 279,10 59,91 6 087,37 39 946,80 3 520,42 30 339,01 25 165 824 687,09 -937,20 3 824,64 5 874,94 13 127,00 3 427,42 25 165 824 687,09 -843,35 30 162,30 59,61 6 046,72 40 104,80 3 836,17 30 221,91 25 165 824 687,09 -937,20 3 824,65 5 877,85 12 929,50 3 227,00 25 165 824 687,09 -843,35 29 924,30 59,77 6 086,54 39 639,30 3 568,69 29 984,07 25 165 824 687,09 -937,20 3 824,77 5 873,20 13 005,10 3 307,13Pierre Aït-Tahar Paraita Wohler 25 165 824 687,09 -843,35 29 873,20 59,73 6 073,56 39 637,80 3 631,31 29 932,93 25 165 824 687,09 -937,20 3 824,56 5 875,10 13 254,60 3 554,94 moyenne 30 101,59 59,76 6 071,09 39 795,87 3 563,43 30 161,35 moyenne 3 824,61 5 874,61 13 116,17 3 416,95 nb tirages rendement spot VaR temps RNG (ms) temps tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) temps tirages+RNG nb tirages rendement spot VaR temps RNG+tirages (ms) temps tri (ms) temps total (ms) temps autre (ms) 50 331 648 687,09 -866,30 60 717,10 119,43 12 207,70 76 822,70 3 778,47 60 836,53 50 331 648 687,09 -944,24 7 941,56 12 098,50 23 524,80 3 484,74 50 331 648 687,09 -866,30 60 099,80 119,62 12 179,40 74 646,20 2 247,38 60 219,42 50 331 648 687,09 -944,24 7 941,38 12 096,40 23 701,00 3 663,22 50 331 648 687,09 -866,30 60 206,10 119,62 12 197,30 76 439,90 3 916,88 60 325,72 50 331 648 687,09 -944,24 7 941,51 12 094,00 23 414,70 3 379,19 50 331 648 687,09 -866,30 59 855,90 119,19 12 198,90 76 004,80 3 830,81 59 975,09 50 331 648 687,09 -944,24 7 941,55 12 095,50 23 826,60 3 789,55 50 331 648 687,09 -866,30 60 452,40 119,55 12 185,80 76 694,20 3 936,45 60 571,95 50 331 648 687,09 -944,24 7 941,30 12 102,40 23 494,40 3 450,70 50 331 648 687,09 -866,30 60 065,20 119,28 12 079,70 76 117,00 3 852,82 60 184,48 50 331 648 687,09 -944,24 7 941,22 12 095,70 23 298,10 3 261,18 50 331 648 687,09 -866,30 60 660,10 119,38 12 161,50 77 074,10 4 133,12 60 779,48 50 331 648 687,09 -944,24 7 941,85 12 102,50 23 460,90 3 416,55 50 331 648 687,09 -866,30 60 332,40 119,38 12 208,70 76 446,20 3 785,72 60 451,78 50 331 648 687,09 -944,24 7 941,81 12 095,10 23 451,60 3 414,69 50 331 648 687,09 -866,30 60 625,20 119,46 12 076,10 77 044,80 4 224,04 60 744,66 50 331 648 687,09 -944,24 7 941,77 12 096,10 23 317,90 3 280,03 21 50 331 648 687,09 -866,30 60 372,90 119,59 12 208,90 76 487,50 3 786,11 60 492,49 50 331 648 687,09 -944,24 7 941,67 12 097,30 23 550,20 3 511,23 moyenne 60 338,71 119,45 12 170,40 76 377,74 3 749,18 60 458,16 moyenne 7 941,56 12 097,35 23 504,02 3 465,11 Figure 2.3 – résultat des benchmarks sur NEF - partie 3 Simulation de la VaR Monte-Carlo sur GPU

×