GH: intro et information sur la journée d'Avril 2003 à Nice. On y a présenté l'avancement du projet CARAML aux autre participants à l'ACI-GRID. Voir les transparents présentés à cet effet.
Avancement de caml. Polymorphisme de première classe (types des champs d'enregistrements): Garrigue et Rémy. Modules récursifs. Typage dynamique pour output-input value, pour le marshalling (J. Faruse GCaml). JoCaml: calcul et langage pour la mobilité et la synchronisation. Travaux en cours, questions difficiles et ouvertes: mobilité du code (difficile car les machines n'ont pas toutes le même code à priori). Mobilité basée sur les fichiers *.cmo (unité de compilation, modules). Vérif de type au moment de l'envoi des messages. Problème d'identité des types abstraits. Modèle de pannes.
Etat de la bibliothèque ocamlP3L. Les primitives déclaratives exprimant du parallélisme possible. Illustration graphique de ces "graphiques". Seq, Pipe, Fram, Loop, Map, Reduce. Choix de la stratégie d'exécution laissé au compilateur. Code utilisateur inchangé selon la bibliothèque qu'on utilise pour compiler: séquentiel, parallèle (ou GRID ?), choix aussi d'une compilation pour graphisme. Tout ceci étant sémantiquement équivalent. Relative facilité de la vérification de programmes: il suffit de prouver un programme applicatif fonctionnel (programmeur) + prouver l'implantation de chacune des primitives ocamlP3L (spécialiste). "Vrais" utilisateurs INRIA en simulation numérique pour l'industrie pétrolière. Solveurs spécifiques aux types de sols, il faut les combiner tout en les parallélisant. Simplicité d'intégration de codes écrits en d'autres langages. En cours: intégration de la syntaxe du placement des tableaux dans map avec les tableaux caml, compilation efficace.
Etat des travaux autour de BSMLlib à Créteil: vérification formelle Coq de programmes BSMLlib, modèle d'évaluation minimalement synchrone, nouvelle implantation CAML-MPI. Typage statique avec les sortes des deux niveaux. Implantation formellement vérifiée d'un sous-ensemble de Caml-light.
Modèle des algorithmes asynchrone de Bertsekas. Utilité, flexibilité et déterminisme mais échec des modèles de coût data-parallèles usuels qui tombent alors dans le pire cas des délais de communication et synchro. Bertsekas a introduit un temps local virtuel, et modélise de manière relâchée les entrelâcements de calcul local et de communication. Ces itérations "chaotiques" font qu'on peut travailler avec des données périmées. Des conditions suffisantes assez larges impliquent la convergence sur la même valeur vectorielle qu'un calcul synchrone de référence. On travaille sur une meilleure formalisation du modèle en éliminant la notion de temps local virtuel. Ce modèle permettra de gérer les imprévus dans un contexte GRID, imprévus dans les délais de communication.
Travaux au LIFO sur PDB. Ocaml doit appeler un système d'évaluation parallèle de jointures (maintenant multi-jointures) écrit en C et MPI. On a essayé de faire du multi-thread mais trouvé que c'est sans intérêt pour le moment. On a un analyseur syntaxique des requêtes SQL. Fonctions CAML: lancer l'exécution, consulter le résultat ODBC. En dessous du code C+MPI on a MySQL. Ajout de directives à la requête SQL pour indiquer le placement des données à l'entrée et à la sortie ainsi que les processeurs à utiliser. Le compilateur génère un plan parallèle. Fragmentation horizontale des tables (pas de répétition). Stratégie de pipelinage des différentes phases d'une requête.
On a isolé trois grandes directions de recherche qui ont servi de partition aux participants pour travailler en sous-groupes:
Les sous-groupes ont travaillé environ 45 minutes puis chacun a présenté ses conclusion à l'ensemble du projet. Cette dernière partie n'a pas donné lieu à beaucoup de remous, on peut donc simplement résumer les conclusion de chaque sous-groupe. Veuillez excuser l'inégalité de détail des commentaires puisque je participais moi-même à 2.2.
Le but est d'adapter le modèle BSP à l'utilisation simultanée de plusieurs grappes. On propose simplement d'ajouter un troisième niveau à la syntaxe et à la sémantique de BSML. Les trois niveaux seront donc: processeur, machine parallèle, réseau de machines parallèles. Primitives de communication à la BSML:
mkgrid (fun site -> mkpar (fun pid -> e(site,pid))) etc.
Question ouverte: et le modèle de coût ? Est-ce qu'on peut traiter g de manière homogène à travers les valeurs de la variable "site" ?
Il s'agit ici d'augmenter nos systèmes avec des annotations servant d'estimé des ressources disponibles et de la consommation de ressource prévue par le programme. Le système pourra utiliser ces annotations pour optimiser au mieux. Les irrégularités prévues concernent donc i) les ressources disponibles et ii) la consommation de ces ressources en calcul et comm; cela se décline au niveau a) du processeur b) du site géographique (la machine parallèle, la grappe etc) et c) du temps car les bandes passantes auront tendance à varier de manière imprévisible et les processeurs seront eux-mêmes libres ou chargés par d'autres applications.
Pour ocamlP3L on propose d'annoter la fonction map
map scol:[c1;c2;c3](f,3)
en donnant par ex ici le nombre 3 de processeurs prévus (ou désirés?).
Pour BSML on pourra annoter la fonction put avec les volumes prévus des messages (valeurs h_i+ et h_i- prévues).
On pourra écrire des fichiers de configuration où on déclare les performances prévues des processeurs et déclarer la bande passante entre des paires de processeurs. Toutes ces infos pourront être symboliques ou énumératives selon la quantité disponible: inventer une syntaxe hybride.
Adapter cela à de la variabilité dynamique des ressources ? On pourra faire écrire des fichiers de config dynamiquement avec des valeurs instantanées et lissées, mesurées par des programmes moniteurs tournant en continu.
Il reste beaucoup à faire sur l'outil PDB sur système parallèle dédiée et la principale difficulté est de ne pas pouvoir ouvrir le code (par manque de temps surtout) des SGBD appelés. Il faudra aussi adapter l'outil PDB au contexte GRID. On propose pour cela deux grandes pistes, à explorer séparément puis éventuellement à combiner:
i. Soit que les données ne sont pas géographiquement répliquées. Chaque site possède une base de donnée distincte ou des tables distinctes de la même bd. Alors les calculs se feront selon la distribution initiale des données. Les sous-requêtes seront exécutées en local sur chaque site => accélération parallèle. A voir: où stocker les résultats s'ils sont volumineux, c-à-d volumes de communication à la sortie.
ii. Soit que les données sont répliquées sur chaque site. On autorisera le découpage pour accélérer les calculs en utilisant plusieurs sites. A suivre.
Gaétan
mai 2003