Si j´avais eu plus de place, j´aurais mis comme sous titre au topic : "Il m´en faut une comme ça". explication :

Je ne sais pas si vous en avez entendu parler, mais depuis quelques mois, NVidia propose au téléchargement gratuitement, un framework, nommé CUDA (C for GPU), qui comprend un compilateur et des outils de développement, pour écrire des programme qui tourne sur processeurs G80 (les processeurs des cartes GF 8800). Ça permet aux personnes qui possèdent ces cartes (qui ne sont pas hors de prix) d´utiliser leur puissance phénoménal pour faire du calcul, de manière bien plus simple que les technique de GCGPU (general computing over GPU) qui étaient utilisé jusqu´à là (où on reprogramait des shader, ..., bref, des choses pas du tout pensé pour ça).

Mais là, ils annoncent la sortie d´autre chose :
http://www.nvidia.com/objbject/tesla_gpu_processor.html

Le coprocesseur Tesla, est donc un GPU destiné uniquement au calcul. Pour la modique somme de 1300$ (pas énorme) un particulier peut avoir 128 coeurs de calculs avec 3Go de mémoire dédié dans sa machine.

Tout ça pour en arriver à une enquête sur la programmation parallèle.

Qui ici écrit des programmes parallèle ? en utilisant quelles type d´architecture (multi-coeurs, ou alors multi-machine) ? avec quels modèles et quels bibliothèques ou outils pour le faire ? et pour écrire quoi ?

bref, tout ce que vous pouvez avoir envie de dire sur le sujet.

La prog parallele, sujet sympa !
Pour ma part, je programme a 99.9 % un seul processus a la fois (donc pas de prog parallele)
Mais il m´est quand meme arrivé de faire plusieurs tests sur la prog paralllele (uniquement sur CPU, pas de GPU en ce qui me concerne)
J´ai fait des essais de processus, threads, mutex, etc etc, par curiosité !
Apres, c´est vrai que je n´y utilise pas tous les jours.

J´avais fait un aspirateur de jeuxvideo.com (qui aspirait les pages de chaque test de jeux, et pondait un site avec des screenshots, j´aime bien mon aspirateur spécifique), lui est multithread (avec nobre de threads paramétrables)
Ce programme se prete idéalement à cela : puisque je fais un grand for (qui va de 1 jusqu´a 18000), qui correspondent, par exces, a chacun des jeux testés par JeuxVideo.com
le thread principale s´occupait de lancer les autres threads, de les attraper quand ils avaient fini une page, pour leur en donner une autre.
Je faisais partir 20 threads, qui alalient chacun télécharger la page, l´analyser, et télécharger les images du jeu.

Ma these est en programmation parallele. Je m´interesse particulierement au probleme théorique qui apparaisse mais je connais aussi la pratique.

J´ecrit en ce moment un framework de programmation parallele pour processeur multicoeur (bien qu´il marche avec n´importe quel multiprocesseur) a base de PThread.
une url: http://gforge.inria.fr/projects/pastel/
C´est du work in progress sur la parallelisation des algorithmes de la STL. Ca marche bien quand on se prend pas un effet NUMA dans la tete.

Au niveau du calcul distribué, on ne manque pas d´outils: MPI, KAAPI, Athapascan, Globus, RPC...

Bien sur, tu as cité CUDA pour les carte graphique de NVidia.

MPI est une lib de communication a base de passation de message. Tres utilisé dans le calcul scientifique.

KAAPI est un framework en C++ qui sert a faire de l´algorithmique parallele adaptative sur machine a mémoire distribué (Ca marche aussi en mémoire partagé). L´idée est de présenter ses algorithmes dans une formes récursive en déclarant ce qui peut etre fait en parallel de quoi. Ca marche plutot bien. Ca utilise Athapascan pour la couche réseau.

Globus sert a faire du desktop grid computing "a la seti@home". C´est dans le meme style que Boinc.

On peut naturellement utilisé tous les mecanisme de RPC pour faire du calcul parallele. En attendant que le serveur distant te répondent, tu peux calculer autre chose.

J´ai oublié de parler de cilk qui est une extension assez simple du C pour faire du calcul parallele. C´est assez simple a prendre en main.

Il y a aussi la lib openMP qui marche assez mal et qui est utilisé par GCC.

Ca devrait te donner une bonne vue d´ensemble des outils. Si tu as plus de question, n´hesites pas!

ce n´était pas tant des questions précise, qu´une envie de voir ce que les participant au forum font dans ce domaine, déclenchée par cette vision de rêve qu´est la carte Tesla.

Pour ma part, je me suis essayé principalement à 3 choses :

• un peu d´OpenMP pour mon programme de TIPE. Avec l´avantage pour cette bibliothèque que contrairement à la plupart des autre méthode, le code de base (non parallèle) n´a pratiquement pas à être touché. C´est-à-dire qu´on mets des pragma en C qui disent au compilo : "tu peut paralléliser telle boucle de telle manière". Bien sûr, dans ce modèle c´est assez limité, mais c´est vraiment très simple à mettre en œuvre.

Combiné avec le compilo Intel (récemment passé en version 10, et toujours gratuit sous linux pour une utilisation non commerciale) qui est capable de vectoriser tout seul certaines boucles et de paralléliser tout seul le code dans certaines circonstance, j´ai pu avoir un gain presque de 2 sur deux cœurs par rapport à une version sans ces optimisation (mais avec le même compilateur) pour mon TIPE (le programme s´y prêtait bien si vous vous en souvenez, car il s´agissait de simuler des particules interagissant entre elle par le biais de forces électrostatique).

Bon, il y a aussi le cas trivial ou on peut découper en morceau facilement la tâche d´un programme. Dans ce cas, là, il m´arrive d´utiliser des fork sous linux avec des passages de données via des pipe. Pourquoi pas des thread ? parce que j´utilise du Caml dans ces moment là, et qu´il n´y a pas de bon support pour les thread en caml.

Et enfin, cette année, j´ai travaillé en cours sur NGrid, un framework de calcul distribué qui est pour l´instant assez instable (le cours consistait à développer le framework, pas à développer avec), mais dont l´archi vise à enlever le plus possible de travail au programmeur final, tout en abstrayant la partie physique en dessous de la grille de calcul.

Tout ça me rappelle qu´il y a quelques temps (en sup), pour résoudre le programme des N-reines (placer N reines sur un échiquier N*N sans qu´elles soient en prise) pour des N grand (ici grand veut dire au dessus de 20), j´avais écrit un programme qui découpait le plateau à explorer en plusieurs secteur, écrivait un fichier de configuration pour un autre programme que j´avais écrit et j´ai distribué à tout mes camarades de classe une tranche du calcul. Ça a été ma seul expérience de calcul distribué sur plusieurs machine. Mais ce n´était pas très automatisé.

Tout ça pour dire qu´alors qu´on a de plus en plus de cœurs de calcul dans nos PC, on n´a toujours pas ni la théorie, ni les outils simple qu´il faudrait pour les utiliser facilement (ie, sans travail de la part du programmeur, un peu comme les outils de Intel).
Mais c´est vrai que, en regardant la thèse de godrik (bon, la il y a peut d´information encore) je me dit que c´est un peu le genre de chose qui peuvent être très utile : le programmeur utilise des outils dont il a l´habitude et par magie, ils sont parallélisés.

bref, et enfin, je signale à ceux qui ne connaisse pas, l´existence de JoCaml, une version d´OCaml qui permet de faire du join-calcule en OCaml (donc du calcul concurrent (sur une machine) ou distribué (sur plusieurs). Mais je n´ai pas encore testé.

"mais dont l´archi vise à enlever le plus possible de travail au programmeur final, tout en abstrayant la partie physique en dessous de la grille de calcul."

Globalement, toutes les tentatives d´abstraire la couche physique ne marche pas tres bien. Le plus grand probleme qui se posent est: comment faire discuter l´application et le middleware de facon SIMPLE et efficace. Pour que chaque partie puisse faire ce qu´il a a faire. Et il n´y a pas vraiment de réponse a cela.

"Mais c´est vrai que, en regardant la thèse de godrik (bon, la il y a peut d´information encore) je me dit que c´est un peu le genre de chose qui peuvent être très utile : le programmeur utilise des outils dont il a l´habitude et par magie, ils sont parallélisés."
En fait, Ce n´est pas mon travail mainstream. C´est plus une preuve de concept. On nous dit dans tous les livres d´informatique que le parallelisme est efficace sur de grosses structure de données et que c´est pour cela qu´on ne peu pas faire du parallelisme sur les données de petite taille. On cherche a montrer (et on y arrive modulo ce $#"!! de scheduler de processus) que sur les architectures parallele a mémoire partagé moderne, ceci est possible. (Je vous donnerait l´adresse du technical report quand je l´aurait ecrit)

Bien sur cette approche ne regle pas tous les problemes et ne permet pas d´utiliser vraiment les perfs de son quadri-core préféré, mais c´est (a mon avis) un bon début pour savoir ce que l´on peut faire et ce que l´on ne peut pas faire.

En passant, Vous connaissez peut etre le modele de parallelisme PRAM developpé dans les années 1970/80, qui sert de "machine de turing" pour l´étude de la programmation parallele. Jusqu´a présent ce modele était purement théorique, les machines étaient vraiment trop différente de ce modele. Mais récement, un industriel a fondu quelque chose qui ressemble beaucoup. C´est un FPGA avec 64 processeurs chacun composé de 16 coeur (soit 1024 unité de calcul). Cadencé a 75Mhz avec une mémoire synchrone permettant de faire "comme si" on avait une PRAM. Affaire a suivre.

Globalment dire qu´on a pas la théorie, c´est un peu méchant. Elle existe et est présente dans les livres. Globalement, on sait faire des applis parallele avec de pas trop mauvaise perf, on sait ce qui est facile et ce qui est difficile. Mais les outils manquent cruellement. En parallele, on a besoin de beaucoup plus d´information qu´en sequentiel pour etre efficace. Obtenir cette info n´est pas forcement facil. La plupart du temps, le developpeur ne l´as lui meme pas vraiment.