Calcul de VaR par Monte-Carlo sur GPU

PFE sur la Monte-Carlo VaR

Pierre Aït-Tahar – Paraita Wohler

7 mars 2013

VaR Monte-Carlo sur GPU

Table des ﬁgures

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

Pierre Aït-Tahar Paraita Wohler 1
Master IMAFA - 2012/2013


Introduction

0.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éralement
pour 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 banque
Bankers 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 banques
et Solvabilité II pour les assurances.

De nos jours, son utilisation est fortement demandé et deviendra obligatoire avec les accords de
Bâ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ée
sauf é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 cette
méthode, vient des jeux de hasard pratiqués à Monte-Carlo. Elle a été inventée en 1947 par Nicholas
Metropolis, 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 risque
dans une décision financière. Dans notre cas le calcul de VaR. La VaR-Monte-Carlo permet de simuler
les 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 par
exemple pour un portefeuille de 100 actifs sans corrélation, sur une durée de 3 mois et 10 millions de
simulations nous devrons générer 100 ∗ 90 ∗ 106 = 9 ∗ 109 variables aléatoires. Ce qui est considérable


Simulation de la VaR Monte-Carlo sur GPU

tout 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 dans
notre 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 de
rapatrier les résultats. Pour compenser ces pertes nous allons toujours calculer un grand nombre de
simulations ( au moins dans l’ordre du million ).

1. Graphical Processing Unit



Partie 1
Var Monte-Carlo

1.1 Simulation d’un actif sur une journée
Nous sommes dans le modèle de Black & Sholes et nous allons utiliser un mouvement brownien
gé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 Brownien
qui suit une loi N (0; δt) avec δt qui correspond à un jour. La somme de ces estimations nous donne
une estimation de la valeur de portefeuille : P a Cependant nous devons savoir combien de variable
alé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.



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 le
nombre de variables aléatoires soit insuffisant pour la précision voulue. Nous devons donc re-simuler
d’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++. Le
principal avantage est la réutilisabilité de nos classes, en particulier le CLManager qui pourra être
utilisé dans d’autres projets ou domaines. Aussi la compréhension de notre code est plus aisée car
toute la mécanique OpenCL est cachée à l’utilisateur de cette classe.



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 compatible
OpenCL, mais aussi un framework, c’est à dire un ensemble de fonctions utilisées pour envoyer des
commandes OpenCL.

L’idée est de pouvoir faire exécuter du calcul de manière parallèle en profitant du nombre important
de coeurs disponibles sur un GPU. OpenCL pousse l’abstraction plus loin en permettant de ne plus
différencier le périphérique en lui même mais de ne voir que les coeurs (ou Comput Unit en terme
OpenCL). Ainsi il est possible de parler à plusieurs GPU et même des CPU, OpenCL se démocratisant
même aux processeurs ARM.

Lorsqu’on veut exécuter du code OpenCL, il est nécessaire dans un premier temps d’interroger la
machine pour connaître les différents périphériques compatibles. Il faut donc récupérer les platforms 1 ,
1. pilote OpenCL



en 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 qui
sont 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 ainsi
qu’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ême
work-group peuvent se partager des données, données qui seront stockées localement au Comput
Unit, donc plus rapides. Néanmoins un Comput Unit possède une limite de taille maximale, taille qui
peut être récupérée via une requête au device adéquat. Maximiser la taille des work-groups permet
d’occuper au mieux le GPU, et l’accès aux données se fait plus rapidement. Aussi il faut garder en
tête que tous les work-items ne travaillent pas magiquement tous en même temps mais par paquets
de 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ôte
accueillera 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 ressources
OpenCL, 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 de
compréhension du code. En pratique on s’est rendu compte que le nombre de lignes pour le dialogue
de 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 kernel



1.3.2 Langage OpenCL
Le langage OpenCL est dérivé du langage C, et est exécuté sur les devices compatibles. Il faut
savoir qu’une fois un kernel terminé, toute la mémoire utilisée est flushée, donc il n’est plus possible
d’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 platforms
et 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 sur
le GPU). En fait il est même possible d’utiliser plusieurs devices, mais avec la contrainte de temps
imposé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 travailler
sur 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 signature
du kernel, avec CLManager::setKernelArg().

Enfin on lance l’exécution du kernel avec l’appel à CLManager::executeKernel() en lui spécifiant
le 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 le
résultat depuis la mémoire du GPU vers la mémoire RAM de l’ordinateur, dans la variable que l’on
aura instanciée auparavant.
4. c’est le nom qu’on donne à une fonction qui tournera 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 donc
lors de l’appel à clm.executeKernel() que je ne vais utiliser que 10 work-items. Aussi la méthode
setKernelArg() 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 sortie
Le 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 la
machine, 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 chemin
d’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 dur
dans 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 un
point-virgule



1.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êts
Dans 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 le
plus de temps. Dans un premier temps nous avions utilisé l’implémentation de Mersenne Twister
donnée par la librairie Boost 6 , et qui nous a permis de nous concentrer sur le tirage des trajectoires
sur GPU.

Nous nous sommes rendus compte que l’algorithme de Mersenne Twister, même s’il était très rapide
et bénéficiait d’une très grand période (219937 − 1), prenait beaucoup de place en mémoire, sachant que
si chaque work-item devait posséder son propre générateur, il nous faudrait sur le GPU une mémoire
de 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 le
générateur n’occupe que 4 octets, pour une période de 232 . Si on est toujours limités en nombre de
work-items, il est néanmoins possible de calculer la VaR sur un horizon très lointain, car le même
générateur est utilisé jusqu’à l’horizon. Un article de l’auteur 9 de l’implémentation permet de vérifier
la solidité de son générateur, et nous avons nous même vérifié que les valeurs aléatoires générées puis
transformées en gaussiennes étaient cohérentes, voir la figure 1.2. On voit que le générateur est de
bonne 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 des
trajectoires 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.html



Figure 1.2 – Histogramme de 1966080 tirages gaussiens

Figure 1.3 – Temps cumulé suivant l’optimisation



Dans la deuxième barre, nous avons proﬁté du fait que la mémoire dite globale dans la RAM du
GPU 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 du
GPU, 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 workgroup
Pour 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.

Enﬁn pour la dernière barre nous avons réunit les 2 optimisations précédentes. L’optimisation la
plus 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 nous
avons 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 : 1024
Nous nous sommes néanmoins limité à l’utilisation d’un seul des GPU sur la Tesla C2050, mais OpenCL
permet l’utilisation de plusieurs GPU en même temps.



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 CPU
Qui 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éatoires
sur le GPU.

Ce qu’on qualifie de temps autre n’est que le reste du temps où le programme fait l’instanciation
des 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 qui
lui est resté sur CPU. En passant le tri sur GPU (dans l’état de l’art c’est un problème déjà résolu
et des solutions bien optimisées existent déjà). Malheureusement nous n’avons pas eu le temps d’aller
aussi 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 ? Il
faut garder à l’esprit que la taille limitée de la RAM côté GPU impacte grandement le nombre de
tirages, sur la figure 1.6 on voit néanmoins le temps pris par, en bleu le prototype optimisé (RNG sur
CPU), et en rouge la version finale que nous avons codé (RNG sur GPU).
10. Random Number Generation



Figure 1.5 – Répartition du temps avec la RNG sur GPU

Figure 1.6 – Comparatif des 2 versions



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 de
notre générateur). La place utilisée en mémoire n’est pas proportionnelle à l’horizon.



Partie 2
Conclusion

2.1 Travail effectué
Au cours de ce projet nous avons appris sur la difficulté de la programmation gpu,GPU comment
utiliser les différentes mémoires, la répartition des workgroup, l’interaction entre le code GPU et la
structure de la carte.

Nous avons implémenté un CLManager qui permet d’abstraire tous les appels OpenCL, et rendre
ainsi 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 fait
coté CPU.

2.2 Évolutions possibles
2.2.1 Gestion plus propre des erreurs
Par manque de temps, pour debugger nous utilisons un mode de compilation dans lequel nous
envoyons 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, que
plusieurs types d’actifs devraient implémenter, par exemple une Action serait un actif particulier. Les
implé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 comportement
de celui ci par exemple en prenant directement le portefeuille en paramètre, et selon la nature de
l’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 pouvoir
spé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 2
devices, théoriquement nous aurions pu calculer 2 fois plus vite.
1. http://www-sop.inria.fr/dream/Cluster/OverView



2.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 nous
pouvons générer 2 fois moins de variables aléatoires, ce qui représente un grand gain de temps. Une
autre utilisation aurait été si notre générateur de variables aléatoires avait une faible cyclicité, mais
ce 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 ne
le sont pas.
La matrice de corrélation est par déﬁnition symétrique. Nous pouvons l’exprimer dans une base de
vecteurs propres. La librairie Boost possède des fonctions permettant de faire cette transformation.

2.3 Gestion de projet
2.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 avoir
pu bénéﬁcier 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_GPUs



Annexe

Voici les résultats des benchmarks réalisés sur NEF :


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,82

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,89

Pierre 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

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

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

Calcul1 Calcul2
Tri CPU Tri CPU

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,46

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,64

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

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

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


Calcul1 Calcul2
Tri CPU Tri CPU

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,50

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,13

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

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


Calcul de VaR par Monte-Carlo sur GPU

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Calcul de VaR par Monte-Carlo sur GPU

Ähnlich wie Calcul de VaR par Monte-Carlo sur GPU (20)

Calcul de VaR par Monte-Carlo sur GPU