Sytoka Modon a écrit 4565 commentaires

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é ;-)

En parallèle, il y a un gros boulot sur Jessie pour que tout marche bien ;-)

Ceci dis, la méthode a ses limites. Par exemple, lorsque le paquetage entraîne aussi la libc avec elle vers testing ou plus, personnellement, je ne joue plus ;-)

Je dirais qu'il suffit de faire sa configuration avec un noyau standard puis de faire un 'lsmod' pour avoir la liste des modules utilisées. Ensuite, il faut jouer avec les options du make du noyau pour ne construire que ces modules et dans l'idéal, les mettre en dur et non en module.

Avant scilab n'était pas libre donc n'était pas diffuser dans les distributions. Maintenant, il ne marche plus sur la grande majorité des PC… Je ne sais pas quelle sont les objectifs de l'équipe de développement mais elle aide bien à la diffusion de la plate-forme de python/numpy ;-)