La Simulation distribue et parallle

1
La Simulation distribuée et parallèle
2
Objectif

• Passer du modèle à une implémentation
• Utiliser un maximum la puissance des ordinateurs
• Pourquoi utiliser quun ordinateur pour faire une
  simulation ?
• Comment faire travailler plusieurs ordinateurs
  entre eux ?
• Quels sont les possibilités ?
• Quels sont les problèmes ?

3
Solutions architecturales possibles

• Un processeur
• Limité par la mémoire et la puissance de calcul
• Multiprocesseurs
• Utilisation de mémoires partagées
• Mais ordinateurs coûteux
• Interconnexion dordinateurs, clusters
• Possibilité de recourir à une mémoire partagée
• Solution peu onéreuse

4
Quels méthodes de distribution adopter ?

• Parallélisation automatique
• Analyse automatique du code
• Accélération obtenue reste faible
• Distribution des expériences
• Code séquentiel identique sur tous les
  processeurs
• Paramètres dentrées uniquement qui changent
• Distribution des fonctions du simulateur

5
Quels méthodes de distribution adopter ?

• Distribution des événements
• Utilisation dun échéancier globale
• En général, utilisation dune mémoire partagée
• Intéressant quand le volume dinformations
  échangées est important
• Distribution des éléments du modèle
• Utilisation du parallélisme du modèle
• Échange de messages datés entre les processus
• Obligation dutiliser une synchronisation des
  processus

6
Exécution distribuée la causalité

• Toute conséquence possède une cause
• Simulation séquentielle aucun problème
• Simulation distribuée ?
• 2 actions A et B
• A sur processeur P et B sur le processeur Q
• Si B calculé avant A ????
• Causalité impose ordre partiel entre les
  transitions
• Lamport Lam78 a défini une méthode pour
  respecter cette causalité

7
Le problème de la causalité ?

• Généralement, problème rencontré lors de la
  distribution des événements du modèle
• Avec les autres types de distributions
• Utilisation dun échéancier globale
• Pourquoi distribuer les éléments du modèles
• Pas de mémoire partagée
• Optimisation du parallélisme du modèle

8
Le temps ?

• Temps physique
• du 23 Janvier 2003 9h au 23 Janvier 2003 12h
• Temps simulé
• Représentation du temps physique 9.0-12.0
• Temps Wallclock
• Temps dexécution de la simulation 900 à 915

9
Évolution synchrone

• Temps simulé horloge globale
• Toutes les horloges logiques (horloge de chaque
  processeur) avancent en même temps
• Existence dun décalage dû à la propagation
• Assurance que lors du passage au temps t, tous
  les processeurs ont fini t-1
• Problème inactivité de certains processeurs

10
Évolution asynchrone

• Chaque processeur avance à sa propre vitesse
• Problème ?

11
Exemple de simulation

• Le trafic aérien et les aéroports

12
Exemple dun aéroport

• 3 événements par avion
• Approche (avion sous contrôle de la tour)
• Atterrissage
• Décollage
• 3 états
• En_lair nombre davion en lair
• Au_sol nombre davion au sol
• Piste_libre booléen
• 2 constantes temporelles
• A temps nécessaire pour atterrir
• D temps nécessaire pour pouvoir partir

13
Event-Oriented Simulation Example

• Now date locale de simulation
• InTheAir nombre davion en lair (en approche
  ou en train dattérir)
• OnTheGround nombre davions au sol
• RunwayFree Booléen, vrai si la piste est libre

• Arrival Event
• InTheAir InTheAir1
• If (RunwayFree)
• RunwayFreeFALSE
• Schedule Landed event _at_ Now R

Landed Event InTheAir InTheAir-1
OnTheGround OnTheGround1 Schedule Departure
event _at_ Now G If (InTheAirgt0) Schedule Landed
event _at_ Now R Else RunwayFree TRUE
Departure Event OnTheGround OnTheGround - 1
14
En_lair
0
Au_sol
0
Piste_libre
Vrai
0
1
2
3
4
5
6
7
8
9
10
11
Temps de simulation
A (Temps pour atterrir) 3 D (Temps pour partir)
4
15
Le trafic de plusieurs aéroports ?

• Intéraction entre eux
• Obligation de séchanger des messages
• Exemple Avion décolle de Paris, il sera en
  approche à Genève 1h plus tard
• Dans la simulation programmer cette approche
  sur laéroport de Genève
• Simulation sur un processeur ou avec mémoire
  partagée aucun problème mais limite des
  ressources
• Et sur plusieurs ordinateurs ?

16
Approche de lexécution distribuée

• Simulation dun modèle par ordinateur
• Communication par message
• Aucune mémoire partagée

17
Event-Oriented Simulation Example

• Now date locale de simulation
• InTheAir nombre davion en lair (en approche
  ou en train dattérir)
• OnTheGround nombre davions au sol
• RunwayFree Booléen, vrai si la piste est libre

• Arrival Event
• InTheAir InTheAir1
• If (RunwayFree)
• RunwayFreeFALSE
• Schedule Landed event (local) _at_ Now R

Landed Event InTheAir InTheAir-1
OnTheGround OnTheGround1 Schedule Departure
event (local) _at_ Now G If (InTheAirgt0) Schedule
Landed event (local) _at_ Now R Else RunwayFree
TRUE
Departure Event (D delay to reach another
airport) OnTheGround OnTheGround -
1 Schedule Arrival Event (remote) _at_ (NowD) _at_
another airport
18
La causalité ?
Départ dun avion à t 8 GEN-PAR 10 Calcul de
larrivée à PAR t1018 Envoie du message à PAR
une arrivée prévue à t18
GEN
Sur PAR t30 ???
PAR
NIC
19
Les règles dor

• Maintenir la causalité temps réel (ou physique)
  est unique sur un processeur, le temps simulé
  est unique
• Mais sur plusieurs processeurs ???
• Maintenir la vivacité le temps sécoule

20
2 types de synchronisation

• Approche pessimiste (ou conservative)
• la simulation avance quand elle est sûre de
  pouvoir le faire
• Approche optimiste
• la simulation avance et détecte les violations
  de contrainte de causalité quand elles se
  produisent. Elle revient alors en arrière jusquà
  ce que la contrainte soit à nouveau satisfaite et
  la simulation repart.

21
Hypothèses

• Canaux FIFO
• Communications sûres
• Mémoire suffisante
• Tous les messages consécutifs provenant dun même
  processeur sont estampillés avec des valeurs
  croissantes

22
Approche pessimiste

• Synchronisation

23
Approche pessimiste (ou conservative)

• Approche synchrone, dirigée par le temps
• Approche asynchrone, dirigée par les événements

24
Approche synchrone

• Synchronisation forte horloge globale
• A chaque phase de calcul
• Chaque processeur exécute une action
• Attente ensuite que tout le monde ait fini
  (barrière de synchronisation)
• Quand détection de la terminaison, passage à la
  phase suivante

25
Approche synchrone

• Algorithme synchrone faible ou à fenêtre
• Objectif augmenter le nombre de processeurs
  actifs simultanément
• Incrémente alors de 1 d
• Calcul de d ?
• pré calculé par une analyse de la simulation
• Calculé dynamiquement par un algorithme de calcul
  de minimum global

26
Approche asynchrone (dirigée par les événements)

• En distribué
• un processeur na pas de vision globale (pas de
  mémoire partagée)
• Prise de décision en fonction des informations
  locales
• Mais avant toute exécution dun événement
  estampillé au temps T, le simulateur doit être
  sûr de ne pas recevoir dans le futur un message
  avec une estampille TltT

27
Approche asynchrone (dirigée par les événements)

• Solution ?
• Un processeur doit attendre ?
• Mais pendant combien de temps ?
• Quel décision prendre ?

28
Approche asynchrone Chandy/Misra et Bryant
Null Message Algorithm

• Hypothèses
• Échange de messages avec estampille (daté) entre
  chaque ordinateur
• Topologie du réseau fixe
• Les messages sont expédiés dans lordre
• Le réseau achemine correctement les messages et
  les liens de communication conservent lordre
  dexpédition (canaux FIFO)

29
Chandy/Misra/Bryant Null Message Algorithm

• WHILE (simulation nest pas fini)
• Wait Until chaque lien contient un message
• Retirer le message avec la date minimale
• Exécuter laction correspondante
• END-LOOP

Evénement de NIC
Evénement 2
9
8
2
Evénement 4
Evénement 5
5
4
Attente dun message
Problème DEADLOCK
30
Une configuration de DEADLOCK
Supposons que le délai entre les aéroports est 3
GEN (attente de PAR)
7
NIC (attente de GEN)
15
10
PAR (attente de NIC)
T5
9
8
31
Solution NULL message
Supposons que le delai entre les aéroports est 3
Calcul de la date minimale de chaque message
quun aéroport pourra recevoir
NIC envoie message NULL estampillé 538
PAR envoie message NULL estampillé 11
GEN (attente de PAR)
11
7
GEN peut traiter événement daté à 7
11
NIC (attente de GEN)
15
8
10
PAR (attente de NIC)
T5
8
9
8
32
Solution NULL message
Supposons que le delai entre les aéroports est 3
T7
NIC événement daté 8
GEN
11
NIC événement daté 9
10
NIC
10
15
11
10
PAR
T5
8
T8
T9
9
8
33
Algorithme du NULL message

• Chaque processus i exécute
• WHILE (simulation nest pas fini)
• Wait Until chaque lien contient un message
• Retirer le message avec la date minimale
• Exécuter laction correspondante
• Envoyer à tous les voisins la date minimale
  quils pourront recevoir de i.
• END-LOOP

34
Problème des approches conservatives

• Nonexploitation du parallélisme totale de la
  simulation
• Configuration statique
• Pas de création de nouveau processus au cours de
  la simulation
• Certaines simulations sont impossibles
• Si lincrément de lestampille est nulle

35
Approche optimiste

• Rappel un simulateur par processeur
• Pas de vision globale
• Optimiste on fonce dans le brouillard

36
Time Warp (Jefferson)

• Principe
• Chaque processus exécute les événements dans
  lordre
• Si un message arrive avec une date antérieure
  annulation des actions effectuées

37
Algorithme du Time Warp
4
7
15
24
28
30

• A la réception dun message du passé
• restaurer les états antérieurs
• sauvegarder tous les états
• annuler les messages envoyés et à envoyer
• utilisation danti-messages et de messages
  dannulation

38
Les anti-messages ?
12
message positif
12
anti-message
12

• Utilisée pour annuler un message
• A chaque message envoyé, il existe un
  anti-message correspondant
• Anti-message et message sont identiques, excepté
  un bit de signe
• Quand un message et son anti-message se
  rencontrent dans une file, ils se détruisent
• A lexpédition dun message, conservation dune
  copie de lanti-message correspondant

39
Valeurs à sauvegarder

• Evénements traités
• Messages envoyés et reçus
• Date émission
• Date réception
• Emetteur
• Récepteur
• Signe
• Données

40
Exemple sur un processeur A
File dentrée des messages
Date émission
Date réception
Emetteur
Récepteur
Signe
Temps Virtuel Local TVL162
Données
File de sortie des messages
Date émission
Date réception
Emetteur
Récepteur
Signe
Données
File des états sauvegardés
41
Exemple sur un processeur A
File dentrée des messages
Date émission
Date réception
Emetteur
Récepteur
Signe
Temps Virtuel Local TVL162
Données
File de sortie des messages
Date émission
Nouveau message
Date réception
Emetteur
Récepteur
Signe
Données
File des états sauvegardés
42
Exemple sur un processeur A
File dentrée des messages
Date émission
Date réception
Emetteur
Récepteur
Signe
Temps Virtuel Local TVL121
Données
File de sortie des messages
Date émission
Nouveau message
Date réception
ANTI-MESSAGES envoyés
Emetteur
Récepteur
Signe
Données
File des états sauvegardés
43
Réception danti-messages

• Si le message est dans la dentrée du
  destinataire et non traité annulation
• Sinon même procédure que pour la réception dun
  message du passé rollback

44
Problème du rollback

• Malgré les retours-arrière,
• le système évolue-t-il globalement ?
• quantité mémoire pour stoker les historiques
  sera-t-elle toujours suffisante ?
• Comment détecter la terminaison ?
• Comment gérer les entrées/sorties en tenant
  compte des retours-arrière ?

45
Solution Temps virtuel global

• Sur tous les processeurs, il existe un temps
  minimale au-dessous duquel la simulation ne
  pourra jamais revenir.
• Utilité de ce Temps Virtuel Global ?
• Libération de la mémoire occupée par les
  sauvegardes
• Valider les actions définitivement
• Détection de la terminaison ?
• File dattente vide 8
• Toutes les files dattente sont vides TVG 8
• Un algorithme de TVG par Samadi en 1985

46
Calcul du TVG ou Min globale

• Minimum de toutes les estampilles des messages
  non encore reçus et des temps locaux
• Une approximation est suffisante
• Calcul fréquent est nécessaire pour optimiser la
  mémoire
• Ce calcul ralentit lexécution

47
Optimisation du rollback

• Gafni en 1988 larrivée dun message en
  retard ne modifie pas suffisamment les calculs
  pour que les messages déjà envoyés soient faux
• Annulation paresseuse attente de leffet de la
  réception dun message en retard
• Si provoque les mêmes messages que précédemment,
  OK
• Sinon, on envoie un anti-message
• Re-évaluation paresseuse on soccupe de létat
  des processeurs en pas des messages
• Si un message en retard arrive et provoque les
  mêmes résultats que précédemment, on repart là où
  lon était

48
Avantages de ces optimisations

• Le speedup est plus élevé que le nombre de
  processeurs impliqués dans le calcul
• Exemple 2 processeurs - vitesse de la
  simulation distribuée doit être 2 fois rapide
  quen séquentielle
• Avec optimisation
• plus de 2 fois rapide avec 2 processeurs

49
Difficultés de lapproche optimiste

• Va-t-on passer plus de temps à faire des
  retours-arrière que des exécutions de la
  simulation ?
• Jefferson en 85
• Temps passé à faire des rollback temps
  dattente dans lapproche pessimiste
• Sauvegarde périodique des états du système
• Nécessité de plus de mémoire dans lapproche
  optimiste quen pessimiste
• Tolérance et correction des erreurs pouvant être
  causées par une exécution erronée et annulée par
  un rollback
• Pour linstant, laissée à la charge de
  lutilisateur
• Mise au point de la fréquence des sauvegardes des
  vecteurs détats, gestion de la mémoire,

50
Performances

• IL NEXISTE PAS DE SOLUTION UNIVERSELLE
• Approche pessimiste
• File dattente sur 5 processeurs aucun gain
• 292 voitures sur 292 routes,33 Transputers 19
• Approche optimiste
• Comportement des fourmis sur 32 proc. 13
• Simulation logique
• sur 32 proc. 25
• sur 8 proc. 2
• Simulation de réseaux dinterconnexion plus
  lent que lapproche pessimiste

51
Bibliographie

• Lamport 78 Time, clocks and the ordering of
  events in a distributed system Communication of
  the ACM, Vol 21,7
• Jefferson 85 Virtual Time ACM Transactions on
  Programming Languages and Systems, Vol 7,3
• Samadi 85 Distributed simulation, alogirthms
  and performance analysis Thèse de doctorat,
  University of California, Los Angeles, USA
• Misra 86 Distributed discrete-event simulation
  Computing Survey, Vol 18,1
• Gafni 88 Rollback mechanisms for optimistic
  distributed simulation systems Proceedings of
  the SCS Multiconference on Distributed Simulation