Presentation of the 1st year Ph.D. students of the LIG

Encadrants:

• Didier Donzez (LIG, ERODS);
• Florence Maraninchi (VERIMAG, Synchrone);
• Gilles Privat (Orange Labs);
• CIFFRE;

Début de thèse: octobre 2013

Présentation de la notion de ville intelligente:

• objets avec capteurs
• collecte de donnée
• contrôle et action
• particularité: humains et capteurs pouvant intervenir sur le système et fournir de l'information

Difficulté:

• Verticalité: chaque entreprise/service municipal (déchets, éclairage, énergie, …) déploie ses propres services (capteurs, collecte, traitement, action,…)
• Besoin d'horizontalisation, i.e., de mise en commun de capteur et d'interactions.

Enjeu:

• standardisation des interfaces, distribution et partage des infrastructures, …

Positionnement de la thèse:

• Mise en place d'un middleware adapté à ce genre de contexte;
• À la croisée de problématiques capteurs, contrôle, infrastructures, systèmes d'information, contraintes légales;
• Évaluation de l'outil avec le cas d'usage de l'arrivée d'un nouvel utilisateur;

Questions:

• Vivien Quéma: Comment comptes-tu valider tes résultats et montrer l'apport de tes travaux par rapport à l'existant ?
  • Définir un cas d'usage pertinent mais à murir.
• Vania : Dans ton dernier slide, pour l'évaluation, tu parles de simulation. Comptez-vous utiliser des environnements types appartements intelligents
  • On y réfléchi.
• Grégory Mounié: Dans ton modèle, tu mets les commandes et les questions dans la même boite. Ça parait étrange.
  • Pas compris la réponse
• Grégory Mounié: Il y a des rétroactions dans ce type de système que tu ne sembles pas prendre en compte.
• Nassim Halli: Ça existe actuellement des villes intelligentes ?
  • Il y a Santander dans le cadre de projets européens mais c'est minoritaire. À Lyon, ils ont mis des capteurs dans la chaussée pour savoir s'il faut mettre du sel ou pas.

Encadrants:

• Sara Bouchenak (LIG, ERODS);
• Damian Serrano (LIG, ERODS);

Début de thèse: octobre 2013

• Motivation de l'utilisation du cloud computing
• Définition de la notion de fiabilité dans ce contexte
• Différentes thématiques de recherche:
  • modélisation pour faire de la prévision
  • systèmes auto-adaptatifs
  • virtualisation pour le rajeunissement des systèmes et la réplication. C'est à cette dernière qu'on s'intéresse ici
• Problématique de protocoles de tolérance aux fautes byzantines.
  • Performance (latence/débit) vs. fiabilité mais performance peu évaluée
  • 2 grands types de protocoles:
    1. ceux qui sont à hautes performance quand il n'y a pas d'erreur mais peuvent avoir d'assez mauvaises performances en cas de fautes
    2. ceux qui ont un niveau de performance acceptable quel que soit le workload
  • Objectif: évaluer ces différents protocoles
• Présentation des

Questions:

• Grégory Mounié: Le SLA est-il le bon modèle pour évaluer ce genre de problématique ? Dans le cas de la panne de google, c'était 500,000 clients avec un SLA de 1€.
  • C'est vrai.
• Vivien Quéma: Qu'entends-tu par fiabilité ? Et pourquoi s'intéresser tout particulièrement aux protocoles BFT qui sont plus difficiles à évaluer mettre en oeuvre que les protocoles crash resilient (genre PAXOS qui sont utilisés de partout et semble plus simple) ? Quelle est la motivation pour le byzantins en fait ? Ça parait super dur…
  • Damian Serrano y répond. Les crash protocoles sont déjà super optimisés. Il y a débat visiblement.
• Arnaud Legrand: Comment on injecte un tel workload ? Bon, pas le temps pour en discuter car le débat précédent a bien monopolisé l'attention.

Encadrants:

• Jean-François MÉHAUT (LIG, NANOSIM);
• Henri-Pierre Charles (CEA LIST);
• CIFFRE avec startup du CEA (Asleta Nanographics)

Début de thèse: janvier 2012

• INSCALE: application java graphique développée par la startup, d'où la motivation pour les applications java
• Optimisation faisable à plein de niveaux différents mais rarement spécialisés pour une application donnée.
• JVM = interpreter + JIT compiler + Memory Manager + Thread Manager donc plusieurs leviers possibles
• Architecture de plus en plus complexes (multi-core, out-of-order execution, SIMD instruction set, memory wall)
• Problème attaqué depuis cette année: comment utiliser la vectorisation pour des codes java?
  • Plusieurs options:
    1. On laisse le JIT faire (depuis java 8). Mais c'est une boite noire et on n'a pas d'autre alternative que de regarder l'assembleur généré pour savoir ce qu'il a fait. Le JIT ne sais pas vectoriser les réductions et il n'y a pas d'intrinsics pour le forcer ou le guider.
    2. Passer par l'interface native (JNI) mais demande de passer par du code statique (alors qu'en JIT, on peut avoir du polymorphisme, du code dynamique, …)
  • A déjà des résultats sur le thème où il a comparé les différentes alternatives.
• Autre problème attaqué: modifier la représentation des structures de données pour avoir de meilleurs performances mémoires.
• En cours:
  • Rajouter des intrinsics au HotSpot JIT.
  • Tenter d'autres environnements de compilation (LLVM - VmKit)

Questions:

• Arnaud Legrand: Slide "Java Performance Equation), ça sort d'où ce graphe ? On sait tracer ce genre de détails ?
• Grégory Mounié: Pourquoi Hotspot plutôt que Cacao qui faisait des trucs statiques assez intelligents ?
  • Pourquoi pas ? Cacao est plutôt une VM de recherche et on a quelques contraintes de robustesse avec l'application INSCALE. Ce qui est bloquant dans notre cas, c'est les spécifications.
• Grégory Mounié: Tu penses que les gens d'Oracle ont l'intention de modifier leur JVM pour que l'auto-vectorisation marche mieux ?
  • Il n'est pas du tout dans l'esprit de java de rajouter des trucs spécifiques comme ça. D'où l'idée de passer par une phase de pré-compilation avec LLVM.
• Vivien Quéma: Il y a des travaux en cours sur comment faire en sorte que la VM peut faire au niveau aliasing… euh, j'ai pas suivi la fin de la question.
• Grégory Mounié: Autre question mais on est pris par le temps.

Encadrants:

• Jean-François MÉHAUT (LIG, NANOSIM);
• Éric Rutten (Inria, CTRL-A);
• Gwenaël Delaval (LIG, NANOSIM);

Début de thèse: octobre 2013

Software Transaction Memory comes from database systems (commit, abort, rollback).

Different possible conflict solving strategies for threads: aggressive, suicide, backoff

Issues: monitoring, profiling, … are costly and the different strategies (contention management, concurrency policy, thread mapping, …) to use are difficult to identify and highly depend on the workload.

Idea: use autonomic control loop from control theory.

Questions:

• Arnaud Legrand: You may want to have a look at http://mescal.imag.fr/membres/arnaud.legrand/readings/rigor/thesis-jacqmot.pdf Ask me for the access codes.
• Vivien Quéma: Do you consider single application workloads or multi-application workloads ?
  • It does not matter.

Encadrants:

• Denis TRYSTRAM (LIG, MOAIS);
• Grégory Mounié (LIG, MOAIS);
• Thèse financée par la DGA

Début de thèse: octobre 2013

• Motivation
  • Petascale, exascale, architectures hybrides
  • Difficultés: passage à l'échelle, hétérogénéité hardware et software
• Approche
  • Ordonnancement à grain fin pour du data-flow au sein d'un noeud et avec une faible complexité algorithmique
  • Selon les approches, certaines sont performance agnostiques (e.g., vol de travail) ou pas (HEFT)
  • Essayer de définir une notion d'affinité qu'on puisse ensuite utiliser pour faire de l'approximation bicritère duale (DADA).
  • Affinité calculée de façon online et implémentation dans XKaapi
• Résultats
  • Validation sur Idgraf avec Cholesky, LU, QR
  • Un DADA performance agnostique arrive à s'en sortir mieux que HEFT sur le temps de calcul et arrive à diminuer la quantité de transferts mémoire.
• Perspectives
  • Étudier la robustesse des algorithmes aux informations de temps incorrectes.
  • Prendre en compte la contention de façon plus fine.

Questions:

• Arnaud Legrand: Je pensais que l'affinité était là pour rendre compte de la proximité de tâches ou de problèmes de contention en vue in fine de minimiser le temps de complétion.
• Arnaud Legrand: Comparaison avec StarPU à faire… Sur Idgraf et avec StarPU bien configuré, ça serait équitable.
• Arnaud Legrand: Comment traces-tu la quantité de mémoire transférée?
• Vania Marangozova-Martin: Quel besoin d'une abstraction de la ressource matérielle via cette notion d'affinité ?
  • Pour simplifier les heuristiques.
• Vania Marangozova-Martin: Tu mets quoi exactement dans cette notion d'affinité et comment combiner différentes notions d'affinité ?
  • L'aggrégation des critères, c'est dur. J'aimerais rajouté des notions de fiabilité/stabilité des performances des ressources.
• Jean-François Méhaut: La topologie de la machine est connue. Vos algorithmes peuvent-ils tirer parti de cette information ?
  • Dans les algorithmes que j'ai implémenté, la seule information utilisée, c'est la quantité de données écrites sur la ressource mais on pourrait pondérer cette information par la profondeur dans la hiérarchie NUMA.
• Vivien Quéma: Ta mémoire est éclatée sur différents bancs. Comment ça se passe quand tu as plusieurs applications qui tournent sur la même machine ? On les partitionne ? On les autorise à se marcher les unes sur les autres ?

Encadrants:

• Vania Marangozova-Martin (LIG, NANOSIM)
• Thèse dans le cadre du projet SoC-Trace (ST, ProBayes)

Début de thèse: octobre 2013

• Systèmes embarqués présents à tous les niveaux.
• Besoin de validation, debog
• Traces très fines (interruptions), multi-échelles (hardware/software), de très grandes tailles, de formats très différents, …
• Objectif: proposer une infrastructure logicielle FrameSoC
• Présentation de l'organisation dans le temps de l'évolution de ses travaux.
  • Format et stockage des traces: ajout d'une sémantique (état, causalité, variable, …) nous permettant d'identifier des anomalies.
  • Outils d'analyse statistique: essayer de formaliser les contributions précédentes. Technique de traitement du signal pour mettre en valeur la corrélation entre l'apparition d'évènements (pour essayer de détecter une causalité).
  • Workflow d'analyse de trace: interopérabilité des outils, notion de plan d'expérience, traçage des analyse, … A regardé vistrails.

Questions:

• Denis Trystram: T'as regardé Pegasus ?
  • Non, on commence juste sur les workflows
• Denis Trystram: Comment se passe la collaboration avec ProBayes ? Puisqu'ils sont impliqués dans SoC-trace, ça n'est pas lié ?
  • Pourquoi pas ? À réfléchir.
• Denis Trystram: Au LIG, il y a eu deux matinées Trace et dans HAMA, ils ont des problèmes proches. Vous avez participé à ces journées et discuté avec eux ?
• Nassim Halli; Les traces sont très grosses. Ces informations sont-elles toutes pertinentes et utilisées ?
  • Quand on fait la collecte, on ne sait pas forcément ce que l'on cherche a priori et on a donc besoin de récupérer le maximum d'informations.
  • En fait, même à l'heure actuelle, il n'y a pas forcément assez d'informations de tracées… Ça bricole pas mal à l'heure actuelle.

Encadrants:

• Guillaume HUARD (LIG, MOAIS)
• Bruno RAFFIN (LIG, MOAIS)

Début de thèse: octobre 2013

• Contexte
  • Simulation de systèmes physiques
  • Besoin de choses pas juste réalistes/crédibles mais aussi proches de la réalité que possible, le tout en temps réel pour entraîner les chirurgiens.
  • Travaux dans le cadre de SOFA qui est un framework efficace mais bien complexe…
  • Différentes parallélisation efficaces mais à l'état de prototype. La version de production utilise openmp de façon aggressive sans avoir fait un vrai bon profiling avant. Du coup, de temps en temps, ça gagne mais de temps en temps, ça perd également en performance par rapport à la version séquentielle.
  • Objectif: proposer une méthodologie générale pour l'optimisation des perfs appliquées à SOFA mais sans lui être spécifique
• Analyse
  • Première approche: perf counters avec likwid mais ça génère des traces difficiles à analyser. Ces
  • Les fonctions indiquées par les développeurs de SOFA comme étant coûteuses ne représentent pas non plus la partie la plus importante d'une exécution.
  • Les analyses en R permettent de repérer qu'on a peu d'instructions par cycles, probablement de problème
  • On aurait a priori les mêmes réponses avec des outils comme Oprofile ou Vtunes.
  • État de l'art par rapport aux outils comparables dans le monde du parallèle.
• Travaux en cours et perspectives
  • Objectif: détecter des patterns d'accès mémoire
  • Intégration/utilisation de FrameSoc ?

Questions:

• Arnaud Legrand: Tu connais facet_wrap et facet_grid ? :)
• Arnaud Legrand: Jean-François Méhaut a eu des étudiants qui ont travaillé sur ces aspects accès mémoire et pattern detection via du data-mining. Tu as regardé ?
• Nassim Halli: Dans les graphes montrés avec le profiling des fonctions: est-ce inclusif (-> non) ? La complexité des fonctions change-t-elle beaucoup avec le workload et au cours du temps (puisque tout est aggrégé là)?
  • En fait, le runtime lui même n'a pas accès à ces informations ?
• Nassim Halli: Une approche intéressante peut être de caractériser les fonctions et les méthodes avec des nano-patterns de performance (genre classifier en cpu-bound, memory-bound, …).
• Denis Trystram: Il est où le scheduler ?
  • Pour l'instant, les problèmes sont plutôt au niveau de la mémoire donc c'est là que le scheduler devrait intervenir. Ça peut rejoindre les travaux de Raphaël. Mais on n'en est pas là pour l'instant.
• Vania Marangozova-Martin: Le profiling des accès mémoire sont très coûteux. Tu pourrais regarder les travaux sur la réexécution déterministes de systèmes (pour le debuggage). Ces gens là ont des stratégies pour diminuer la quantité d'information capturée.
• Vivien Quéma: Tu veux mieux paralléliser SOFA. Ta contribution est dans le monde parallèle ou dans le monde de la simulation physique ?
  • Plutôt dans le monde parallèle en fait. L'objectif est de faire le ménage, d'avoir une méthodologie propre. SOFA est une motivation et finalement un use case.
• Vania Marangozova-Martin: Mettons que tu arrives à obtenir les informations pertinentes (sachant que ça peut prendre du temps).

Encadrants:

• Denis Trystram (LIG, MOAIS)

Début de thèse: octobre 2013

• Requested_time is a very bad approximation of run_time, hence holes in the scheduling. Furthermore, architectures are hierarchical.
• Goal: try to improve scheduling in this context
• Two published articles on scheduling topics bue somehow unrelated to the PhD thesis

Questions:

• Arnaud Legrand: what is the current status or your research on this particular research topic ?
  • We worked on related subjects but it's ongoing and preliminary at the moment.

Encadrants:

• Vivien Quéma (LIG, MOAIS)

Début de thèse: octobre 2013

• Motivation:
  • Scalaris est un système de stockage key/value open source qu'on va utiliser pour conduire notre étude
  • Complexité (protocole, code, déploiement) -> sujet à faute
  • Objectif: s'assurer de la cohérence des données dans le système. On se moque des performances ici.
    • exécution pas à pas impossible
    • Émulation difficile
    • Condition réelles difficilement reproductibles
  • Comment tester efficacement la cohérence d'un système distribué?
• Framework d'émulation
  • À base de VM Xen.
• Framework de test
  • Besoin d'un système de breakpoint distribué pour faire des tests plus fins et modification de Scalaris à cet effet.
  • Difficulté de la génération des tests (sampling d'espace d'état infini)

Questions:

• Arnaud Legrand: Perte des performances, ok, mais est-ce si obligatoire que ça ? (e.g., distem). Quid des solutions à bases de containers ?
• Vania Marangozova-Martin: Tu veux faire un outil d'émulation d'algorithmes distribués. Quelle différence avec des outils de simulation d'algorithmes distribués ?
  • C'est plus réaliste. On travaille sur le code et pas sur l'algorithme.
• Arnaud Legrand: En fait, tu pourrais simuler en interceptant les appels systèmes et en réinjectant dans un simulateur.