Sytoka Modon a écrit 4538 commentaires

> Le libre ne propose pas, la personne constate, et prend ce qui lui
> convient.

C'est pour cela que j'utilise Linux, car j'ai besoin d'avoir xfig et que celui-ci ne tourne pas en natif sous Windows ;-)

Je ne suis pas spécialiste mais un des problèmes de la virtualisation aujourd'hui est que le matériel n'est pas prévu pour. Au niveau processeur, le changement de contexte coute cher (cela va s'améliorer) et à part le processeur, le reste n'a pas d'instruction de virtualisation. Du coup, si tu laisses un OS invité avoir accès au matériel via le BUS PCI, il est possible pour elle de prendre le contrôle de la machine physique !

Certes, la paravistualisation n'est pas la panacée mais il est /a priori/ plus difficile aujourd'hui de sortir d'un environnement paravirtualisé que virtualisé.

Dans l'avenir, on va aller vers un architecture matériel qui sera je l'espère virtualisable, mais par exemple, au niveau de la carte graphique, pour le moment, il n'y a rien à l'horizon.

Au niveau serveur, le système vserver s'améliore petit à petit et on va arriver au final à un modèle proche de Xen à mon avis.

Xen est vraiment taillé pour les serveurs. Alors oui sous debian, cela marche sans interface graphique et c'est tant mieux. Je n'ai pas X11 sur mes serveurs !

Ensuite vmware n'est pas libre...

Enfin, Xen est bien plus performant car on est en mode paravirtualisé et non virtualisé. Les OS invité ne passe pas par exemple par un BIOS. Il n'y a pas de changement de contexte au niveau du microprocessuers. /a priori/, c'est plus sécurisé d'après cet article :

http://taviso.decsystem.org/virtsec.pdf

En gros, si mes souvenirs sont bons, l'OS invité n'accède pas au matériel (le bus PCI n'est pas virtualisé) et les échanges entre l'OS invité et le dom0 sont limités à un petit nombre d'appel qui sont bien écrit sous Xen.

Sous debian, Xen s'installe et est opérationnel en quelques minutes. Cela marche super bien. J'ai en moyen 6 machines virtuelles par machines physiques. Le plus important, cela ne plante JAMAIS....

Il suffit d'estimer effectivement ce qu'un homme est capable de faire à la minute, par exemple max 20 cliques et de mettre cela dans iptables au niveau du parametre limit. J'ai ce genre de règle en permanence et aucune injection de règle à chaud et cela marche très bien.

Je met surtout cela sur un serveur ssh. Je n'autorise par exemple que 2 ou 3 nouvelles connections par minutes et du coup, je n'ai quasiment plus d'attaque sur ce port...

Oui mais si on prends un générateur de nombre aléatoire auquel on rajoute des pertubations du aux paramêtres internes de la machine, si l'ensemble est bien fait, on devrait être plus aléatoire que le générateur logiciel cablé dans la puce et peu prévisible puisqu'on a quand même la sécurité du générateur logiciel ?

C'est d'ailleurs depuis ce temps là que c'est la mode de coder comme un pied chez Micorsoft ;-)

J'ai du mal à comprendre pourquoi, dans un PC moderne, il n'y ai pas un générateur de nombre aléatoire matériel. Il y a tellement de paramêtre sur un PC que cela devrait être possible d'en faire un truc qui sort des nombres impévisibles...

Il manque aussi les machines des grands groupes pétroliers... Par exemple, Total a des calculateurs à faire rêver plus d'un chercheur. Mais pour des problèmes de communication, il ne veulent pas en parler.

> Et à l'IDRIS, tu peux faire tourner ton job sur 3000 processeurs
> pendant deux jours, parce qu'il te faut des résultats sur 3000
> processeurs, sans que personne ne râle?

Tu obtient a peu près ce que tu demandes, dans la limite de ce qui est possible de donner. Si tu ne demande rien, tu n'as rien... Avoir 100% de la machine pendant deux jours me semble tout à fait réaliste si ton projet et cohérent.

> D'abord, l'IDRIS n'a pas de machines dans le top500, à ma
> connaissance

Exact car la recherche publique française n'est pas la priorité de nos gouvernements actuels. Cela n'empêche que ce sont quand même des bonnes machines.

Je parlais de l'IDRIS mais il y a aussi les machines du CEA qui sont accessibles même si cela est plus difficile... Je connais moins ce que propose l'INRIA.

Dans les grosses fac, il y a aussi parfois des moyens communs qui sont loin d'être nul.

Sauf à travailler sur les performances d'un code utilisant plus de 1000 coeurs et ou MPI donne des signes de faiblesse, il y a de quoi jouer en recherche.

> Tu as accès à l'IDRIS, cool pour toi, mais ça ne change rien à la
> situation des japonais ou américains.

On parle ici de recherche publique. Mon tord a été de donner un exemple un peu franco francais. A ma connaissance, les exemples que tu prends sont parmi les plus mauvais car ce sont les pays ou les chercheurs ont accès à des machines bien plus puissantes qu'en France.

Il serait temps de faire quelques centres Europpéens de calcul sur le modèle de l'IDRIS afin que tout chercheur européen ait ses chances. Je ne pense pas que les politiques puissent prendre sur ce point une quelconque décision mondiale, donc restons à l'échelle européenne.

> Tu fais tourner quel type de jobs à l'IDRIS ? Il s'agit bien de
> recherche en informatique ?

Moi rien car il y a des administrateurs système à l'IDRIS qui font très bien leur boulot et qui n'ont pas besoin de moi. Les chercheurs de mon labo, oui ;-)

Encore une fois et comme le dis le post ci-dessus. Ercit ton projet de recherche et soumet le à l'évaluation. Tu n'auras aucune heure sur une quelconque machine de calcul tant que tu n'auras pas présenté le moindre dossier. Et c'est normal vu le cout de des machines et des ingénieurs qui passent pas mal d'énergie à essayer de les faire tourner au mieux.

> car leurs labos n'ont pas assez de sous pour leur payer les droits
> d'accès.

FAUX.

Mon labo a accès à l'IDRIS et à ma connaissance, cela ne coute RIEN. Enfin, pas vraiment... Il faut faire un dossier scientifique pour obtenir des heures qui tiennent la route et que celui-ci soit jugé correct par le comité de sélection.

Il ne vous reste donc qu'a construire un dossier bien ficelé.

Les clusters, c'est bien mais au niveau des 'belles' machines de type vectoriel ou SMP (Un OS pour toute la machine et de la mémoire partagé), il n'y a quasiment plus de machine. J'ai trouvé en début de liste

15 - HLRB-II - Altix 4700 1.6 GHz - SGI

30 - Earth-Simulator - NEC

En effet, en général, ces 'belles' machines ont une architecture mieux intégrée et donc les programmes parallèles ou vectoriels sont plus performant dessus.

Je me demande en pratique quel est l'efficacité des machines du TOP 500 car je doute qu'il y ai beaucoup de programes qui puissent tirer de la capacité totale d'une seule machine.

Il faudrait en parallèle du TOP 500 des machines faire un TOP 500 des programmes en terme de consommation de GFlops, voire rapporter cela à la capacité de la machine.

En effet, c'est très différent de faire tourner un programme sur 5000 coeurs que de faire tourner 100 programmes sur 50 coeurs. J'ai comme l'impression que ces grosses bécanes du TOP 500 sont surtout positionné sur le second cas d'utilisation.

Pour finir, j'espère que la nouvelle SX9 de NEC va bien marcher car sur le papier, elle semble impressionnante

http://www.geekzone.co.nz/content.asp?contentid=7458

Le rapport de puissance crête entre le premier et le 500ième est constant depuis des années et est quasiment égale à 100.

Au chose constante, en moyenne, la machine numéro 1 se retrouve 500ième 7 ans après.

Oui, c'est elle. D'ailleurs, c'est ainsi qu'elle a été connu ici.

Rien à voir mais Richard Cazenave (UMP) a été battu au dernière élection grace au retour d'Alain Carrignon qui a foutu le bordel et perdu lui-aussi l'élection ;-)

rsync utilise de manière transparente ssh si tu passes par le réseau donc il n'y a aucun soucis de flux avec ce logiciel.

Que l'INRIA a les moyens de le tester en grandeur nature sur un grosse machine ;-)

Il y a un problème avec les calculs sur les nombres flottants. Généralement, il y a des impasses de faites sur les cas particuliers qui font qu'un compilateurs va plus vite que l'autre.

J'avais lu quelques part que ifort ne respectait pas les règles 'IEEE Floating point exception' et que les respecter coutait très chère en temps de calcul.

Donc au niveau du bench annoncé, il faut voir ce qui est réellement calculé et dans quel condition.

D'après SGI, un programme OpenMP s'écroule avant 100 coeurs et un programme MPI s'écroule au dela de 1000 coeur en règle général et indépendanment du langage.

Ici le problème est d'arriver à écrire un programme très fortement parallèle qui ne passe pas son temps en communication. C'est donc plus un problème d'architecture matérielle et logicielle que de programmation pour commencer.

SGI propose d nouveau Rad-Hat ou Suse...Mais je suis d'accord, c'est un point de détail. Les debian n'ont plus ne tournent pas avec le noyau 'Linus'. L'important est qu'il est possible de reprendre le noyau Suse avec les optimisations SGI pour les remettre sur une autre distribution. Et cela n'a rien d'exceptionnel à faire puisque c'est ce que font les distributions entre-elles depuis longtemps.

Je veux bien mais Lisp -> non merci. Déjà ce n'est pas toujours facile de lire le code d'un thésard alors en LISP, je n'y crois pas.

Pour Haskell et OCaml, j'aime bien mais je ne suis pas sur qu'il soit facile d'y rentrer dedans si on n'a pas fait un peu de cours d'informatique sur ce type de langage. Or, à par en math appli, les étudiants n'ont en général aucune notion d'informatique au niveau des langages fonctionnels.

Enfin et surtout, si tu vas sur les grosses machines de type IDRIS (Calculateur vectoriel NEC, cluster superscalaire IBM, SMP avec BUS NUMA performant SGI...) tu vas pleurer avec les langages que tu proposes... Tous les outils tournent autour du C, C++ et Fortran et si tu n'utilises pas les bibliothèques de la machine, ton code va se trainer.

Dans le futur, un code scientifique non parallèle est à mon avis un code mort. Il faut donc avoir un langage qui utilise au mieux l'architecture d'une machine fortement parallèle. Selon SGI, très peu de code sont performant au dela de la barrière des 1000 coeurs...

C'est peut être cet aspect la qui va faire bouger les choses d'un point de vue langage.

Je n'ai jamais dis que le Fortran est la panacée. J'ouvre le débat et je le défend contre des exemples pourris qui ont trente ans d'age. C'est différent. J'ai fait du Fortran et cela m'a bien fait chier au début mais il faut avouer que le langage est bien plus lisible et plus intéressant qu'on ne le pense au premier abord.

Ensuite, je suis preneur de langage plus adapté pour faire du numérique. J'avais trouvé Sather avec lequel je m'amusais bien mais il est mort.

Le problème, comme je l'ai dis juste au dessous, c'est que ce bout de code n'est absolument representatif d'un code Fortran moderne et ne devrait même plus compilé ainsi.

D'ailleurs, un code en F77 ne compilera plus sur un compilateur F2003 car le langage a éliminé pas mal de structure aujourd'hui obsolète. Ce type de structure avait une raison à l'époque ou elles ont été écrites mais ne devrait plus être donné en exemple pour dénigrer un langage de nos jours.

Un truc très beau des vieux Fortran mais complètement imbitable de nos jours, un vieux programme Fortran peut être écrit sans espace ! On colle tout ! L'intérêt se comprends si on a utilisé un tant soit peu les cartes perforées (ce qui n'est pas mon cas). Le F90 a du être compatible avec cette contrainte. Essayez d'écrire un langage de programmation sans séparateur... Bon courage.

Lorsqu'on parle du C++, on ne parle jamais du C++ des années 80 qui ne supportait que l'héritage simple...

Je ne parle pas non plus du Fortran 77 et de ses COMMON... Tout cela est maintenant dépassé.

Lorsque je parle du Fortran, j'évoque la dernière version, F98 (qui n'a pas vraiment d'existence légale = F95 + quelques extensions), voire du F2003 qui supporte l'héritage simple (alors que le C ne le fait pas !).

Fortran, c'est autre chose qu'une version du langage qui a plus de 30 ans aujourd'hui. Le grand ménage a été réalisé avec F90, cela commence quand même à faire...

Ce que tu présentes est du vieux Fortran et même si je n'ai pas essayer, ne devrait pas marcher sur un compilateur d'aujourd'hui.

Avec les derniers Fortran, tu es obligé de déclarer toutes les variables. Il n'y a plus de variable implcite. Enfin, avec un drapeua du compilateur, tu peux mais c'est à tes risques et périls...

A ma connaissance non ! Le := c'est du coté de Pascal et Ada. Même si les dernières version s'inspire de l'Ada (forcément, il y a des membres qui sont à la fois dans le commité Ada et Fortran), l'affectation en Fortran est toujours le =.

Fortran traine (souvent ici) une image de langage vieux et dépassé mais il a su évolué bien plus que d'autres langages qui sont nés après et déjà mort.

Par exemple, le compilateur NAG sais gérer l'allocation dynamique avec ramasses miettes. Avec ce compilateur, il n'est pas nécessaire de déallouer la mémoire et il n'y a pas de fuite mémoire possible (contrairement au C)...

Avec g95, il est aussi possible de suspendre un programme dans un fichier pour le redémarrer plus tard au même point. C'est le compilateur qui gère tout cela. A ma connaissance, gcc pour le C ne fait pas cela.

Cela peut paraitre bête mais un programme écrit en Fortran 98 est à la fois lisible et clair (important pour la sécurité) tout en étant performant.