Techniques de réduction de la variance
3.1.2 Le niveau zéro de la réduction de la variance : améliorer son code !
Les techniques de réduction de la variance qui vont être présentées dans ce chapitre fonctionnent au niveaualgorithmique : pour améliorer l’efficacité, on change fondamen-talement lanature du calcul effectué. Mais la première façon d’améliorer l’efficacité est d’abord d’optimiser son code de calcul ! En effet, pour faire calculer la même chose à votre ordinateur, l’ordre ou l’organisation des calculs peut lui demander beaucoup plus d’efforts...
Donc, utiliser des techniques de réduction de la variance, c’est très bien, mais si on ne conçoit pas bien son code, on ruine bêtement ses efforts ! Un code mal conçu peut faire perdre un facteur 2 voire 10 dans la vitesse d’exécution, et même, s’il est très mal conçu, rendre le programme totalement inopérant en pratique. Surtout, cela n’est pas valable que pour la méthode de Monte-Carlo, mais pourtoute implémentation informatique !
Exemple 3.2. À titre d’exemple, voyons comment nous pourrions améliorer notre code du Keno. Une première remarque qui vient à l’esprit est que l’appel à la fonction gain, qui donne le gain financier obtenu à partir d’un certain score, n’est pas utilisée de façon très intelligente... En effet, à chaque fois que nous avons à calculer un gain, nous allons refaire toute la boucle de calcul afférente au calcul de ce gain, alors qu’il est bien évident que nous pourrions calculer une fois pour toutes les différentes valeurs de gains associées aux différents scores (qui ne sont qu’en nombre fini et petit), et nous contenter de lire ensuite ces résultats stockés dans un tableau ! On obtient ainsi le programme suivant (voir la fonction calcul_gains.m en annexe :
% La fonction "keno_v2" fait le même travail que "keno_IC", mais avec un
% code amélioré au niveau du calcul des gains, qu'on pré-réalise avant la
% boucle.
function keno_v2 () Nsim = 1000000;
Ncoch = 16;
total = 0;
total_carres = 0;
% "tableau_gains(s + 1)" sera la valeur du gain pour un score de s. On le
% calcule une fois pour toutes à l'aide de la fonction auxiliaire
% "calcul_gains".
tableau_gains = calcul_gains ();
for i = 1 : Nsim
carton = 1 : Ncoch;
% "legain" est le gain obtenu par le joueur. Comme on va l'utiliser
% deux fois, on doit le stocker dans une variable d'abord.
legain = tableau_gains(score (carton, tirage ()) + 1);
total = total + legain;
total_carres = total_carres + legain * legain;
endmoyenne = total / Nsim;
variance_gain = total_carres / Nsim - moyenne * moyenne;
ect_estimtr = sqrt (variance_gain / Nsim);
c0 = sqrt (2) * erfinv (-.90);
c1 = sqrt (2) * erfinv (+.998);
fprintf ('Avec un risque de 1 ‰ pour la sous-estimation, ') fprintf ('resp. de 5 %% pour la surestimation,\n');
fprintf ('l''espérance de gain du Keno se situe dans l''intervalle ');
fprintf ('[%f, %f] €.\n', moyenne + c0 *ect_estimtr, ...
moyenne + c1 * ect_estimtr);
return end
Sur ma machine, l’exécution du programme passe d’environ 22,4 secondes à 16,6 secondes seulement. Bien entendu, le résultat est exactement le même (sous réserve d’avoir pris la même graine pour le générateur pseudo-aléatoire), vu que les calculs relatifs à la simulation sont identiques.
Mais on peut faire encore mieux ! Remarquons en effet que nous simulons l’ensemble des numéros tirés du carton, alors que tout ce qui nous intéresse est de savoir combien
de numéros sont tirés parmi ceux de ‘1’ à ‘16’ (rappelons en effet qu’on peut joueur toujours la même grille, en cochant ‘1’ pour le numéro ‘1’, etc.). On peut choisir de regarder successivement les numéros de ‘1’ à ‘16’ et voir, conditionnellement à ceux qui ont été tirés ou non parmi les précédents, s’ils vont être tirée ou non. Cela conduit à une fonctiontirage_reduitqui renvoie un 16-vecteur valant ‘true’ en sa case iquand le numéro coché pour i a été tiré et ‘false’ sinon. Le programme obtenu étant alors :
% La fonction "keno_v3" fait le même travail que "keno_v2", mais avec un
% code encore amélioré, où on ne simule les numéros tirés que parmi ceux
% qui sont cochés.
function keno_v3 () Nsim = 1000000;
Ncoch = 16;
total = 0;
total_carres = 0;
tableau_gains = calcul_gains ();
for i = 1 : Nsim
% La fonction "tirage_reduit" donne quels numéros ont été tirés parmi
% ceux qu'on a cochés; on stocke son résultat dans "letirage".
letirage = tirage_reduit ();
% "lescore" est le score obtenu, qui se déduit facilement de letirage.
lescore = sum ((1:Ncoch) .* letirage);
legain = tableau_gains(lescore + 1);
total = total + legain;
total_carres = total_carres + legain * legain;
endmoyenne = total / Nsim;
variance_gain = total_carres / Nsim - moyenne * moyenne;
ect_estimtr = sqrt (variance_gain / Nsim);
c0 = sqrt (2) * erfinv (-.90);
c1 = sqrt (2) * erfinv (+.998);
fprintf ('Avec un risque de 1 ‰ pour la sous-estimation, ') fprintf ('resp. de 5 %% pour la surestimation,\n');
fprintf ('l''espérance de gain du Keno se situe dans l''intervalle ');
fprintf ('[%f, %f] €.\n', moyenne + c0 *ect_estimtr, ...
moyenne + c1 * ect_estimtr);
return end
Le temps de calcul descend alors à 12,8 secondes... Noter que cette fois, les résultats obtenus ne sont pas strictement identiques, même en prenant une graine peudo-aléatoire identique, car la simulation utilise lestirages aléatoires de façon différente ; par contre, la précision du résultat est bien la même (l’intervalle de confiance a la même largeur), dans la mesure où les opérations effectuées sont identiques en substance (on simule des tirages et on regarde le gain moyen).
On pourrait encore faire quelques améliorations à la marge, mais je voudrais en montrer une dernière plus radicale : changer de langage de programmation ! Le langage de Matlab que j’ai utilisé jusque-là est en effet un langage de haut niveau (je ne contrôle
donc pas très bien les claculs effectivement faits par le processeur), interprété (le logiciel ne découvre les lignes du programme qu’au moment de l’exécution, et ne peut donc pas préparer d’optimisation en fonction de la structure globale du programme), et très faiblement type (à chaque fois que Matlab rencontre un objet, il doit savoir s’il va le traiter comme une matrice, un entier, un réel, un complexe, ...). Tout cela perd beaucoup de temps à l’exécution. Un langage de plus bas niveau, compilé, au langage moins ambigu devrait donc être susceptible de faire beaucoup mieux... Essayons donc avec le roi des langages de bas niveau, à savoir le langage C... Le temps de calcul est alors de... 0,5 secondes ! Autant dire que, si notre préoccupation était vraiment la rapidité, on aurait mieux fait de tout de suite commencer par là...
Remarque 3.3. Certaines optimisation de code peuvent avoir un résultat pratiquement nul, parce qu’on a amélioré une partie du code qui ne prenait qu’une toute partie du temps total. Il faut un peu d’expérience de la programmation pour savoir quelles sont les opérations les plus lourdes pour le processeur, et à quels endroits un code non optimisé risque donc de nous couter vraiment cher... Bien sûr, le bon sens aide aussi : il est ainsi évident qu’il y a énormément plus d’intérêt à optimiser une opération répétée un très grand nombre de fois à l’intérieur d’une boucle, plutôt qu’une opération effectuée une fois pour toutes au début du programme !
Remarque 3.4. Certains logiciels ou certains langages ont leurs spécificités qu’il est bon de connaitre pour accélérer l’exécution. Ainsi, sous Matlab, les opérations portant sur les matrices sont pré-compilées pour être particulièrement rapides à l’exécution, de sorte qu’il est en général beaucoup plus efficace d’utiliser une fonction Matlab toute faite plutôt que de passer par une boucle pour faire le même calcul case par case... Ces considérations sont surtout intéressantes lorsqu’on est spécialisé dans un langage donné.
Dans la mesure où l’objectif de ce cours est de présenter les méthodes de Monte-Carlo de manière générale, sans mettre en avant un langage particulier, nous n’exploiterons dans la suite que les optimisations de code reposant sur des considérations informatiques générales, sans faire attention aux spécificités propres à Matlab.