gvallee a écrit 104 commentaires

Tu as raison, j'ai un peu trop simplifie... Pour completer un peu, a priori ils font ca pour que le PowerPC soit utilise uniquement dans son role initial, i.e. servir de front-end pour les coeurs Cell. Actuellement, il semble que le probleme est que les utilisateurs ont commence a utilise le PowerPC pour faire du calcul, ce qui pose pas mal de probleme. En mettant un Opteron devant le Cell, ils esperent que les gens vont arretes de faire cela. Du coup, les utilisateurs devraient reutiliser le SDK pour le Cell comme IBM le voudrait (le code arrivant sur le PPC est donc compile avec le compilo d'IBM et execute uniquement des taches de base pour les SPEs).

Enfin c'est ce que j'ai retenu des differentes discussions que j'ai pu avoir avec des gens utilisant le Cell, je ne suis pas non plus specialiste, je peux me tromper. :-)

Reste qu'a mon avis ca va toujours etre un cauchemar a programmer dans pas mal de cas. Par exemple a cause du bus entre les coeurs est tres rapide mais le lien entre le bus et les coeurs eux-memes sont beaucoup plus lents (je ne souviens pas des chiffres exacts), creant de gros problemes lorsque l'on deplace pas mal de donnees entre les coeurs. En meme temps ca reste une architecture interessante. :-)

Le Cell peut etre associe a d'autres processeurs ; son architecture ne fait pas qu'il doit etre obligatoirement associe au PowerPC. D'ailleurs une version associee a un Opteron a ete annoncee : http://www-03.ibm.com/press/us/en/pressrelease/20210.wss

De toute facon, les machines petaflop (enfin plutot les futures machines petaflop) atteindront le petaflop en puissance crete, non pas en puissance soutenue. En principe les applications arrivent a utiliser 60% au maximum de la performance crete (souvent bien moins que ca en fait), en fonction de leurs algorithmes et leur mise en oeuvre.

Donc pour completer ce que tu dis : aujourd'hui aucune application ne peut utiliser 100% de la puissance d'une machine petaflop.

Cray n'est pas uniquement a citer pour des raisons historiques, l'une des premieres machines a atteindre le petaflop (performance crete) sera une machine Cray:
http://www.hpcwire.com/hpc/701937.html

Tres bon justificatif. :-)

Une precision mineure tout de meme : ce n'est pas "Chape" de Cray mais "Chapel".
http://chapel.cs.washington.edu/

Au passage, un autre langage interessant : Global Arrays.
http://www.emsl.pnl.gov/docs/global/

> J'ai pris le rpm direct depuis la sarge et modifié pour ajouter mes
> patchs.

Qu'est ce que tu racontes? Prendre des RPMs depuis la Sarge? Ca n'a aucun sens?

> J'ai également eu a re-modifier un autre .deb récemment, même
> merde, là encore les scripts qui bugs sans erreurs explicites.
> (en fait j'ai découvert après coup que les macros venaient de la
> version n+1 et étaient incompatible, tout du refaire la main)

Quelles macros, version +1 de quoi? tout ce que tu dis n'a aucun sens dans le monde Debian. Encore une fois ca resemble a 100% a un discour pour la construction de RPMs, pas de .deb. Je reste donc sur ma premiere impression : tu essaies de faire avec les .deb ce que tu as l'habitude de faire avec les RPMs et oh surprise! et bien ca n'est pas pareil et du coup ca ne marche pas!
Je veux bien que tu aies eu des problemes mais franchement la soit tu baratines soit tu t'exprimes vraiment mal. Bref, fais quelque chose!

> Pour avoir bouffé de votre .deb méchamment, avoir fait de même
> avec les rpm, je peux dire que comme fait mandriva, c'est vraiment
> supérieur !

Superieur en quoi? moi aussi je "me bouffe des .deb et des spec files" tous les jours, les deux ont leurs avantages et leurs inconvenients. Donc deux solutions: (i) tu expliques clairement ton probleme et la discussion est possible, (ii) tu arretes de gueuler comme un putois a dire des conneries (tu as vu je sais m'exprimer avec le meme genre de langage que toi).

> Les macros sont explicites, on peux facilement contourner et porter
> vers redhat (déjà fait pour vim par exemple).
> Les spec file sont clair, inclus dans le src.rpm.

Encore une fois ce que tu dis n'a pas reellement de sens dans le monde des paquets debian. De plus, pour ton information, il existe aussi des paquets source sous Debian qui te permettent de recreer un paquet en une commande.
Ensuite oui pour les RPMs, il y a un seul fichier de description du paquets et de la methode de construction du paquet, le .spec. Oui ce fichier est clair mais ca a aussi des mauvais cote. Un exemple : code crade pour contourner un probleme de Makefile, mis en oeuvre par les personnes ayant repris un projet, du coup les Makefile n'etaient pas corriges et les commandes pour creer le paquet (et donc compiler le logiciel) se trouvait de plus en plus dans le fichier spec et non pas dans le Makefile du projet meme (experience vecue).
Avec les .deb il y a trois fichiers pour chaques paquets (fournis par le paquet source) : un pour la description du paquet (control), un pour construire le paquet (rules) et un pour le changelog. Moi ca me parrait raisonnable et tu sais quoi? et bien ca fait gagner pas mal de temps pour creer un nouveau paquets si tout ca est bien fait car dans la plus part des cas tu as juste a faire des modifications mineurs d'un de ces fichiers.
Donc tu vois, les deux ont leurs avantages. Etonnant non? (attention reference, je te laisse trouver a qui). En plus si le logiciel de base est bien concu, le fichier qui decris comment construire le paquet fait juste appel a des cibles du Makefile du logiciel dont tu veux creer un paquet.

Alors si tu veux patcher un .deb, tu as au moins deux approches differentes : (i) tu bosses avec l'equipe de dev du logiciel (pareil que pour les RPMs), (ii) tu recuperes le paquet source et tu fais des modifs que tu gardes chez toi (comme pour les paquets RPMs a nouveau).

> Et surtout pas besoin de se prendre le chou avec les
> dépendances, rpm s'en charge tout seul (via quelques macros)

Encore une fois tu parles de quoi la? La declaration des dependances pour les paquets Debian est vraiment similaire a celle des paquets RPM. Je ne comprends pas... quelqu'un dans l'assistance peut traduire? En plus avec les .deb on peut creer des dependences de maniere legerement plus fine que pour les RPMs (difference qui dans la majorite des cas est peu importante).

Personnellement, je fais des RPMs et .deb et je suis arrive a une seule conclusion : les deux ont leurs avantages et leurs inconvenients et je peux argumenter sur le sujet (comme tu peux le voir dans ce message). Peux-tu argumenter tes propos au lieu d'agresser tout le monde?

Par contre je prefere toujours un peu apt a yum par exemple mais c'est une autre histoire.

C'etait pas le moment cette nuit de dire des trucs pareils sur un sujet que je connais un peu.

Tu n'aurais pas essaye de faire des .deb avec tes habitudes de creation de RPM? Parce que je fais aussi les deux, RPM et .deb, et je n'ai JAMAIS rellement eu tes problemes (y compris pour les paquets pour le noyau).
Oui les .deb demandent plus de temps et d'efforts pour creer des paquets propres. Donc pour moi dire que les .deb "c'est VRAIMENT DE LA MERDE" ca prouve plutot ton incompetence qu'autre chose. De la meme maniere que si tu avais dis que les RPMs sont de la merde.

A mon avis ce n'est pas si simple... Seuls les impots conciderent que tu es resident d'un pays si tu y passes plus de 6 mois (bien qu'aux US, je crois me souvenir que c'est une duree differente). Pour l'immigration c'est autre chose : tu peux vivre aux US pendant des annees mais a cause du type de visa que tu as, tu dois toujours officiellement avoir une adresse en France.
Si en plus on parle de "resident permanent", c'est encore different : tu as besoin d'une carte verte, tous les autres visas ne sont pas concideres comme residents permanents par l'immigration.

Donc attention avec les regles d'immigration : si tu rentres aux US comme touriste mais que pendant ton sejour aux US tu travailles en etant paye par Google, je ne suis pas certain que l'immigration accepte ca. Pour les impots ca devrait aller.

Juste une petite remarque "USB video camera devices" ne veut pas forcement dire "webcam USB". Je pense que la traduction n'est pas assez precise ; "USB video camera devices" inclus aussi je pense certains camescopes par exemple.
Apres je ne sais pas si les tuners TV sont inclus dans ce groupe...

Mes 2 cents...

Synaptic, c'est pas mal pour une machine de bureau avec notamment le classement des paquets pas theme. Ca rend la gestion des paquets simple a travers une interface graphique (pour ceux qui aiment).

Pour les machines distantes/serveurs, en particulier a travers ssh, c'est pas trop ca et puis "apt-get install synaptic" -> "Après dépaquetage, 11.6Mo d'espace disque supplémentaires seront utilisés."

aptitude quant a lui passe tres bien a travers ssh (mode texte), l'ergonomie est au final assez proche de synaptic mais en mode texte.

Alors oui je suis d'accord que Synaptic est bien fait mais c'est loin de pouvoir "remplacer" apt ou aptitude a mon avis, a part peut-etre pour les gens qui ne gere que leur machine sans avoir a se soucier d'administration a distance.

Mon commentaire peu inutile du matin. :-)

Plus precisement un SSI cree l'illusion de disposer un SMP (machine unique avec plusieurs processeurs, une seule memoire) a partir d'un cluster, cela inclus entre autre creer une memoire partagee entre les noeuds du cluster par voie logicielle.
SSS en revanche, qui n'est pas un acronyme "officiel", vise plutot a analyser et etre les fonctionnalites classiques d'un cluster, non SSI, : comment gerer sur un tres grand nombre de noeuds des applications paralleles (type MPI), un systeme de gestion de taches, etc.

Juste une question : comment OSCAR est suppose "profiter des experimentations exterieures" si personne ne vient nous voir? Je suis vraiment surpris de voir ce type de reaction... est-on suppose connaitre tous les projets? faire seul tout le travail de veille technologique et d'integration? (oui j'en rajoute un peu)

Serieusement, contactez nous (nous on a deja essaye de notre cote, pour le moment ca n'a pas donne grand chose pour diverses raisons) ; IGGI semble regrouper de bonnes idees, de bons composants. Vous connaissez les details de CLIC, Kadeploy et divers autres projets, pas nous ; mettez nous sur la piste, discutons et voyons ce que l'on peut faire. Je t'envoie un message prive pour te faire parvenir mon adresse email.

Je connais Kadeploy et apprecie son algo pour le deploiement parallele. Par contre dire que OSCAR n'a pas evoluer depuis la version c'est un peu extremiste a mon avis. Par exemple voici quelques points qui me semblent uniques dans OSCAR :
- abstraction des paquets binaires qui permettent de supporter par exemple simplement les RPMs et les Deb.
- modularisation de l'architecture pour simplifier les projets tiers tels que SSI-OSCAR.
Ensuite peut-etre que vis-a-vis de tes besoins, OSCAR n'a pas evolue, mais quels sont-ils?

Permets moi egalement d'apporter quelques precisions supplementaires:
- pour ce qui est de la doc, encore une fois je pense que tu ne connais pas assez bien le projet : OSCAR, de part son design (c'est clair lorsque l'on utilise la GUI), permet la definition du cluster etape par etape et chaque etape est documentee. Par contre, il est vrai que si l'on cherche a sortir de cette installation par defaut, ce n'est pas simple. Donc si tu voulais dire souplesse et adaptation au niveau de l'architecture du cluster, oui OSCAR est tres limite.
- pour l'autoconfiguration, desole mais je ne vois rien sur ce point que OSCAR ne permet pas de faire.

Mais encore une fois, je ne cherche pas a prouver que OSCAR est meilleur. Mais certaines choses que tu as affirme etaient incorrectes (32-64 bits, doc par exemple), je me devais de reagir. Ensuite comme je l'ai dis, et comme tu le dis toi-meme, chaque projet a ses points forts. D'ailleurs il y a quelque temps, j'avais commence a regarder comment integrer kadeploy dans OSCAR (ce qui n'a rien d'une idee stupide vu le design de OSCAR), j'avais discute avec les developpeurs du projet, etc. Malheureusement, cela n'a pas pu aboutir par manque de temps de ma part.
D'ailleurs une partie non negligeable des developpeurs de OSCAR sont des chercheurs, OSCAR etant un simple outil que l'on utilise pour effectuer/diffuser nos projets de recherche. On est donc ouvert a toutes propositions/discussions (ce que j'avais fais a un certain moment en discutant avec les Grenoblois de OAR et Kadeploy); tu es le bienvenu pour soumettre tes idees et commentaires.

Plutot que de faire des "constats" sur un site comme celui-ci on devrait peut-etre plutot essayer de discuter ensemble, avoir des briques de base communes qui nous permettrait de federer les efforts et d'avancer plus vite sur les points qui seraient plus novateurs. On a commence a faire cela avec l'equipe de Kerrighed (bon d'accord ce cas est fausse je suis un ancien de l'equipe Kerrighed) et cela a ete tres benefique pour les deux projets, je pense. Peut-etre est-il temps de faire la meme chose entre OSCAR et IGGI (vraie question ouverte)?

Je me reponds a moi meme car ce que j'ai dis sur OAR est faux, je n'ai jamais eu de probleme avec, je confondais avec un autre projet.

Pour information, OSCAR propose certaines de ces fonctionnalites :
- auto-configuration via un seul script (serveur et nodes) : il est possible avec la version actuellement en developpement d'ecrire des fichiers de configuration decrivant la grappe et ensuite d'utiliser le ligne de commande pour que tout soit fait automatiquement.
- monitoring via ganglia : OSCAR fournit Ganglia par defaut
- possibilité de benchmark : pour le moment on se refuse d'inclure des benchmarks car on doit faire face a la question classique de savoir comment fournir un bench optimise pour la plate-forme (question non triviale), vu que la majorite des benchmarks HPC actuels necessitent une optimisation des parametres.
- 2 modes de duplication parrallele de nodes : OSCAR dispose de rsync classique, multicast et egalement bittorent.
- installation en parrallele de RPM via urpmi en mode parrallele : OSCAR propose C3 et le support de yum, il est donc egalement tout a fait possible de mettre a jour des RPMs en parallele (il sera egalement possible de faire la meme chose avec C3 et apt pour la version Debian).
- module BLCR pour checkpoint restart pour les applications LAM : disponible via HA-OSCAR (tolerance aux fautes, les puristes du HPC ne veulent pas encore, malheureusement de mecanismes de checkpoint/restart directement inclus dans OSCAR).
- ordonanceur OAR (MAUI distribué dans OSCAR n'est plus sous licence GPL) : la derniere fois que j'ai teste OAR, c'etait tres loin de compiler sur toutes les distribs et cela manquait un peu de stabilite (c'etait il y a longtemps). OSCAR fournit egalement SGE.
- doc complete (plus de 120 pages) : on propose la doc utilisateur et developpeur (si tu veux compter le nombre de pages, je pense qu'il y en a aussi facilement 120), je ne vois pas ce que tu reproches a OSCAR sur ce plan.
- OSCAR supporte _deja_ le 32 et 64 bits (mais le support IA64 a ete mis un peu de cote pour OSCAR 5.0).

Bref, tu denigres un peu OSCAR mais ce que tu affirmes est loin d'etre vrai. Je n'ai absolument rien contre IGGI (et presente de reels avantages), il y a de la place pour tout le monde, mais s'il te plait n'affirme pas des choses fausses sur un projets que visiblement tu ne connais pas bien.

Amicalement,

Juste la signification a propos des acronymes, cela te permettra peut-etre de trouver plus d'informations :
- SSI : "Single System Image" ou encore "Systeme a Image Unique", l'idee generale (vraiment generale!)etant de creer l'illusion qu'un cluster est une machine multi-processeurs
- SSS : "Scalable System Software", cette fois l'idee generale de ce projet est de se concentrer sur l'aspect grande taille de certains systemes (comment soumettre des applications sur des milliers de machines, comme administrer le systeme, etc.)
- HA : "High Availability" ou encore "haute disponibilite", l'idee generaleest dans ce cas de tolerer les fautes materielles et logicielles pour en limiter l'impact sur l'execution des applications. C'est particulierement important pour les systemes de grande taille ou des defaillances ont lieu tous les jours.

Voila j'espere que cela te sera utile. :-)

Pour info HP a arrete de supporter OpenSSI, Bruce Walker et toute son equipe travaillent sur d'autres projets.

En fait, pour ce que j'ai pu lire du code de Xen et de OpenMOSIX, les codes sont differents. Les SSI et la virtualisation, bien que ayant des idees communes (creer des abstractions transparentes aux applications et environnements d'execution), les mises en oeuvres et les concepts sont differents la plus part du temps. Par exemple, Xen tente de tirer profit de choses telles que les technologies Intel-VT and AMD-V (virtualisation au niveau hardware) qui importe peu aux SSI (au moins jusque maintenant).
Autre difference Xen gere la memoire a la granularite d'une machine virtuelle, pas d'un processus, ce sont donc des choses differentes (et au final plus simple a mon sens dans le cas d'une machine virtuelle).

Bref, d'apres moi le seul point commun est que les deux codes sont des codes "noyau" et necessitent donc le meme genre de competences.

Apres cela, je pense que beaucoup de gens font du Xen ou Xen-like parce que c'est a la mode et qu'il y a de l'argent a recuperer facilement; chose plus difficile a faire actuellement avec un SSI.

Bien vu j'avais oublie le coup Thunderbird... :-)

> Toutes les grappes gigantesques sont plutôt là parce que les américains jouent à qui aura la plus grosse (grappe), IBM et Intel notamment.

Tu veux plutot dire IBM et Cray, non? L'une des prochaines machines peta-scale sera une machine Cray XT3, fondee sur des processeurs AMD:
http://www.hpcwire.com/hpc/701937.html

Je metterais un bemol a que tu dis Brice. La grille est a la mode en Europe et en Chine (cf. les differents projets Europeens, notamment le projet XtreemOS - oui mon avis n'est pas neutre :-), pas vraiment aux US (en dehors de TeraGrid).

Pour revenir aux calculateurs de grandes tailles et a l'execution de vraies applications, le principal probleme actuellement, que ce soit avec les BG ou les Cray (XT3 par exemple), est que l'OS des noeuds de calcul n'est pas Linux mais des noyaux "legers" et proprietaires (catamount dans le cas des machines Cray). Les noeuds de service tournent souvent avec le noyau Linux.
Du coup, les applications developpees pour ces machines (par exemple celles developpees dans les labos DoE aux US) sont peu portables mais passent assez bien a l'echelle et ne necessitent pas Linux actuellement. C'est un petit monde a part mais pour lequel il y a encore pas mal de recherche, mais c'est vrai que ca concerne quasi uniquement les US, meme si les BG semblent se vendre assez bien.

Au passage, concernant ta remarque sur l'optimisation de Linpack, tu as tout a fait raison, et c'est d'ailleurs un probleme recurrent (comme comparer entre eux les differents resultats provenant d'architectures pour le moins differentes). Je crois qu'ils travaillent sur le probleme dans le cadre de l'effort "HPC Challenge (HPCC)".

Hop quelques liens :
Cray XT3 : http://www.cray.com/products/xt3/specifications.html
IBM BG : http://www-03.ibm.com/servers/deepcomputing/bluegene_glance.(...)
HPCC : http://icl.cs.utk.edu/hpcc/
Projets Europeens autour de la grille : http://cordis.europa.eu/ist/grids/index.html
xtreemOS : https://www.xtreemos.org/

A noter que certains patchs pour le client Lustre ont ete integres dans le noyau et que les dev de Lustre prevoient de pouvoir faire un client sans avoir a patcher le noyau dans un futur proche.

Si mes souvenirs sont bons, c'est la premiere chose que fait le handler (desole le mot equivalent francais ne me revient pas) d'exception de faute de page (page fault exception handler). Le code du handler est do_page_fault() (fichier fault.c) du noyau et si tu veux une description plus detaillee sans lire le code, le chapitre "Process Address Space" du livre "Understanding the Linux Kernel" est assez bien fait.

Pour information, l'automodification de code est technique connue et utilisee depuis longtemps... aucun rapport avec l'IA.

Je ne vois pas le rapport avec les machines virtuelles ; c'est plutot du code qui se modifie lui-meme, non?