R

1
Réunion ANR - GCPMF15/01/2008
Distribution large échelle dun algorithme
financier de contrôle stochastique

• Xavier WARIN (EDF RD - OSIRIS)?
• Stéphane VIALLE (SUPELEC - IMS)?
• Constantinos MAKASSIKIS (SUPELEC - IMS, LORIA -
  AlGorille)?

2
Introduction
3
Introduction

• Objectif Présentation de la distribution dune
  application financière de valorisation dactifs
  de stockage de gaz réalisée avec EDF.
• Application utilisée dans des projets
  dinvestissements
• calcule le prix de location optimal dun actif de
  stockage
• utilise des modèles de prix complexes gourmands
  en ressources et nécessitant une calibration.

4
Introduction

• Solution distribution/parallélisation.
• pour accélerer et passer à léchelle
• Par rapport applications de type Bag of Tasks,
  mise en jeu
• de calculs intensifs
• ET
• des communications fréquentes redistribution
  régulière de données et de résultats
• ? nécessite une optimisation des échanges de
  données

5
Contexte financier
6
Contexte financier

• Actif de stockage de gaz
• Cavité où est stocké le gaz
• Matériel (pompes, ) pour injecter/sous-tirer
• Contraintes de fonctionnement diverses

• Fluctuations des prix du gaz
• Cause modification de la demande (hiver, été)
• Conséquence possibilité darbitrer pour
  profiter de la dynamique des prix ? valorisation

7
Contexte financier

• La valorisation fait appel à
• des algorithmes de contrôle stochastique
• des modèles de prix variés

Dans notre cas le propriétaire veut déterminer à
quel prix il va louer une partie de son actif.
Pour ce faire, il se fonde sur les résultats
potentiels de différentes stratégies de gestion
quil aurait pu appliquer sur la portion louée
sil ne lavait pas louée.
8
Distribution delalgorithme
9
Algorithme séquentiel
Futur
Aujourdhui
Prix de location à t0
tn
t0
tn-1
Calculs Stochastiques
Hypothèses de terminaison
10
Algorithme séquentiel

• Pour chaque pas de temps (de tn-1 à t0)
• Pour chaque niveau de stock admissible
• Calcul complexe pour déterminer la meilleure
  décision à prendre au temps ti avec un niveau de
  stock si
•  Injecter, ne rien faire ou soutirer ? 

11
Difficultés de parallélisation

• Pour chaque pas de temps (de tn-1 à t0)
• Pour chaque niveau de stock admissible
• Calcul complexe pour déterminer la meilleure
  décision à prendre au temps ti avec un niveau de
  stock si
•  Injecter, ne rien faire ou soutirer ? 
• La parallélisation au niveau de la boucle la plus
  externe est impossible à cause des dépendances de
  lalgorithme.
• Le niveau le plus intéressant se trouve au niveau
  de la boucle sur les niveaux de stock.

12
Structures de données

• A chaque pas de temps utilisation de deux
  tableaux OldRes et NewRes.
• OldRes contient les résultats du pas de temps
  précédent.
• NewRes pour mémoriser les résultats du pas de
  temps courant.
• Problème à chaque pas de temps le travail
  seffectue sur une zone contiguë mais à bornes
  variables.

A ti
Niveaux de stock
OldRes
Aléas de prix
Résultats à ti1
NewRes
Résultats à ti
13
Schéma de parallélisation
ti1

• En séquentiel, on peut se placer dans le cas
  ci-contre.

NewRes
ti
OldRes

• En parallèle

NewRes

• Solution 1
• réplication des tableaux.
• broadcast.

• Solution 2
• optimisation de la taille des tableaux.
• redistribution de ce qui est nécessaire.

14
Schéma de parallélisation
ti1
Sur P1
Res à ti1
ti
1) Déterminer la nouvelle distribution des
calculs à ti
Res à ti
2) Déterminer les données requises à ti par
P1
3) Déterminer les données à envoyer par P1
C
D
B
A
4) Allouer structures de données de taille
optimale
5) Effectuer les communications selon le plan
de routage (MPI)
6) Calculer Res à ti
15
Implémentations
16
Implémentations

• Deux implémentations
• (1) en Python avec MPI et C
• Priorité au confort de lutilisateur
  (paramétrage, visualisation )
• Interfaçage Python/C
• Interfaçage Python/MPI
• (2) en C avec MPI
• Priorité à la performance
• 3 versions MPI_Bsend(), MPI_Ibsend() et
  MPI_Issend()

17
Etude des performances
18
Evaluation des performances

• Utilisation de la 2ième implémentation
  (MPI_Issend())
• Expérimentations sur 3 architectures distribuées
  
• Deux clusters de PCs (SUPELEC et
  GRID5000/Sophia).
• Le supercalculateur Blue Gene/L de EDF RD.
• Avec 3 modèles de prix du gaz

19
Performances avec  G 
54min
14min
8
15s
64
1024
20
Performances avec  NIG 
6h40
3min
1024
128
21
Performances avec  G-2f 

• Besoin de beaucoup de mémoire
• 11 Go pour lexécution séquentielle
• 10 CPUs avec 2 Go en parallèle
• Exécution rendue possible par notre distribution.
• Scale jusquà 1024 processeurs.
• Limitation
• Impossible de calculer un speedup rigoureux.
• Donc étude dextensibilité (seulement).

22
Performances avec  G-2f 
14h
16
2h20
128
46min
1024
Blue Gene wins !
23
Etude dextensibilité avec  G-2f 
Maintient du temps dexécution à 12 000 secondes
24
Conclusion
25
Conclusion Perspectives

• Algorithme itératif de contrôle stochastique
  dynamique avec distribution à chaque pas de temps
  des calculs et des données.
• Résultats issus des expérimentations témoignent
  de lefficacité de notre distribution sur
  clusters de PCs (128 CPUs) et supercalculateur
  (1024 CPUs)
• Accéleration de lexécution sur trois modèles de
  prix aux caractéristiques variées
• 2 modèles de référence et 1 nouveau modèle

26
Version n-dimensionnelle distribuée

• Depuis octobre 2007 (EDF Supélec)
• Distribution dune version de  contrôle
  stochastique multistocks 
• Distribution dhypercubes de données et de
  calculs
• Application à la gestion dynamique du
  portefeuille EDF
• maximisation de l'espérance des gains liés à
  la gestion de stocks d'eau et de stocks de
  produits à terme sous respect de contrainte de
  satisfaction de la demande.
• ? WP6 Contrôle stochastique en grande
  dimension.
• Vers une généralisation à N dimensions de la
  distribution dun algorithme de contrôle
  stochastique

27
Version n-dimensionnelle distribuée
Une application plus complexe en deux parties

• A chaque pas de temps
• Intersections et répartitions dhypercubes
• Provisioning dynamique des processeurs
• Sauvegardes de résultats intermédiaires
• Simulations de Monte Carlo à partir des résultats
  intermédiaires embarrassingly parallel

28
Version n-dimensionnelle distribuée

• Un cas test sur 7 stocks dure
• 18 h sur les 32 PCs du cluster de SUPELEC
• 5h30 sur 1024 nœuds de Blue Gene.
• Les temps de calcul restent longs ... besoin de
  tolérance aux pannes.

29
Questions ?
30
(No Transcript)
31
(No Transcript)
32
Environnements dexpérimentation
Cluster SUPELEC 32 nœuds monoprocesseur Processeur
Pentium 4 à 3.0 GHz Mémoire vive 2 GB Réseau
dinterconnexion Gigabit Ethernet
Cluster Grid5000 (Sophia, Azur)? 72 nœuds
biprocesseurs Processeur Opteron 246 à 2.0 GHz
Mémoire vive 2 GB (partagés)? Réseau
dinterconnexion Gigabit Ethernet
33
Environnements dexpérimentation
Blue Gene/L de EDF RD 4096 nœuds
biprocesseurs Processeur PowerPC à 700 MHz
(faible consommation)? Mémoire vive 1 GB
(partagé)? Réseau dinterconnexion Gigabit
Ethernet
34
Quelle machine pour quel modèle ?

• Les performances permettent de proposer une
  architecture dexécution adaptée selon le modèle
  envisagé