lasher a écrit 2742 commentaires

Tu semble faire un procès d'intention basé sur tes a priori concernant Bové en général

Tu sembles savoir ce que je pense de Bové à ma place. :-)
En l'occurrence, je ne pense rien de ce monsieur. Je ne l'aime pas particulièrement, mais je ne suis pas anti-Bové pour autant.

[troll]
OUAIS !
[/troll]

Je n'ai pas lu jusqu'au bout, mais le côté « les méchantes multinationales menacent le logiciel libre » me fait un peu rire, au moins en ce qui concerne les gros logiciels libres. IBM, Sun, etc., ne m'ont pas l'air d'être tout à fait des acteurs inquiétants pour la vie du libre. Par contre, il existe tout un tas de petites boites qui reprennent du logiciel libre, le dépouillent de ses commentaires chiants (« /* Distribué sous GPL v2 et supérieur */ » par exemple), et repackagent le tout.

Je suis persuadé que les grosses boites (multinationales ou pas) font de même, mais je ne suis pas certain que la proportion par rapport aux plus petites soit plus importante.

Je suis d'accord, Fortran n'est pas parfait pour faire du code parallèle mais la concurrence ?

Ben justement. La concurrence n'est pas meilleure du point de vue langage. Du point de vue des bibliothèques qui vont bien, le C est muni depuis un bout de temps de machins types threads, de bibliothèques à deux niveaux pour les threads, etc.


Pour ce qui est des bibliothèques de base comme BLAS ou Lapack, cela évolue, lentement mais surement.
Mouais. Pour ne prendre qu'une bibliothèque ultra-utilisée, à savoir hypre, peut-être bien que les préconditionneurs sont vraiment géniaux, mais en ce qui concerne les BLAS, ils ont fait un simple f2c d'une implémentation « libre » qui date de ... 1977. Ça fait peur, vraiment.

Pour ce qui est de l'argument des bibliothèques moins bonnes mais qui au moins n'ont pas de bugs, pour ne reprendre que des briques de base (oui, encore les BLAS ;-)), on se retrouve à la fin avec des gens qui ont des algorithmes qui ne passent pas du tout à l'échelle (parce que passer sur 16 ou 32 processeurs n'assure pas du tout que ça pourra passer au-delà), et qui vont être tout content de quadrupler le prix de leur calculateur, en doublant les processeurs ainsi que le système de refroidissement qui va avec, pour finalement obtenir une accélération de ... deux (je parle de machines qui sont déjà équipées d'au moins 16 ou 32 processeurs, justement).

Il faut bien voir que ce ne sont toujours pas des chercheurs en informatique qui font du Fortran mais plutôt des chercheurs du domaine des études faites. Les contrats de recherche qu'ils obtiennent ne sont pas destinés à financer l'amélioration de BLAS par exemple.

Et c'est bien ce que je leur reproche -- silencieusement, parce que le sismologue qui explique qu'il n'est pas informaticien, mais qu'il a codé tout son machin de maillage adaptatif en FORTRAN/MPI a quand même tout mon respect, optimisation ou pas optimisation.

Je sais bien qu'il s'agit de scientifiques autres que des infoteux qui codent tout ça (ce qui explique aussi pourquoi ils font toujours du FORTRAN). N'empêche : embaucher quelqu'un (un ingé de recherche) pour reprendre les bibliothèques fondamentales et les optimiser pour des architectures d'aujourd'hui (parce que le NUMA, avec l'hypertransport et le futur CSI d'Intel, c'est vraiment aujourd'hui) ne serait pas du luxe. D'ailleurs, certains labos l'ont compris, et commencent à prendre des gens compétents dans le domaine de l'optimisation.

Ah ça, c'est bien vrai. Lorsqu'on code en FORTRAN, on a tellement peur de retoucher à certains codes (BLAS, LaPACK, etc) qu'on laisse souvent les vieilles implémentations telles quelles, alors qu'elles ne sont pas forcément programmées dans une optique parallèle.

Et je ne parle pas du combo magique FORTRAN + MPI, avec des gens qui utilisent les I/O asynchrones pour aller plus vite (ce qui est bien) mais en pratique font des MPI_send(...) ; MPI_wait(...); (pas bien, gérer les I/O async en synchrone, faut le faire quand même).

Et justement, FORTRAN permet peut-être la performance, mais dans le cadre du HPC, si t'es pas foutu d'optimiser ton code correctement (et c'est le problème de beaucoup de scientifiques non informaticien, et oui c'est normal, puisqu'ils ne sont pas infoteux), tu perds tellement de temps lors de l'exécution qu'on se demande bien à quoi peuvent servir tous ces mécanismes faits pour rendre le calcul efficace.

On est bien d'accord. Lorsqu'on parle de programmation pour le HPC, rajouter tout un tas de machins à Fortran n'est pas très intéressant. Cela dit, FORTRAN (77|90), malgré toutes les qualités qu'on peut bien vouloir lui trouver, c'est moche. Même le C fait figure de langage moderne à côté.

Le processeur que même IBM veut abandonner car personne n'arrive à le programmer ?

Mmmmh, franchement, autant je vois beaucoup de code F77 et un peu de F90 autour de moi, autant F2003 m'a l'air un chouilla mort-né.

Je ne sais pas sur quoi pompe l'X (mais de ce que j'ai vu, souvent il s'agit du bouquin écrit par le prof qui enseigne la matière, donc bon), mais en tout cas leurs cours sont dispo en ps/pdf sur le site, au moins pour l'info. Et ils sont d'excellente qualité.

« Le RISC, c'est bien. »

http://www.fosdem.org/2007 ?

Moi oui, ça a l'air rigolo ce jeu. :-)

Il est même évident qu'il a pris les noyaux tels quels, au point qu'il a demandé à ce qu'on lui dise quoi faire pour avoir de meilleures perfs. Si personne ne lui répond, on ne peut pas le lui reprocher.

Par contre, si Red Hat reconnaît qu'effectivement il a levé un lièvre, il n'y a plus qu'à s'écraser, non ?

Non, liberal dans le sens américain ne signifie pas la même chose qu'en France. :-)

Si tu ne préinstalles rien, tu empêches une large majorité d'utilisateurs (ie pas informaticiens pour deux sous) d'utiliser leur ordinateur. Un ordinateur sans OS ne sert à rien pour une utilisation individuelle.

L'aide du multi-coeur est très limitée si tu te contentes des applications , tu ne vas pas aller bien loin. Le multi-coeur peut aussi servir pour héberger les différents threads d'un même processus - ou de processus différents, évidemment. C'est d'autant plus vrai que, sous linux, un processus et un threads sont quasiment identiques.

Laisse-moi rire pour le « on n'aurait rien senti ».
Et puis lorsqu'on parle d'optimisation, le « beau code » n'existe pas, justement parce qu'on optimise. Comme quoi hein.

Ben si, en plus de devoir être rédigée en Français pour être légale en France, il y a un certain nombre de choses qu'il t'est interdit d'affirmer dans une licence.

En ce qui concerne les threads, et en particulier l'implémentation des pthreads (au moins sur linux), le problème est surtout la performance affichée de la bibliothèque fournie. Un autre problème est que les pthreads sont des threads système - ce qui dans le cadre de certaines applications se justifie tout à fait, et est même conseillé - mais avoir des bibliothèques de threads en espace utilisateur peut aussi avoir son intérêt (l'idéal étant évidemment l'utilisation de threads à 2 niveaux : système et utilisateur) : lorsqu'il y a beaucoup de changements de contexte à effectuer, une bibliothèque de threads en espace utilisateur ira bien plus vite (pas besoin de faire un appel système, d'appeler l'ordonnanceur, puis de repasser en mode utilisateur). Mais on peut évidemment trouver des exemples où l'appel à des threads système se révèle plus avantageux (par exemple, si de toute manière il faut faire une entrée/sortie, et que le programme a tendance à en faire beaucoup, alors comme de toute manière on passera par le système, autant passer la main à un autre thread/processus en attendant que la donnée soit écrite ou lue).

Pour ce qui est d'architecturer une application multi-thread, je ne suis pas certain que tu aies besoin de bouquins si différents de ceux qui traitent d'algorithmique parallèle en règle générale, et des threads POSIX en particulier. Après, tout est histoire d'implémentation, et le fait est qu'entre celle de Sun et celle de Linux, il y a un monde. Donc même avec un programme portable (car utilisant les pthreads), les performances risquent de beaucoup varier (par exemple, sous Linux, un thread et un processus ne sont pas fondamentalement différents, alors que sous Solaris, qui implémente une bibliothèque hybride, si).

Bof. Ça marche pas mal quand ta boucle possède déjà de très bonnes propriétés de parallélisation. De plus, même sur des cas très étudiés (bibliothèques d'algèbre linéaire, etc.),on a un problème de passage à l'échelle. Alors sur 2 ou 4 coeurs, ce n'est peut-être pas très grave, mais quand il s'agit de faire tourner en parallèle plusieurs threads sur plusieurs processeurs, eux-même multi-core, chaque coeur pouvant être muni d'un dispositif SMT, ça commence à faire beaucoup de niveaux de parallélisme à prendre en compte.

Les implémentations actuelles d'OpenMP sont relativement décevantes, notamment parce que pour des raisons « pratiques », plusieurs synchronisations sont effectuées même lorsqu'on pourrait s'en passer (sauf qu'il faut être humain pour le savoir :-) ).

Donc la parallélisation automatique, sauf dans des cas très précis, je n'y crois pas trop dans un avenir immédiat. Par contre, ajouter à des langages des primitives permettant de gérer correctement les threads serait clairement un plus.

Il y a déjà tout un tas d'articles essayant d'établir un lien direct entre la consommation d'énergie d'une puce CMP (multi-core), SMT (multi-thread, type hyper-threading d'intel, ou bien ce qu'on trouve dans les power 5 et 6 d'IBM), et le mono-core. L'objectif avoué de ces papiers est d'obtenir le meilleur compromis entre performance, consommation électrique, et dissipation thermique. Patience, nous n'en sommes qu'au début. :-)

« Bin pour un serveur avec plein de clients, ce n'est pas compliqué..
Et ces processeurs 2*2 sont plutot prévus pour des serveurs. »

Euh, non. Des stations de travail avec deux processeurs comportant chacun deux coeurs, ça existe déjà, et ne sont clairement pas destinées à faire office de serveurs.

Le côté « serveur » de la chose existe à cause du prix qu'on constate maintenant, mais d'ici un an, lorsqu'Intel et AMD auront sorti leurs octo-coeurs, Apple et Dell proposeront très certainement dans leur catalogue des machines avec 4 coeurs (en fait, Dell en propose déjà).

Concernant les jeux vidéo, ça fait un bail que les programmeurs se posent la question de l'optimisation. Mais si pour un serveur, se contenter du fait que chaque coeur peut faire tourner un ensemble de threads indépendants est suffisant (et encore, ça dépend de l'application), pour les applications de tous les jours, c'est moins évident. Désormais, il va falloir apprendre à programmer correctement avec les threads, et franchement, il y a pas mal de gens dans l'industrie qui ne savent pas le faire efficacement (je ne parle même pas d'optimisation à ce stade).

Donc oui, la question de « comment va-t-on programmer efficacement sur ce genre d'architecture » me semble plutôt pertinente. Surtout si tu prends en compte certains effets « rigolos » qui peuvent se produire si on se retrouve avec une éviction des lignes de cache successives, due à une mauvaise exploitation de la localité dans les threads. Le système pourrait s'en trouver ralenti au lieu d'accéléré.

Bref. Je radote, j'arrête. :-)

« Ce genre d'architecture n'est pas conçue pour des applications grand public, mais pour imiter les grilles de calcul en plus performant. »

Alors, déjà, je suppose que tu voulais parler de grappes ( « clusters » ), parce que les grilles, c'est autre chose. Ensuite, je sais très bien à quoi sert une machine massivement parallèle, et comment on programme pour elle. Quant aux théories pour développer du calcul parallèle ou distribué sur ce genre de machines, je n'y crois pas un instant. Il existe des tas d'algorithme théoriquement géniaux, mais qui supposent qu'on peut avoir accès à tout un tas de mécanismes non moins géniaux (par exemple, lorsque tu effectues un calcul et que tu le parallélise, si tu as besoin de synchroniser une partie de tes calculs à chaque étape de l'algorithme, tu te retrouves avec un GROS goulot d'étranglement.)

De plus, le problème de la localité (utilisation des caches) et de la bande-passante mémoire devient critique dans ce genre d'architectures, et je me répète, très peu de personnes sont capables d'optimiser un programme pour ce genre d'architecture (et c'est aussi valable pour les gros clusters qui existent de ci de là).

Maintenant, si tu reprends ce que je dis, je faisais remarquer que même pour un 2 x 2 coeurs, c'était loin d'être évident.

Intel parle de « tile » (tuile). Et de façon générale, 80 coeurs c'est très bien, c'est le futur, le progrès, tout ça, mais presque personne ne sait programmer efficacement en parallèle. Si on prend le quadcore qu'Intel a sorti récemment, qui comprend 2 x 2 coeurs, avec les caches partagés 2 à 2, j'aimerais bien qu'on m'explique comment on espère optimiser « facilement » des programmes pour ce genre d'architecture. Je n'ose même pas imaginer ce qu'il va en être pour 80 coeu^Wtuiles.

Je te propose de lire « Je suis noir et je n'aime pas le manioc », histoire d'avoir un point de vue « de l'intérieur » (enfin, non, justement, enfin ... lis, tu comprendras :-)) sur la polygamie.