Sytoka Modon a écrit 4544 commentaires

A mon avis, pour avoir réagit en premier, je pense qu'il serait bien et temps de prendre un bouquin sur Perl ;-)

Tu rajoutes une bête loop et cela devrait faire l'affaire…

for my $file (@ARGV) ....


Bref, ça commence à sentir le roussi pour le Fortran. C'est dommage car c'est un excellent langage, mais j'ai l'impression que les temps sont durs pour les langages non généralistes.

Je ne serais pas aussi dur. Cela fait des années et des années que 99% des personnes pensent que le Fortran est mort et il est toujours la. Il a fortement évolué, bien plus de le C par exemple… Il y a 15 ans, c'était impossible de faire du Fortran sans avoir un compilateur privateur, de nos jours, gfortran s'en sors pas si mal sur de nombreux code (même si le résultat n'est pas aussi rapide qu'avec ifort). Pour les Coarrays, cela avance via OpenCoarray (http://opencoarrays.org/) mais il faut bien voir que l'objectif est d'avoir une manière simple de faire du parallèle intégré dans le langage donc on ne sera pas plus rapide qu'un code hybride aux petits oignons OpenMP/MPI… Il n'y a pas de magie derrière les Coarray ;-)

De notre coté, on utilise de plus en plus hdf5 et netcdf4 parallel (MPI). Il y a des gains énorme à basculer la dessus pour les entrées sorties.

Je crois qu'on est d'accord sur tout en pratique ;-) Je suis d'accord que l'architecture POWER est bien mais l'histoire montre cet argument ne suffit pas, surtout si le prix est d'un ordre de 2. Même Intel a du enterrer son Itanium, c'est pour dire. Mais cette guerre avec AMD fait que leur Xeon arrache désormais en puissance !!

Sinon, je parlais du prix marché DELL car quand on attaque ce genre de machine, on a souvent un marché. Je n'ai pas parlé de marché IBM car un, on n'en a pas et deux, dans nos derniers appels d'offre, IBM ne faisait pas de cadeaux ;-( Ceci dis, je suis curieux de voir ce que cela va donner car la réaction d'Intel est toujours intéressante.

La FFTW est géniale mais va l'utiliser sur 10_000 coeurs ;-) La version MPI a encore des sacrés progrès à faire et il faut surtout qu'un mathématicien trouve trouve une méthode géniale pour paralléliser la FFT sur un cluster ! Nvidia et Intel cherche aussi (Nvidia en a vraiment besoin pour ses GPU, idem pour Intel avec les Xeon Phi) mais pour le moment, je n'ai rien vu de génial.

Les langages fonctionnels seront plus rapide que le C/C++/Fortran le jour où les compilateurs auront une vision globale du code meilleure qu'un bon programmeur

Les compilateurs ont déjà une vision globale, par exemple l'option -ipo de ifort.

IL n'y a pas qu'un problème de compilateur, si tu fais du HPC sur un très grand nombre de cœur, tu mappes ta structure de données sur des tableaux. C'est une des raisons pour lesquelles il faut souvent écrire les codes spécifiquement pour le HPC. Via le bus InfiniBand, tu attaques via ton code hybride MPI/OpenMP tout en adresse (Fortran). Tu minimises toutes les copies. C'est une manière de programmer très différentes d'Erlang qui fait tout l'inverse par exemple ;-)

J'aimerais bien qu'un code Erlang soit plus performant qu'un code Fortran mais en on n'en est pas encore là. Par contre, il est tout à fait possible qu'à moyen terme, du code Erlang (ou équivalent) soit plus facile à concevoir et à maintenir et soit suffisamment performant pour qu'on s'en satisfasse sur les gros clusters HPC ;-)

On se retrouve donc contraint à développer en Fortran ou C/C++

Je rappelle pour ceux qui l'aurait oublié que le Fortran est un langage objet gérant l'héritage simple.

Pour avoir joué il longtemps avec cela, il faut penser à flusher (flush) car les écritures se font en mode block généralement pour aller plus vite donc en général, l'autre programme ne reçoit jamais les données si elles sont petites…

Dans ton cas, je n'ai pas regardé de près ton code. Désolé.

Actuellement, on est sur HP et les stations HP sous GNU/Linux sont de la daube en boite… Un des rares points ou DELL est clairement mieux ;-)

J'ai eu de l'Alpha, du POWER, de l'Itanium… et même du SPARC et du 68000 sous UNIX. A par l'Alpha, les autres ont toujours été trop cher pour un quelconque gain réel. Avec 15k€, j'ai une machine DELL avec 512Go RAM et c'est la RAM qui coûte cher sur ce genre de machine ! Via le marché public de la recherche, on a un DELL R630 avec 16Go RAM a moins de 1kE. Les gros acheteurs ont tous des marchés négociés s'ils ne sont pas trop mauvais.

Ma dernière machine exotique Itanium plantait lamentablement sur un bête 'modprobe 8021q', c'était sur la Suse officielle du constructeur… Ceci dis, je ne suis pas dans le domaine bancaire et Oracle n'a pas mis les pieds chez moi ;-) Le seul domaine ou nous utilisons les machines IBM, ce sont les supercalculateurs Blue Gene de l'IDRIS mais c'est un sacré boulot en terme de ressources humaines pour avoir un code performant dessus.

Concernant ARM, je suis d'accord avec toi, ça avance mais pas aussi vite qu'on pourrait l'espérer. L'embarqué est clairement encore la priorité…

On a joué dans le temps l'architecture Alpha car c'était très proche du PC en pratique. Cela aurait pu marcher si les offres s'étaient maintenu.

A plus de 20kE le ticket d'entrée, je doute que l'offre IBM aille bien loin… C'est pas avec ce genre de ticket qu'on maintient une architecture compétitive face à la puissance du x86. Cf la machine Itanium ou même Intel a du jeter l'éponge. Je crois bien plus à la carte ARM mais il faut effectivement que celle-ci monte encore un peu en puissance mais c'est bien ce qui se passe depuis quelques années…

Car ce n'est un secret pour personne, bigblue cherche à imposer son architecture comme étant une vraie alternative au traditionnel x86.

Enfin, c'est pas gagné ! L'hyperviseur propriétaire, j'aime pas du tout et le prix ? Pour prendre une vrai place, il faut que cela soit au même prix, IBM a toujours été hors de prix. Leur stratégie sur le libre n'a jamais été clair (cf l'affaire OpenOffice par exemple). A mon avis, ils jouent leur survis car même les banques ne doivent plus avoir envie de payer une fortune leurs bécanes.

Pour la virtualisation de milliers de VM, il y a une piste intéressante avec par exemple la machine Moonshot d'HP à base de processeur ARM. Entre l'ARM et le x86, cela va être dur de se maintenir sur un créneau généraliste…

http://www8.hp.com/us/en/products/servers/moonshot/index.html

Il y a quand même une différence entre une taupe (humaine) et une boite noire (automate)…

Dans le monde professionnel, ces portables sans port RJ45, c'est très très chiant… Ça finit chez nous par une quequette USB qui emmerde tout le monde, l'utilisateur en premier !

A noter qu'avec Sympa, il y a aussi la possibilité d'avoir un dossier partagé par liste. Pour faire des petits trucs collaboratifs ou mettre quelques documents de référence, c'est pratique.

Il y a Sympa et Mailman

Sympa est facile a utiliser en pratique même si pas évident à configurer au début !

Effectivement, tout dépend du contexte. Dans mon cas, on a pas mal (trop) de serveur donc R630 garantie 7 ans J+1. Mais étant sur le marché recherche MATINFO3, on a des prix qui ne nous font pas hésiter trop longtemps…

Perso, je pars sur des R630 au moins car ils ont la double alimentation, double disque en RAID1 et l'IPMI qui marche (console SOL). J'ai essayé la gamme en dessous mais c'est quand même bien limité pour un hyperviseur.

Je ne me suis pas occupé du dossier de très prêt, juste participé au plan réseau, aux préconisations et voir après si tout est bien monté. Donc je ne peux pas te dire question coût s'il y a eu surcoût. Ceci dis, notre machine est un exemplaire unique et il n'y aura pas d'autres exemplaires de fabriqué donc pour la boite, cela ne sers à rien non plus de garder le code du pilotage. C'est sur base d'automates Siemens mais c'est le savoir faire qu'ils gardent ;-)

il a juste demandé en plus que les sources lui reviennent, pour faire comme si c'était lui qui avait fait le dév je suppose.

Dans mon labo, on a développé une manip unique au monde. On a demandé a avoir la propriété sur les sources du système de contrôle. La manip est prévu pour marcher au moins 40 ans… On ne veut pas dépendre de la boite qui a fait le développement initial ou tout refaire à zéro un jour. Il est clair cependant qu'on ne dira jamais qu'on a fait nous mêmes les dev ! Par ailleurs, il est clair qu'on poursuivra tant que l'on pourra la collaboration avec la boite qui a fait le code jusque là. C'est juste qu'on trouve normal d'avoir les sources et de pouvoir en faire ce que l'on veut.

Il a passé la modération… L'erreur est humaine ;-)

Personnellement, je félicite l'auteur pour son article.

Vous cherchez une solution OpenSource et vous allez basculer sous TFS… Il y a un point qui m'échappe complètement.

Normalement, un bon serveur implémente normalement CMIS et on peux alors faire de la synchronisation automatique via un protocole normalisé. Exemple http://cmissync.com/

Pourquoi HTTPS ? Parce que les DSI bloquent en entrée sortie tout sauf le 80/443… Donc on encapsule tout dans IP qu'on met dans TCP qu'on enrobe de HTTP, qu'on cache dans TLS.

Mais comme cela n'est pas idéal dans de nombreux cas. On invente quoi ? Le HTTP avec les entêtes binaires…

Allez hop, je file ->[]

Il n'y a pas le logiciel Maarch qui a déjà été fait un peu pour cela ?

http://www.maarch.org

Comme d'habitude, deux solutions :

Personnellement, mon habitude, c'est 'apt-get install' ;-)

Il y a encore des personnes qui monte et gère elle même leur serveur. L'intégration dans les distributions est donc un plus surtout pour un projet qui vise les couches bases.

A par cela, ça a l'air très bien !

mais un seul d'entre eux

J'aimerais savoir comment on peut affirmer une chose pareil alors qu'il y a des centaines de bibliothèques !

Ce framework utilise des modules depuis 2009

J'utilisais déjà des modules avant 2000 en Perl. DBI existait bien avant ces daubes de fonctions mysql* du PHP !

Parfois, je me demande vraiment pourquoi PHP a marché ;-)