1 OpenMASK distribué, 30 mai 2002 Les noyaux d’exécution distribuée d’OpenMASK David Margery 30 mai 2002.

Présentation au sujet: "1 OpenMASK distribué, 30 mai 2002 Les noyaux d’exécution distribuée d’OpenMASK David Margery 30 mai 2002."— Transcription de la présentation:

1 1 OpenMASK distribué, 30 mai 2002 Les noyaux d’exécution distribuée d’OpenMASK David Margery David.Margery@irisa.fr/ dmargery@iwi.fr 30 mai 2002

2 2 OpenMASK distribué, 30 mai 2002 Plan de l’exposé è Présentation d’OpenMASK ŸContexte de recherche ŸSurvol des capacités ŸChoix fondamentaux è Distribution et parallélisme ŸPrincipes –La cohérence relâchée contrainte ŸMise en oeuvre ŸRésultats è Perspectives

3 3 OpenMASK distribué, 30 mai 2002 Les origines : GASP è 93-94 : ŸUne volonté de capitaliser les travaux du projet Siames ŸUne volonté de bénéficier de la puissance de calcul d’une exécution distribuée è 98 : ŸPublication de [donikian98] ŸDémarrage de ma thèse ŸUne seule application réelle : mustang (simulation d’environnements urbain)

4 4 OpenMASK distribué, 30 mai 2002 Les objectifs è Une abstraction complète ŸCouvrant l’ensemble du champ applicatif de l’animation, de la simulation et de la réalité virtuelle –Supportant en natif l’ensemble des algorithmes d’animation et de simulation –Permettant d’espérer une exécution parallèle et distribuée qui soit performante è Des noyaux d’exécution implémentant cette abstraction ŸAdaptés au contexte matériel ŸAdaptés à l’application visée ŸPerformants

5 5 OpenMASK distribué, 30 mai 2002 L’état actuel : OpenMASK3.0 è Distribué sous licence QPL Ÿwww.openmask.orgwww.openmask.org è Utilisé dans des contextes applicatifs variés ŸSimulation comportementale (multi-agents) ŸRéalité virtuelle distribuée (projet Perf-RV) ŸSimulation mécanique (multi-corps) et retour haptique è Encore des évolutions prévues ŸRecherche sur les stratégies de distribution ŸMeilleure coopération animation/simulation ŸMeilleur support pour les données atomiques de grande taille

6 6 OpenMASK distribué, 30 mai 2002 Survol des capacités d’OpenMASK è OpenMASK, noyau d’exécution est ŸUn logiciel de création, de destruction, de recherche d’objets de simulation ŸUn bus logiciel pour faire communiquer ces objets de simulation –Établissement de flots de données –Signaux diffusés dans l’environnement –Évènements échangés entre les objets ŸUn moteur d’exécution gérant l’écoulement du temps et permettant l’activation des objets de simulation selon leur contraintes

7 7 OpenMASK distribué, 30 mai 2002 Points fondamentaux è Un objet de simulation est un objet qui partage ses données et non ses méthodes ŸC’est la base pour le parallélisme –Un seul flot d’exécution dans chaque objet ŸC’est la base pour une distribution performante –On rend les données partagées disponibles sur tous les nœuds qui en ont besoin ŸC’est La Contrainte lorsqu’on programme avec OpenMASK è Ces données partagées ont toujours un sens ŸLeur valeur est continue dans le temps ŸOn peut donc faire des extrapolations et des interpolations

8 8 OpenMASK distribué, 30 mai 2002 Plan de l’exposé è Présentation d’OpenMASK ŸContexte de recherche ŸSurvol des capacités ŸChoix fondamentaux è Distribution et parallélisme ŸPrincipes –La cohérence relâchée contrainte ŸMise en oeuvre ŸRésultats è Perspectives

9 9 OpenMASK distribué, 30 mai 2002 Principes è Il n’y a a priori pas d’ordre d’activation entre les objets de simulation ŸOn pourrait donc avoir un processus (ou thread) par objet de simulation è La communication entre les objets est effectuée grâce au bus logiciel fournit par le noyau d’exécution ŸOn peut donc réaliser des mises en œuvres distribuées de ce bus logiciel ŸLes opérations de communication sont atomiques

10 10 OpenMASK distribué, 30 mai 2002 On évite les problèmes è Intégrité des données ŸIl n’y a pas de méthodes publiques : –Il n’y a qu’un flot d’exécution dans chaque objet –Le problème d’intégrité des données d’un objet se limite au problème de l’intégrité des données publiques d’un objet u Ces données sont gérées par le bus logiciel du noyau d’exécution. Elle peuvent être protégées par des verrous si nécessaire è Interblocage ŸL’utilisation des verrous est limité à des opérations atomiques –Au sens de l’interface : elles renvoient toujours immédiatement un résultat ŸIl n’y a pas d’opération qui nécessite d’attendre un résultat produit par un autre objet/processus

11 11 OpenMASK distribué, 30 mai 2002 Recherche de la performance è L’application a de bonnes propriétés ŸPourvu qu’on puisse mettre en œuvre un bus logiciel pour la communication qui soit performant : ce sera le cœur de cette présentation è Originalité de l’approche (en réalité virtuelle) ŸInstrumentation plutôt que sémantique applicative (NPSNET, MASSIVE) ŸIndépendante du matériel (DEVA) ŸNon basée sur Corba ou Java/RMI (problème de l’attente d’un résultat d’une requête transmise à travers le réseau)

12 12 OpenMASK distribué, 30 mai 2002 Le bus logiciel pour la communication. è Transmission d’événements et de messages ŸNe pose pas de problèmes particulier è La mise à disposition des données publiques d’un objet de simulation ŸSe fait dans les sorties d’un objet ŸUne sortie est un objet générique, dans lequel les objets publient les nouvelles valeurs de leurs attributs publics ŸPour éviter la contention, c’est une file de valeur de taille  2 –On publie une valeur dans un élément de file pendant que les autres objets peuvent lire les anciennes valeurs (éventuellement pour en extrapoler une valeur approchée de la prochaine valeur) ŸLa sortie est instanciée par le noyau d’exécution

13 13 OpenMASK distribué, 30 mai 2002 Autres éléments de distribution è On synchronise simultanément toutes les sorties d’un objet (pour des raisons de cohérence) ŸUne copie de référence (le référentiel) ŸDes copies sur les nœuds ayant besoin des valeurs des sorties de l’objet è Les objets de simulation sont affectés statiquement sur les nœuds de calcul ŸRound-robin ŸDescription fichier de la distribution

14 14 OpenMASK distribué, 30 mai 2002 Bilan è Écrire un noyau d’exécution distribué c’est ŸÉcrire un type de sortie qui peut être synchronisée à travers le réseau ŸÉcrire un algorithme qui choisi la stratégie de synchronisation è Il faudrait aussi ŸÉcrire un algorithme d’équilibrage de charge –Statique (c’est possible) –Dynamique (ce serait souhaitable)

15 15 OpenMASK distribué, 30 mai 2002 Stratégie de synchronisation utilisée (1) è On souhaite maintenir une certaine cohérence ŸRelâchée –On ne veut pas payer le prix d’un algorithme de maintient d’une cohérence séquentielle –On peut ne pas le payer, car l’extrapolation u Se justifie dans notre contexte u Donne des résultats satisfaisants parce qu’elle se fait pour des dates très peu en avance sur les dates des échantillons connus ŸContrainte –On veut maîtriser l’erreur/le décalage visuel

16 16 OpenMASK distribué, 30 mai 2002 Stratégie de synchronisation utilisée (2) è Principe ŸOn veut paralléliser le calcul et la synchronisation de valeurs –Le degré de parallélisme entre les deux activités est réglé par un paramètre de l’algorithme : la latence –Ce qui donne, avec t et latence exprimé en temps simulé –On calcule le pas de simulation de date t que si les valeurs du pas de simulation t-latence-latenceMin sont arrivées sur le nœud courant ŸEn théorie, si latenceMin = 0 pour une mise en œuvre donnée, latence = 0 revient à mettre en œuvre une cohérence séquentielle. Pour les autres valeurs de latence, on a de la cohérence relâchée contrainte ŸEn pratique, les mises en œuvres ont latenceMin fixée à un pas de simulation

17 17 OpenMASK distribué, 30 mai 2002 Plan de l’exposé è Présentation d’OpenMASK ŸContexte de recherche ŸSurvol des capacités ŸChoix fondamentaux è Distribution et parallélisme ŸPrincipes –La cohérence relâchée contrainte ŸMise en oeuvre ŸRésultats è Perspectives

18 18 OpenMASK distribué, 30 mai 2002 Mise en œuvre avec PVM è Pour lire des valeurs de sorties, il faut brancher une entrée sur la sortie d’un objet ŸLors de cette opération, un miroir de l’objet propriétaire de la sortie est créé, et son référentiel est prévenu pour qu’il y ait mise à jour des valeurs du miroir –Actuellement, cette opération prend un pas de temps è La synchronisation des valeurs a lieu entre les référentiels et leur miroir

19 19 OpenMASK distribué, 30 mai 2002 Mise en œuvre avec PVM (2) è Avec utilisation de cohérence relâchée ŸRecevoirAuMoins garantit –La synchronisation des valeurs –Une ampleur maximale du relâchement de la cohérence ŸEnvoyerAuxAbonnés –Insère dans un message de synchronisation l’éventuelle nouvelle valeur produite au pas de calcul précédant Infinite loop { Calculer (i) EnvoyerAuxAbonnés (i) recevoirAuMoins (i-latence) } Infinite loop { Calculer (i) EnvoyerAuxAbonnés (i) RecevoirAuMoins (i-latence) } i -1

20 20 OpenMASK distribué, 30 mai 2002 Performance sous PVM è Accélération è Pourquoi ? ŸCoût de création puis d’interprétation des messages échangés (important et constant) –Mise en œuvre particulièrement mauvaise

21 21 OpenMASK distribué, 30 mai 2002 Mise en œuvre sur mémoire virtuelle partagée (DSM) è Motivations : ŸPas de création et d’interprétation de messages ŸGarantie d’un transfert des informations de mise à jour au besoin (on peut avoir latenceMin = 0) è Problèmes : ŸPlacement des données partagées (sorties, signaux et événements) ŸMise en œuvre de la cohérence relâchée –Au niveau de la DSM –Permettant l’extrapolation de valeurs

22 22 OpenMASK distribué, 30 mai 2002 Principe è Utilisation d’une DSM (Mome [yvon Jégou]) permettant la cohérence relâchée et l’anticipation (prefetch) è Utilisation d’une file pour conserver l’historique des valeurs des sorties i i-3 i-2 i-1 i-3 i-2 i-4 RW ?I R R R 0 1 2 0 33 2 1 transfertprefetch Ri-5Ri-1

23 23 OpenMASK distribué, 30 mai 2002 Mémoriser l’historique è Mise en œuvre d’une file de valeurs à l’aide d’un tableau dont chacun des éléments se trouve sur une page différente, synchronisée indépendamment du contenu de la file ŸAllocation de tableaux de valeurs dans des pages contiguës, avec un décalage constant –Calcul d’adresse simple –Plusieurs tableaux par groupe de pages –Allocation des tableaux en fonction du nœud écrivain –Allocations dynamique de données de type et de taille non connu à l’avance ŸMise en œuvre permettant des accès rapides à la file

24 24 OpenMASK distribué, 30 mai 2002 Gestion de l’allocation è Détournement des mécanismes d’allocation dynamique de C++ è Vue simplifiée : ŸUn gestionnaire distribué de pages pour allouer les pages aux différents nœuds ŸLes nœuds allouent l’espace des éléments des tableaux dont ils sont les écrivains ŸEn cas d’allocation dynamique lors de l’écriture d’un élément du tableau, la mémoire est allouée par un gestionnaire de mémoire qui assure la synchronisation

25 25 OpenMASK distribué, 30 mai 2002 Algorithme de lecture des données è Les problèmes : ŸIl faut lire l’historique sans toucher certaines pages ŸÀ une page correspond un pas de simulation dans le cycle ŸUne donnée n’est pas nécessairement mise à jour à chaque pas du cycle ŸBesoin d’une lecture performante 440 1 v25 260 2 v12 580 8 v29 600 9 v30 160 7 v1 540 6 v28 320 5 v13 500 4 v27 420 0 v24 480 3 v26valeur date indice 260 v12 2 160 v1 7 320 v13 5 420 v24 0 synchro lecture écriture

26 26 OpenMASK distribué, 30 mai 2002 Algorithme de lecture è Invalidation de valeurs par transmission d’une date de plus ancienne valeur valide è Une valeur n’est valide que si sa date est supérieure ou égal à la date de validité associé à la plus récente valeur valide 440 1 v25 260 2 v12 580 8 v29 600 9 v30 160 7 v1 540 6 v28 320 5 v13 500 4 v27 420 0 v24 480 3 v26valeur date indice 260 v12 2 160 v1 7 320 v13 5 420 v24 0 synchro lecture écriture synchro lecture écriture validité30080260320240340360400180420

27 27 OpenMASK distribué, 30 mai 2002 Performance sous DSM è Accélération è Performance ŸDécevante pour le parallélisme ŸDifficile a analyser : –Les traces de la DSM valident le comportement –Les traces ne permettent pas l’analyse de performance

28 28 OpenMASK distribué, 30 mai 2002 Ri-5R Bibliothèque de DSM utilisée è Comportement réel ŸPour une page donnée, plus de défaut de pages que nécessaire, mais leur résolution devrait être locale ŸIl faudrait pouvoir spécialiser davantage la DSM i i-3 i-2 i-1 i-3 i-2 i-4 RW ?I R R R 0 1 2 0 33 2 1 transfert prefetch i-1 IR R RW

29 29 OpenMASK distribué, 30 mai 2002 Bilan è 2 mises en œuvre distribuées du noyau d’exécution d’OpenMASK ŸFonctionnent, et ont des performances satisfaisantes pour faire de la réalité virtuelle distribuée ŸElles sont améliorables, et vont l’être –PVM d’ici fin juin –DSM Mome dans la foulée (les problèmes dont plus complexes) è Elles sont compatibles avec la mise en œuvre parallèle pour SMP ŸAccélération linéaire au points de contention système près (allocation et libération de mémoire) pour de petits SMP ŸLa solution DSM+SMP est fonctionnelle

30 30 OpenMASK distribué, 30 mai 2002 Perspectives è D’ici la fin de mon post-doc industriel ŸAmélioration des performances des versions distribuées –Optimisation du sous-système PVM –Optimisation de la DSM utilisée è Si j’obtiens un poste de chargé de recherche ŸInstrumentation du sous-système DSM pour faire les bons prefetch ŸLes objets distribués Ÿ+ Nombreuses pistes pour généraliser encore l’abstraction proposée (couplage de code) –Objet de simulation -> composants –Modularisation du noyau d’exécution

31 31 OpenMASK distribué, 30 mai 2002 Merci de votre invitation è Des questions ?