Forum FAH-Addict

Le 27/03/2012 à 13h10

Administrateur

Groupe: Administrateur

Inscrit le: 04/06/2009
Messages: 622

MSN    
Le 31/03/2012 à 18h58

Electron

Groupe: Membre

Inscrit le: 28/03/2010
Messages: 81
Adanorm:
Faudrait essayer avec des vins moins frelatés ou, au contraire, des vins encore pires que le beaujolpif.
Histoire d'éponger les excédents....

Bientôt on devra peut-être se soumettre à l'éthylomètre avant de démarrer un ordinateur... :siffle :lol
____________________
Rien n'est plus provisoire que les certitudes
(et encore... je m'demande...)

   
Le 01/04/2012 à 16h48

Administrateur

Groupe: Administrateur

Inscrit le: 04/06/2009
Messages: 622
:D ce soir, 3 caisses de chateau neuf du pape, j'OC !

MSN    
Le 21/05/2012 à 14h32

Proton

Groupe: Membre

Inscrit le: 13/06/2009
Messages: 435
Amis plieurs sous Linux avec un Sandy bridge cette news est une bonne nouvelle ->

http://www.pcinpact.com/news/71023-linux-noyau-ameliorations-btrfs-x32.htm
:top
____________________
Config (H24) : Xeon E5 2699V3 (BOINC) + GTX980Ti (Folding)

MSN Web    
Le 21/05/2012 à 16h43

Administrateur

Groupe: Administrateur

Inscrit le: 04/06/2009
Messages: 622
Je sais bien :) j'ai hate de mettre à jour ma Mint pour passer sur le noyau 3.3, ya déjà du mieux sur Sandy

MSN    
Le 27/05/2012 à 21h45

Administrateur

Groupe: Administrateur

Inscrit le: 03/06/2009
Messages: 632
Elle est sortie la Mint 13 ... par contre elle se met pas à jour toute seule comme une Ubuntu :(

MSN    
Le 28/05/2012 à 09h34

Administrateur

Groupe: Administrateur

Inscrit le: 04/06/2009
Messages: 622
Yep, c'est pour ça que j'ai pas encore mis a jour.
Je vais faire une méthode avec backup du home lorsque j'aurais pas la flemme

MSN    
Le 18/06/2012 à 14h32

Proton

Groupe: Membre

Inscrit le: 13/06/2009
Messages: 435
http://www.presence-pc.com/actualite/BlueGene-Q-Sequoia-47924/#xtor=RSS-11

Le K computer se prend une claque, f@h et BOINC aussi pour le cou^p.

Aller c'est bientôt les soldes il va falloir investir les gars. :hehe

____________________
Config (H24) : Xeon E5 2699V3 (BOINC) + GTX980Ti (Folding)

MSN Web    
Le 18/06/2012 à 14h48

Electron

Groupe: Membre

Inscrit le: 19/05/2010
Messages: 99
16.32 PFLOPS !! Pfff trop facile !!!! Je fais la même avec ma HD5770 :hehe
____________________

Web    
Le 18/06/2012 à 17h10

Administrateur

Groupe: Administrateur

Inscrit le: 04/06/2009
Messages: 622
Mais on à plus de client Power PC :D

MSN    
Le 18/06/2012 à 20h27
____________________
Config (H24) : Xeon E5 2699V3 (BOINC) + GTX980Ti (Folding)

MSN Web    
Le 19/06/2012 à 00h06

Administrateur

Groupe: Administrateur

Inscrit le: 04/06/2009
Messages: 622
Oué, ça c'est une news :D

MSN    
Le 04/07/2012 à 08h34

Proton

Groupe: Membre

Inscrit le: 13/06/2009
Messages: 435
____________________
Config (H24) : Xeon E5 2699V3 (BOINC) + GTX980Ti (Folding)

MSN Web    
Le 04/07/2012 à 18h40

Administrateur

Groupe: Administrateur

Inscrit le: 04/06/2009
Messages: 622
c'est prévu ^^

MSN    
Le 04/07/2012 à 19h02

Electron

Groupe: Membre

Inscrit le: 28/03/2010
Messages: 81
En voici une :

Une des questions que l'on me pose le plus fréquemment est de savoir comment nous gérons la programmation de nos client / serveur / core et l'administration de l'infrastructure. En outre, d'autres étaient curieux de connaître les mises à jour sur différents projets de cores. Alors, j'ai pensé qu'il était logique de répondre en une fois, puisque les réponses sont liées. Ce sera une longue réponse à plusieurs questions courtes, mais nous j'espère qu'elle contribuera à donner un aperçu de la façon dont nous faisons ce que nous faisons.

Tout d'abord, un peu d'histoire. Quand nous avons commencé en 2001, j'ai personnellement écrit la plupart du code (client, serveur, intégration du code scientifique, etc), avec l'aide d'un "étudiant d'été" (le Dr Chapman Jarod) et l'aide d'Adam Beberg sur des questions générales de calcul distribué et l'utilisation de sa bibliothèque réseau Cosm. Je commençais juste en tant que professeur, puis, avec un groupe relativement restreint (4 personnes à la fois), de sorte qu'il était courant pour le chef du laboratoire de mettre la main à la pâte.

Comme le temps passait, le groupe mûrit et grandit, avec l'augmentation du financement du NIH et la NSF. Cela a permis au groupe de croître pour atteindre environ 10 personnes en 2005. À ce stade, la plupart des fonctions ont été confiées à des personnes différentes dans le laboratoire: le développement du code serveur a été réalisé par Young Rhee Min (maintenant professeur), puis plus tard par le Dr Guha Jayachandran. Le développement du client a été réalisé par Siraj Khaliq, puis Guha, puis l'aide de quelques autres (y compris Adam Beberg ainsi que des bénévoles, comme Oncle Fungus). Le développement du coeur a été effectué par le Dr Rhee, Michael Shirts (maintenant professeur), et d'autres.

Ce modèle a raisonnablement bien fonctionné, chaque membre de l'équipe consacrant une part significative, mais pas exagérément importante de son temps (par exemple 10% à 20%) au développement de FAH. Ces principaux développeurs ont pu ajouter un grand nombre de fonctionnalités, à la fois pour aider la science et améliorer l'expérience des donateurs.

Toutefois, dans le temps, ce modèle est arrivé à ses limites. Le temps passant, les développeurs individuels diplômés (dans la recherche universitaire, la recherche est faite par des étudiants diplômés ou stagiaires postdoctoraux, qui ne restent que de 3 à 5 ans). Alors que l'équipe originale était en mesure de construire un système puissant et complexe, le maintien de ce système par les nouvelles générations d'étudiants / post-doctorants est devenue intenable. Le code est complexe et bien connu par les auteurs originaux, mais l'entretien par les nouveaux développeurs était complexe et source d'erreurs, en raison de la complexité du logiciel.

En parallèle à ces efforts dans le développement du code, nous sommes aussi aux limtes de notre infrastructure serveur. Nous sommes passés de quelques serveurs de petite taille (disques durs de 10 Go !), à une très grande infrastructure comparable à celle d'une entreprise, avec des centaines de téraoctets de stockage. Cela aussi est devenu un défi majeur à gérer par le groupe scientifique.

Un nouveau plan. Par conséquent, en 2007, j'ai commencé un nouveau plan de migration de ces fonctions (développement du code et administration du système) en les confiant à des programmeurs et des administrateurs système professionnels. Aujourd'hui, la plupart du développement de code FAH est fait par des programmeurs professionnels, et avec le temps je l'objectif est que tout cela sera fait de cette façon. Le désir de commencer avec une de base de code propre ouvre la voie à de nouveaux projets, tels que le code du serveur v5, la deuxième génération de code GPU (GPU2), la deuxième génération de code SMP (SMP2), le nouveau client (client v7 en chantier), qui ont été développés après avoir fait table rase.

Il ya quelques différences dans la façon dont les donateurs verront les fruits de ces efforts. J'ai constaté que tandis que les programmeurs écrivent du code plus propre (beaucoup plus modulaire et systématique et maintenable), le développement de code est généralement plus lent. Là où le groupe scientifique peut couramment faire des modifications en un mois, les programmeurs professionnels peuvent avoir besoin de 2 ou 3. Ce que nous apporte ce temps supplémentaire est un code plus propre, sans bricolage, et un plan de viabilité à long terme (code propre, bien documenté, méthodes de programmation de haut niveau, etc...) Certains projets sont encore effectués par le personnel scientifique (par exemple le Dr Peter Kasson continue à faire de grandes choses avec le client SMP ainsi que la préparation au passage à SMP2), je m'attends à ce que progressivement tout cela soit fait par des programmeurs.

De manière analogue, l'administration système a été confiée à un groupe professionnel à l'Université Stanford. De même, ils sont plus prudents et méthodiques, mais plus lents à réagir pour cette raison. Mon espoir est que tant par le remplacement de notre vieux matériel que grâce à une installation propre du code du serveur v5, les pannes de serveurs obligeant à les redémarrer devraient être grandement réduites. Ce changement d'infrastructure a été beaucoup plus lent que je l'espérais, en partie du fait des procédures utilisées par l'équipe de sysadmin pour éviter les astuces des hackers et garder un système bien organisé, un environnement uniforme entre tous les serveurs (par exemple les scripts et l'automatisation des tâches courantes).

Une importante bonne nouvelle, c'est que les gens que nous avons recrutés sont très bons. Je suis très heureux de travailler avec certains programmeurs très qualifiés, y compris Peter Eastman, Mark Friedrichs, et Chris Bruns (GPU2/OpenMM code), Scott Legrand et Mike Houston (contacts chez NVIDIA et ATI, respectivement, pour ce qui touche GPU2), Joe Coffland et ses collègues (serveur v5, Core Protomol, coeur Desmond/SMP2, client v7). l'administration système est désormais faite de façon professionnelle, en passant par groupe admin de Miles Davis à Stanford Informatique. En outre, depuis qu'elle a acquis l'expérience du support utilisateur, Terri Fedelin (qui fait des droits administration de l'Université pour moi personnellement) a également aidé au tri des questions sur le forum.

Où en sommes-nous? Une grande partie de leur travail se fait en coulisses et nous ne parlons généralement des grandes nouveautés que lorsque nous sommes prêts à les mettre en oeuvre, mais si vous êtes curieux, vous pouvez voir certaines d'entre elles, telles que le suivi du développement de GPU2 à travers le projet OpenMM (http :/ / simtk.org / home / OpenMM) et le noyau Gromacs/SMP2 via le cvs http://gromacs.org (regardez les mises à jour concernant les threads, car ce qui est nouveau dans SMP2 est l'utilisation de threads au lieu de MPI). Vous pouvez également suivre un peu plus les détails Nitty Gritty sur mon flux Twitter (http://twitter.com/vijaypande), où je prévois d'essayer de donner plus d'informations au jour le jour, bien que dans une forme plus simple (et moins grammaticalement correcte); l'espoir ici est d'essayer d'avoir des mises à jour plus fréquentes, même si elles sont plus petites et plus simples.

Comme la base du code GPU2 est mûre en termes de fonctionnalités, son développement a principalement consisté en corrections de bugs, ce qui est une bonne chose. SMP2 a été testé en interne pendant un certain temps et je m'attends à ce que cela prenne encore quelques semaines. Le principal problème est d'essayer de nous assurer d'obtenir une bonne évolutivité avec des solutions basées sur les threads, en supprimant des goulets d'étranglement, etc... L'initiative SMP2 conduit à deux noyaux différents, un pour le code de Desmond de DE Shaw recherche et un autre pour une variante Gromacs (une variante du noyau A4). Nous avons testé les deux en cpu simple-core (le noyau A4 Gromacs est une version simple core de ce qui deviendra SMP2) et nous espérons sortir dans une semaine ou deux un ensemble de versions simples core de Desmond. Si ceux-ci semblent bons, des versions multi-coeurs via les threads (pas MPI) suivront.

Le déploiement du système v5 continue, avec l'objectif d'avoir une infrastructure v5 (mis en place par les nouveauxadministrateurs système) en parallèle avec l'actuelle, et que l'équipe scientifique migre les nouveaux projets sur la nouvelle infrastructure. Le code v5 est en test depuis un certain temps et nous attendons un des serveurs GPU pour migrer cette semaine, pour atteindre un rythme de migration d'un ou deux serveurs par semaine. Le nouveau code ne plante pas de la même façon que les V3/V4 (blocage sous forte charge et nécessité de "tuer" le processus) et nous en attendons donc un comportement beaucoup plus robuste. En outre, Joe Coffland a été génial en ce qui concerne la réponse aux changements de code et corrections de bugs.

Ainsi, le résultat de cette nouvelle organisation est que les donateurs verront probablement un logiciel plus mature, ce qui signifie aussi des mises à jour moins fréquentes, à la fois parce que le nouveau modèle le permet (un grand nombre de problèmes sont simplifiés par le code plus propre) et parce que les révisions bénéficient de plus de contrôle qualité et d'essais en interne ainsi que de méthodes de programmation plus rigoureuses.

Le résultat à long terme pour FAH est un logiciel meilleur et plus durable. Il faut du temps pour le faire, mais sur la base des résultats obtenus jusqu'à présent (par exemple GPU2 vs GPU), je pense qu'il valait la peine d'attendre (mais nous avons encore du chemin à faire avant que nous puissions voir tous les fruits de ce travail).


De rien, c'est cadeau. :lu

M'enfin... il y a peut-être (sûrement) des trucs à corriger ou améliorer... ;)
____________________
Rien n'est plus provisoire que les certitudes
(et encore... je m'demande...)

   
Le 05/07/2012 à 11h49

Administrateur

Groupe: Administrateur

Inscrit le: 04/06/2009
Messages: 622
:D Merki ! toTOW va être content :)

MSN    
1 Utilisateur en ligne : 0 Administrateur, 0 Modérateur, 0 Membre et 1 Visiteur
Utilisateur en ligne : Aucun membre connecté
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie