-
Notifications
You must be signed in to change notification settings - Fork 0
Itérations
-
Objectif général
- Faire un shader minimal qui marche et qui renvoie des données, Coder un shader de Benchmarking.
- Création/Gestion/Liste des organisations et projets
-
Objectifs détaillés
- Le shader minimal effectue un simple algorithme et retourne la valeur dans une texture. Le shader tourne sur le processeur graphique du client et va stocker les résultats sous format RGBA.
- Un utilisateur doit pouvoir créer, gérer et lister des organisations ainsi que leurs projets. Pour ce faire, il disposera de différents formulaires HTML. Une fois ces formulaires validés, les données seront ajoutées à la base de données.
Une semaine
Du 22 avril au 29 avril 2015
Sacha: Création de l'environnement de travail, création de la base de donnée Fabien: Ajout de divers module frontend, base de style, création des formulaires Léonard et Henrik: Réfléxion sur les possiblité de communication entre Javascript et les shaders, création des shaders simples et de benchmarking.
- Sacha: 8h
- Fabien: 5h
- Léonard et Henrik: 7h
L'itération a été terminée avec succès. Toutefois, quelques problème de comportement sur les shaders sont à noter.
Par exemple, les shaders effectuent le calcul à chaque nouvelle frame au lieu d'une seul fois par lancement du script. De plus, le nombre d'opération du langage est très fortement limité et la récupération des données s'avère fastidieuse.
Des tests approfondis de faisabilité par rapport à l'utilisation de fragment shaders pour les calculs sont à effectuer.
Tâches ajoutées:
- Léonard et Sacha: faire des tests de faisabilité avec des shaders WebGL. (2h)
- Fabien: faire des tests de faisabilité avec la lib WebCLGL.js. (1h30)
La communication à distance entre les membres (chat, vidéo-conférence) peut encore être améliorée.
-
Sacha Bron
Apprentissage approfondi des différentes technologies utilisées: Meteor.js, MongoDB, différentes glues, WebGL. Implémentation complète des schémas de collections et des formulaires de création des organisations et projets. -
Fabien Salathe
Lecture et apprentissage de la documentation de LESS ainsi que de meteor. Code javascript pour meteor (routes, templates, configuration de Meteor.js). Design du logo. -
Henrik Akesson
Etude de WebGL, HTML/Javascript, développement de minimalPi.html, développement d’un shader minimal de benchmark, permettant à l’application de déterminer la puissance d’une machine cliente afin de pouvoir attribuer des processus et intervalles de calcul appropriés (cf minimalPi). -
Léonard Berney
Étude de WebGL, implémentation d’un système de types permettant de convertir des entiers et floats en RGBA. Ecriture de shaders de tests.
- Sacha: 8h
- Fabien: 7h
- Léonard: 5h
- Henrik: 5h
Aucune modification n'est à apporter.
-
Objectif général
- Créer un protocole de communication shaders ↔ Serveur
- Upload de shaders sur les projets, Les Peers doivent pouvoir cliquer sur un bouton lançant les calculs sur leur machine.
-
Objectifs détaillés
- Les shaders exécutés sur les machines des clients doivent retourner des résultats au serveur. Le but côté shaders de cette itération est de mettre en place un protocole de communication qui pourra ensuite permettre au serveur d'interpréter les résultats et aux organisations/utilisateur de les télécharger.
- Les shaders doivent pouvoir être envoyé sur le serveur, stocké en base de données et rendu sur demande. Les peers doivent pouvoir cliquer sur un bouton téléchargeant le shader et lançant les calculs.
Une semaine
29 avril au 6 mai 2015
- Leonard, Henrik: Protocole shader <-> server
- Fabien: Lancement des calculs à partir d'un clic sur un bouton
- Sacha: Formulaire d'envoi du shader et stockage de ce dernier
- Sacha: 6h
- Fabien: 6h
- Léonard et Henrik: 7h
Un des attraits principaux du projet était de pouvoir bénéficier de la puissance des cartes graphique pour faire du calcul distribué.
Après plusieurs tests, nous avons réalisé que la technologie WebGL n'était pas encore assez mature pour un tel projet et avons donc dû l’abandonner pour plusieurs raisons:
- Il est incroyablement complexe d'implémenter des algorithmes en WebGL à cause des limitations du langage (peu de fonctions à disposition, manque d'opérateurs, etc.). Les utilisateurs auraient donc dû passer en temps beaucoup trop élevé pour implémenter des algorithmes même basiques.
- Un des plus gros problèmes est que WebGL ne supporte pas la double précision. Faire des gros calculs pour au final n’obtenir que quelques chiffres de précision n'a pas d'intérêt.
- Dans les tests que nous avons effectués, les shaders n'étaient souvent pas portables et fonctionnaient rarement sur plus d'un navigateur.
- Il arrivait fréquemment que, lorsque la charge de calcul était élevée, le driver de la carte graphique plante.
C'est donc toutes ces raisons qui nous ont incités à abandonner WebGL au profit d'asm.js. Les programmes seront nettement plus simple à écrire pour les utilisateurs et fonctionneront sans problème sur chaque navigateur.
-
Sacha Création d'un système d'upload de fichiers, création d'une page de gestion de projets.
-
Fabien Création d'un bouton permettant de lancer les calculs du côté du client.
-
Léonard, Henrik Écriture de shaders de tests et benchmarks, découverte et approfondissement quant à l'impossibilité de continuer d'utiliser WebGL.
- L'itération 3 doit être complètement revue.
- La partie "shaders" des itérations suivantes sera à replanifier en tenant compte des derniers changement de conception.
- Sacha: 5h
- Fabien: 2h
- Léonard: 5h
- Henrik: 3h
La replanification des itérations va demander une légère charge de travail supplémentaire.
Cependant, l'utilisation d'asm.js sera probablement un gain de temps, étant donné que tous les tests seront fait dans des langages connus des développeurs.
-
Objectif général
- Creer un script Docker qui doit créer un container et installer emscripten au démarrage du serveur.
-
Objectifs détaillés
- Le but d'avoir un container pour contenir emscripten est d'augmenter la sécurité du serveur.
- Un utilisateur envoyant du code malicieux ne pourra pas récupérer de données liées au serveur, car un container ne peux pas accéder au système hôte.
- Dans le cas où le container est corrompu, il suffit de le détruire et de le recréer avec le même script.
Une semaine
Du 6 mai au 13 mai 2015
- Sacha & Fabien : partie serveur, gestion des résultats
- Léonard : écrire le dockerFile
- Henrik : Interpréter les valeurs de retour (RGBA) selon le type voulu du projet
- Sacha: 5h
- Fabien: 6h
- Léonard et Henrik: 8h
L'itération a été effectuée avec succès. Le script Docker peut être lancé en une seule ligne de commande. Il va s'occuper de prendre un fichier C/C++, le compiler en asm.js à l'aide de LLVM et Emscripten, puis déposer le fichier dans un dossier. Un programme de test a été écrit en C++.
Certaines itérations ont été ré-écrite afin de correspondre à l'abandon de la technologie WebGL, jugée trop peu mature et trop imprécise.
- L'itération 4 et l'itération 6 ont été presque totalement ré-écrite.
- Le terme de shader a été remplacé par programme.
-
Sacha Bron
Ré-écriture des itérations. -
Fabien Salathe
Intergration de LLVM et Emscripten dans Docker. -
Henrik Akesson
Création et configuration du Docker. -
Léonard Berney
Création et configuration du Docker.
- Sacha: 4h
- Fabien: 5h
- Léonard: 6h
- Henrik: 5h
Aucune modification n'est à apporter.
-
Objectif général
- Lancement du programme depuis un peer et récupération des résultats. Compiler le programme en asm.js au moment de l'upload d'un fichier.
-
Objectifs détaillés
- Les utilisateurs (peers) doivent pouvoir lancer les calculs sur leur machine grâce à un simple clic sur un bouton. Les calculs doivent tourner dans un Web Worker afin d'éviter le gèle du navigateur.
- Les résultats des calculs distribués doivent être présenté de la manière la plus pratique pour chaque organisation. Pour cela, les données seront affichées dans différents formats, selon le choix de l'utilisateur. Les formats gérer seront en tout cas Json et XML. Ces données pourront aussi être téléchargées.
- Un hameçon doit être appelé au moment de l'envoi d'un fichier C, afin de lancer sa compilation en asm.js. C'est le résultat de cette compilation qui tournera sur les machines des peers.
Une semaine
Du 13 mai au 20 mai 2015
- Sacha & Fabien : partie web (lancement des calculs, hook)
- Henrik & Leonard : compilation du programme dans un conteneur Docker
- Sacha: 8h
- Fabien: 5h
- Léonard et Henrik: 7h
Les scripts compilés en asm.js peuvent être lancés à l'aide d'un clic sur le bonton permettant de lancer les calculs. Pour ce faire, les scripts doivent être compilé avec emcc et les options --pre-js et --post-js afin d'ajouter le javascript necéssaire à la communication entre le webworker (dans lequel tourne l'asm.js) et le javascript côté client (Meteor). Ces communications se font par le protocole de message standard.
Durant le développement de cette partie, nous avons dû faire plusieurs choix. Tout d'abord, comment permettre de manière simple au créateur du code C/C++, de choisir de renvoyer des données à Podicus, un fois son script compilé en asm.js et executé dans un webworker, sans pour autant compromettre la sécurité de l'écosystème.
La solution choisie est d'utiliser les arguments de la fonction main(int argc, char** argv) pour entrer des valeurs dans le programme, et d'utiliser la sortie standard comme flux de communication vers la base de donnée MongoDB.
Dans l'itération 6, il faudra rattraper l'objectif qui n'a pas été réalisé: ajouter les résultats en base de donnée et présenter les résultats de manière élégante. Finalement, le seul format gérer sera le Json, car il est trop difficile de nommer les balises XML de manière assez génériques pour que cela ait du sens pour n'importe quel projet. De plus, il existe une multitude d'outils permettant de convertir du Json en XML.
-
Sacha Bron
Communication par message entre le webworker et Meteor.
Cette communication se fait à l'aide de la fonctionpostMessageet en lui passant tous les arguments nécessaire au programme à l'aide d'un tableau de chaînes de caractères. Pour récupérer la sortie standard du programme, une astuce a été utilisé, permettant de récupérer toutes sorties vers la console Javascript et de les rediriger vers la base de donnée. -
Fabien Salathe
Bouton de lancement des calculs et création du webworker.
Au moment du clic du bonton, Meteor s'occupe de récupérer le bon script asm.js dans la base de donnée MongoDB et l'execute ensuite à l'intérieur d'un webworker. -
Henrik Akesson et Léonard Berney
Recherche sur un moyen idéal de générer du C pouvant communiquer avec l'extérieur.
Il existe une multitude de moyens de communication avec un script asm.js. Par exemple, on peut inclure la bibliothèqueemscripten.het profiter de ses fonctionalités, ou encore appeler des fonctions C précises directement depuis le Javascript. Cepandant, ses méthodes, bien que fonctionnelles, ont été écartées car leur implémentation obligeait le programmeur de l'organisation à installer Emscripten ou à créer des fonctions au nom valide. De plus, des erreurs auraient pu apparaitre (fonctions introuvables, fonctions utilisées de manière incorrecte) et une gestion de ces erreurs aurait été imposée. Nous avons donc préféré utiiser les entrées et sorties standards.
- Sacha: 6h
- Fabien: 5h
- Léonard: 4h
- Henrik: 4h
Aucune modification n'est à apporter.
-
Objectif général
- Système d'entrée de paramètre pour chaque projet, coder un scheduler afin de répartir le travail entre chaque peer.
-
Objectifs détaillés
- Création d'une collection destinée à l'enregistrement des paramètres des projets.
- Mise en place d'un formulaire complexe afin de permettre à l'utilisateur d'entrer des séries de paramètres. Ce formulaire doit permettre un maximum de souplesse dans le but de supporter un nombre maximum de cas d'utilisation des programmes. Ces différents paramètres seront ensuite entrer dans la base de données et envoyées au peer en même temps que le programme associé.
- Mise en place d'un scheduler permettant de répartir les calculs à effectuer entre les différents peers. Ce scheduler doit gérer une file d'attente de tâches à effectuer pour chaque projet, puis les répartir au mieux (selon la puissance des peers, si possible). Si une tâche ne peut pas être effectuée entièrement par un peer (déconnexion, crash, etc.), la tâche est alors remise dans la file du scheduler.
Une semaine
Du 20 mai au 27 mai 2015
- Sacha & Fabien : partie web
- Henrik & Leonard : coder un scheduler
- Sacha: 4h
- Fabien: 5h
- Léonard et Henrik: 11h
Le système de paramétrisation des projets a été mis en place. Il permet aux membres des organisations de définir des paramètres qui seront ensuite transmis aux clients faisant les calculs. Ces paramètres sont des fonctions mathématiques dans lesquels on peut utiliser une variable x (par exemple: x / 2 + sin(x deg)). Cette variable x sera définie pour chaque client par le scheduler. Elle variera itérativement entre 0 et +∞.
Afin de lire les fonctions mathématiques, nous utilisons la bibliothèque mathjs que nous avons inclus à Meteor.
Les paramètres sont ensuite stockés dans la base de données MongoDB. Ils sont ensuite envoyé aux clients en faisant itérer la variable x de la fonction donnée.
Lorsque les clients lancent le programme, ils stockent aussi leur progression dans une collection MongoDB. Un fois les calculs terminés, la progression est mise à jour pour en informer le scheduler.
Dans l'itération 6, Nous devons ajouté de la redondance dans les calculs. Cela revient à faire en sorte que plusieurs clients fassent le même calcul afin d'obtenir, par exemple, une vérification des résultats ou des statistiques.
-
Sacha Bron
Génération et passage des paramètres variables au WebWorker de chaque client. Inclusion de mathjs.
Le choix d'utiliser des fonctions mathématiques à de nombreux avantages:- Tout le monde connait la synthaxe des fonctions mathématiques (
+,-,*,/,^,cos(...), etc.) - Il est possible d'obtenir n'importe quel valeur de sortie selon
x. - Nous n'avons besoin que d'une seule variable itérative.
Affichage des résultats.
Les résultats bruts sont affichés en Json aux membres des organisations. Ils s'agit d'une simple récupération des données stockées sur MongoDB.
- Tout le monde connait la synthaxe des fonctions mathématiques (
-
Fabien Salathe
Mise en place du formulaire d'insertion des paramètres.
Les paramètres du formulaire sont envoyés au programme dans le même ordre qu'ils apparaissent dans le formulaire. Ceci a été possible car Javascript et MongoDB gardent l'ordre des éléments dans leurs tableaux. Un tableau d'objet comportant les labels et les fonctions aura alors toujours le même ordre. -
Henrik Akesson et Léonard Berney
Création du scheduler et de la collectionProgresspremettant de gérer les paramètres déjà calculé ou à calculer. L'une des difficultés était de savoir quand est-ce que le WebWorker a réelement terminé de faire les calculs. Pour ce faire, le protocole de communication entre le WebWorker et Meteor a été amélioré. Désormais, une clé a été ajoutée afin de savoir si c'est une valeur à stocker qui est envoyée ou l'indication de fin de programme.
- Sacha: 5h
- Fabien: 4h
- Léonard: 5h
- Henrik: 5h
Aucune modification n'est à apporter.
- Intégration du système de compte et droits sur les pages.
- Possibilité de voir les comptes utilisateurs des organisations, de modifier leurs droits (ajouter ou retirer).
- Coder des modèles de programme réutilisables et paramétriques (BitCoin, Monte-Carlo, etc.). À terminer à l'itération 7.
- Un programme calculant une fractale est intéressant dans la mesure où il permettra de tester la capacité du système à traiter une grande quantité de données. De plus il est intéressant d'avoir un résultat visuel. À terminer à l'itération 7.
- Possibilité d'ajouter de la redondance dans les calculs pour chaque projet.
Une semaine pour la partie web, deux semaines pour les programmes.
Du 27 mai au 3 juin 201
Sacha: Redondance dans les calculs Fabien: Intégration du système de compte et droits sur les pages Henrik: Création du programme de minage bitcoin Leonard: Création du programme fractal
- Sacha: 4h
- Fabien: 4h
- Léonard et Henrik: 8h
Ajout de la redondance dans les calculs. Désormais, plusieurs clients feront le même calcul et les stockent dans la base de données sous différentes entrées.
Création du système de compte. Un système de compte a été créé. Chaque compte a un nom d'utilisateur, une adresse email, et un mot de passe. Une fois connecté, l'utilisateur peut créer une organisation et/ou être ajouté dans une organisation.
Gestion des membres d'organisations. Les organisations peuvent autant de membres qu'elle le souhaite. Tous les membres ont les mêmes droits sur les projets et sur la gestion d'accès à l'organisation.
Les différents résultats obtenus issus de la redondance doivent pouvoir être comparé de manière simple. C'est-à-dire que l'interface de projet doit permettre de configurer un traitement sur les résultats.
-
Sacha Bron
Création des formulaires de création de compte et connexion. Gestions des utilisateurs du site web.
Les informations sont stockées dans une nouvelle collection MongoDB prévu à cet effet. L'ID des membres et aussi récupérer afin de pouvoir le stocker dans d'autres tables (par exemple:Organisations.members).
Le système de redondance a aussi été mis en place afin de permettre aux membres des projets de choisir si les calculs doivent être effectué plusieurs fois. Pour cela, le système d'état du scheduler a dû être légèrement modifié.
-
Fabien Salathe
Création de la page de gestion des organisations permettant d'ajouter ou retirer des membres.
N'importe quel utilisateur connecté et faisant partie d'une organisation peut ajouter ou retirer des membres à ladite organisation. En outre, il ne peut se retirer lui-même pour éviter d'avoir des organisations vides de membres. -
Henrik Akesson et Léonard Berney
Création de différents programmes permettant de tester le système en profondeur.
- Sacha: 4h
- Fabien: 5h
- Léonard et Henrik: 6h
Aucune modification n'est à apporter.
-
Objectif général (résumé) en une phrase
- Outils d'administrations (tous les droits sur le site web), coder des modèles de programmes réutilisables et paramétriques (bis).
-
Objectifs détaillés à classer dans l’une ou l’autre parmi 3 catégories
- Coder des modèles de programme réutilisables et paramétriques (BitCoin, Monte-Carlo, etc.).
- Créer une nouvelle vue pour afficher l'administration
- Possibilité de voir les gens connecté en live, modifier, bannir des comptes etc.
Une semaine
Du 3 juin au 10 juin 2015
- Sacha & Fabien: Création de l'interface admin, tests, finissions, docs
- Henrik: Création du programme de minage bitcoin
- Leonard: Création du programme monte carlo et autre cas
- Sacha: 9h
- Fabien: 9h
- Léonard et Henrik: 10h
L'interface administrateur a été mise en place et permet d'administrer les organisations et leurs membres. Un programme de recherche de nombres amis a été créé afin d'avoir une démonstration concrète de ce à quoi pourrait servir le projet.