lasher a écrit 2738 commentaires

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.

Euh oui enfin, il se trouve que le livre n'est pas historiquement correct, que l'auteur rajoute tout un tas de détails, et qu'à moins de faire certaines recherches plus ou moins approfondies, il est très difficile de trier ce qui est historiquement exact de ce qui ne l'est pas.

Dieu est Amour. Sa nature, c'est l'amour. Voilà le c½ur de la révélation Judéo-chrétienne.

s/judéo-//

Le dieu des Hébreux est très jaloux, c'est un dieu guerrier, et il ne s'en cache pas (les juifs non plus d'ailleurs). Le dieu de Mahomet n'est pas non plus en reste.

Ce que j'aime beaucoup dans la religion catholique/chrétienne, ce sont les évangiles, qui sont les seuls textes « purs », et qui réforment effectivement la religion juive. Manque de bol, il est difficile de les séparer désormais de tous les textes apocryphes brandis par tous les bigots qui se réclament de la « vraie foi ».

Du coup, la religion (« ce qui relie ») devient encore ce qui sépare les peuples après les avoir rapprochés.

- Dis donc, LinuxFR n'est pas là pour placer des petites annonces, va plutôt sur Lolix ;
- Ouais mais bon, j'ai déjà posté sur Lolix, là c'est pour maximiser mes chances de trouver un bon stagiaire
- salaud d'exploiteur, un stagiaire n'est pas un employé, ni un esclave !
- Euh non mais ... Il va pas être exploité hein, et puis, l'informatique, si tu pratiques pas, t'apprends rien, non plus ;
- Ouais mais tu vas le payer une misère alors que son travail va te rapporter des millions !
- ...

Globalement je suis d'accord avec toi (je suis plutôt BSDiste). Le problème, c'est que si ce genre de licence a une valeur juridique aux USA par exemple, elles n'en ont pas en France (à cause entre autres de la dernière partie en majuscules : tu n'as pas le droit de te dédouaner en disant « je ne fais que fournir le logiciel, je garantis rien », au moins en droit français).

Du coup, même si tout plein de gens gueulent contre la multiplication des licences, ben je commence tout doucement à tendre vers la CeCILL-b (une sorte de licence BSD adaptée au droit français). Surtout qu'il y a une clause permettant de passe le soft directement en GPL quand on sort de la France, si l'on veut (et donc la compatibilité est assurée).