Discussion :

[ijk-ref]

Franchement la réponse de certains me sidère !

La question est pourtant simple : Quel langage pour la programmation parallèle... NON PAS quelle bibliothèque !!!

Répondre C ou C++ !!! parce que c'est bas niveau ²

C'est la réponse la plus absurde du monde ! Et pour le meilleur langage objet vous répondez aussi le C ou l'assembleur car il permet de tout contrôler et de réinventer les mécanismes d'héritage et tout et tout !!!

Vous êtes sur de comprendre la question !?

[Heimdall]

Salut,

concurrence != parallelisme

Tu peux en dire plus s'il te plait ?

Merci a+

[Niark13]

J'ai mis D, parce que son système de type (const transitif, immutabilité, données non partagées entre les threads par défaut...) me parait bien adapté.

Plus d'infos :
http://www.informit.com/articles/pri...aspx?p=1609144

[hsyl20]

J'avais répondu à un topic similaire il y a quelque temps. Ça reste d'actualité :
http://www.developpez.net/forums/d95...e/#post5377819

Déjà il faut bien faire la différence entre parallélisme et concurrence (voir le lien ci-dessus). Ensuite il faut voir les objectifs visés : si vous voulez un code non portable (i.e. dédié à une machine) et qui trace, vous pouvez utiliser un langage bas niveau (C, C++, Fortran). C'est ce qui est fait sur les supercalculateurs comme Tianhe, RoadRunner ou BlueGene.

Cependant, dans le cas général où on souhaite que l'application soit portable, on doit s'abstraire de l'architecture. Jusqu'ici les langages bas niveau avec des extensions comme OpenMP et des API standards comme MPI permettaient d'avoir des perfs raisonnables sur différentes machines. Ça n'est plus le cas aujourd'hui avec l'introduction des accélérateurs (GPU, CELL...). Les architectures hétérogènes sont beaucoup plus difficiles à programmer. Il faut remettre en cause les algorithmes : un algo tout pourri sur CPU peut être le plus efficace sur GPU. Le modèle de mémoire partagée, qui avait déjà été mis à mal avec les architectures NUMA, n'est plus valide maintenant que les mémoires sont distribuées (mémoire hôte, mémoire GPU, etc.) et que les transferts entre chaque mémoire sont explicites (transferts DMA asynchrones).

Bref, pour l'instant dans le domaine de la programmation parallèle, il n'y a pas de langage ultime. Il y a bien quelques expérimentations intéressantes comme ZPL/Chapel, Fortress, x10, Single Assignment C, Intel ArBB, mais rien de mainstream jusqu'ici.

Dans le domaine de la programmation concurrente, les modèles à base d'acteurs (i.e. threads en espace utilisateur), que l'on trouve initialement dans Erlang mais qu'on retrouve désormais également dans Scala par exemple, donnent de très bons résultats. Scala propose d'ailleurs de les exploiter à travers les collections parallèles depuis la version 2.9.

[TropMDR]

C'est quoi la proportion de programmeur sur cette planète capable de comprendre "jusqu'à l'instruction près ce qui est exécuté, dans quel ordre, sur quel processeur" ? Je parie sur moins de 0,1%

J'espere que tu te trompes. Pour moi, faire de la programmation parallele, ce n'est pas ecrire un programme en Fortran puis le passer dans un paralleliseur.[...]

Si tu n'es pas capable de comprendre ce qu'est un niveau de cache, un sous-ensemble de processeurs, une communication reseau, ... Alors je ne pense pas que tu puisses apprehender toutes les contraintes de la programmation parallele.

Ouais...
Imaginons que glob1 et blog2 sont des variable globale initialement à 0. Et que les deux block de code suivant s'exécutent en parallèle sur deux coeur d'un processeur x86

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
{
  int i1 = 0;
  int i2 = 0;
  glob1 = 1;
  i1 = glob1;
  i2 = glob2;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
{
  int j1 = 0;
  int j2 = 0;
  glob2 = 1;
  j2 = glob2;
  j1 = glob1;
}

(Ou si vous préférer, un truc genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MOV [100] ← $1
MOV EAX ← [100]
MOV EBX ← [200]

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MOV [200] ← $1
MOV ECX ← [200]
MOV EDX ← [100]

)
D'après toi, quelle proportion des programmeurs sont capables de donner toutes les sorties possibles opur i1, i2, j1 et j2 (ou EAX EBX ECX et EDX) et en le justifiant ?

[byrautor]

Je ne vois pas trace de la notion d'interruptions et de sa hiérarchisation.
Dans les automates, où des multitâches sont exécutées parallèlement, c'est un des ressorts de la bonne exécution. L'univers du temps réel est parsemé de pièges "mortels"

[Alp]

Pour étayer ce qu'a dit Joel, je vous renvoie vers ceci concernant Haskell : http://www.haskell.org/haskellwiki/Parallelism

[NicoL__]

Pour moi c'est C# avec .net 4.0, un gros effort a été mis pour facilité la parallisation et la simplicité avec des trucs du genre : parallel.foreach
A oui c'est vrai que c'est pas fin, mais dans 80% des cas ça suffit et ça peut être très très simple de refactorer le code pour mutlithreader certaines portion avec des gains rapide. Ok c'est .net qui gère tout... le nb de thread etc... mais bon il le fait pas si mal, je vais pas me cogner de regarder combien y a de Core sur la machine pour voir le nombre de thread optimum à chaque fois que je veux faire un peu de multithreading.

[gangsoleil]

D'après toi, quelle proportion des programmeurs sont capables de donner toutes les sorties possibles pour i1, i2, j1 et j2 (ou EAX EBX ECX et EDX) et en le justifiant ?

Malheureusement pas assez. Neanmoins, ce sont des concepts fondamentaux pour pouvoir apprehender la programmation parallele.

Savoir qu'il ne faut pas utiliser de variable globale en parallelisme (pas en ecriture sans lock dessus etc ... on se comprend), c'est bien. Mais si en plus le developpeur sait pourquoi, cela permet d'etre certain qu'il ne va pas le faire, ou en connaissance de cause.

Globalement, cette reflexion est valable pour tout ce qui est haut niveau : c'est extremement utile, et ca permet de faire certaines choses beaucoup plus rapidement, relativement proprement.
Mais faire du developpement avec un haut niveau d'abstraction en ayant connaissance de tous les mecanismes sous-jacents, cela permet d'etre encore plus efficace et d'eviter de nombreuses erreurs.

[sjrd]

Bon, autant vous dire franchement ce que je pense : je suis choqué qu'on pense encore à du C pour faire du parallèle Une réponse beaucoup plus sensée était celle sur Erlang : ce langage est fait pour ! C'est clair qu'il est mieux pour faire du parallèle.

Sinon, pour donner un langage moins connu : Oz (voir http://www.mozart-oz.org/). À la base c'était une extension d'Erlang (donc les single-assignment et la mémoire distribuée sont là), qui fait pas mal de choses en plus. De nouveau, c'est un langage fait pour la programmation parallèle et surtout distribuée.

Sinon dans un registre plus "familier" à pas mal de lecteurs, il y a Scala qui se débrouille pas mal non plus. Avec ses nouvelles collections parallèles et Akka, ça prend du poil de la bête

Et finalement, je ne peux pas écrire ce post sans mentionner Ozma (https://github.com/sjrd/ozma), qui est le sujet de mon mémoire, et qui intègre dans Scala les primitives de Oz. La différence c'est que lui il est pas encore au point

[Heimdall]

Bon, autant vous dire franchement ce que je pense : je suis choqué qu'on pense encore à du C pour faire du parallèle Une réponse beaucoup plus sensée était celle sur Erlang : ce langage est fait pour ! C'est clair qu'il est mieux pour faire du parallèle.

Ca tourne à la polémique ce topic franchement, et un peu au manque d'ouverture d'esprit. Il y a des tas de gens qui utilisent le C pour faire de la programmation parallèle, en utilisant des bibliothèques de haut niveau (exemple MPI) par exemple, énormément de choses sont complètement transparentes... au final dans ces programmes, le C est utilisé pour d'autres raisons... mais il n'apporte aucun inconvénient pour la parallélisation d'un programme initialement séquentiel.

[sjrd]

Ah comme j'aime qu'on me prête un manque d'ouverture d'esprit surtout en matière de langages de programmation. Généralement dans ce genre de débats, ce sont ceux qui se confinent à leur langage "favori" qui manquent d'ouverture d'esprit. Je ne dis pas que c'est ton cas, mais j'ose prétendre que ce n'est pas le mien.

Comme l'a très bien fait remarquer ijk-ref, la question porte sur le langage, pas la biblio. C avec MPI c'est MPI qui fait tout, en matière de parallélisme. Ce n'est pas C.

Et puis même, pour avoir fait du MPI et du Oz, je préfère largement travailler avec Oz pour faire du parallélisme, bien que je déteste la syntaxe et la difficulté à se relire dans ce langage.

[Heimdall]

Ah comme j'aime qu'on me prête un manque d'ouverture d'esprit surtout en matière de langages de programmation. Généralement dans ce genre de débats, ce sont ceux qui se confinent à leur langage "favori" qui manquent d'ouverture d'esprit. Je ne dis pas que c'est ton cas, mais j'ose prétendre que ce n'est pas le mien.

oh mais je ne parlais pas forcément de toi, mais du topic entier.

Comme l'a très bien fait remarquer ijk-ref, la question porte sur le langage, pas la biblio. C avec MPI c'est MPI qui fait tout, en matière de parallélisme. Ce n'est pas C.

Tout a fait... mais on peut se demander si la question de départ a réellement du sens vis à vis du but (supposé) de ce forum. Ici il est question de parallélisme au sens large (si je puis dire ça ainsi)... Beaucoup de gens (dont je fais partie) prétendent faire des programmes parallèles sans pour autant rien comprendre à comment la biblio qu'ils utilisent (MPI pour moi en l'occurence) fonctionne réellement.

Quand je dis "je fais des programmes parallèles", je dis que je conçois et code des algorithmes dont le calcul sera executé par des process différents. C'est ce que 99% des scientifiques qui font du calcul intensif sur des clusters de calcul font, et ils n'y connaissent rien à la programmation bas niveau (ou pas) liée au parallélisme en lui même.

De ce point de vue là (dont j'ose espéré qu'il n'est pas pour certain hors sujet sur ce forum), on se fout effectivement complètement du "langage" que l'on utilise, pourvu qu'un bibliothèque parallèle soit implémentée dans le langage qu'on a choisi (pour d'autres raisons donc) comme le meilleur pour notre objectif.


Donc en conclusion, soit la question n'a pas de sens, soit elle n'est pas assez précise.

[Camille_B]

De toute manière séparer le langage de la bibliothèque est au final assez absurde.

Supposons que C+Mpi soit, au final, supérieur à Oz tout seul en matière de parallélisation du code. Faut-il choisir Oz parce que la bibli ça compte pas ?

Plus sérieusement, Oz ne dispose pas d'une communauté aussi conséquente que C et d'une bibliothèque aussi riche. C+Mpi n'est peut-être pas aussi bien que Oz en matière de parallélisation, mais C+Mpi+les_autres_biblis+les_années_de_rodage_du_langage vs Oz tout seul sans rien d'autre que sa parallélisation, c'est peut-être, dans certains cas, une solution meilleure.

Je ne connais pas Oz, et puis je suppose que dans ce genre d'affaire tout est fonction du projet et de l'équipe que l'on a avec soit.

Mais au final, au sujet des bibliothèques d'un langage, j'aime beaucoup cette expression de la communauté Perl :

Perl est la syntaxe, le CPAN est le langage.

P.S. : le CPAN c'est l'immense bibliothèque accessible avec l'outil du même nom pour Perl.

[TropMDR]

Malheureusement pas assez. Neanmoins, ce sont des concepts fondamentaux pour pouvoir apprehender la programmation parallele.

Ouais, j'évalue le "pas assez" à moins de 0,1% justement (dommage que personne n'ait pris le risque de répondre). Et non, je ne pense pas que comprendre le modèle mémoire relaxé du x86 soit un concept fondamental pour pouvoir appréhender la programmation parallèle, justement parce qu'il y a des modèle bien meilleurs que la mémoire partagé (genre le passage de message). Et heureusement, vu la complexité incroyable de la chose (et le fait que ça change d'un proc à l'autre. Genre un algo qui marche sur x86 échouera lamentablement sur powerPC).

Savoir qu'il ne faut pas utiliser de variable globale en parallelisme (pas en ecriture sans lock dessus etc ... on se comprend), c'est bien. Mais si en plus le developpeur sait pourquoi, cela permet d'etre certain qu'il ne va pas le faire, ou en connaissance de cause.

Le problème, c'est que si tu fais du parallélisme en mémoire partagée et que tu fous des locks sur tous tes accès, tu es un peu dans la merde en terme de perfs...


Tout ça pour dire que le fait d'être "proche de la machine" n'est vraiment pas un avantage en programmation parallèle, puisque ça augmente *considérablement* la probabilité de faire une grosse connerie...

[Invité]

J'ai voté C/C++ et C# que je connais bien. Je sais que Java s'en tire pas mal mais je n'en fais pas !!

C pour la robustesse et le fait qu'il "colle au natif" mais aussi parce qu'il est incontournable dans certains systèmes alors que les autres apportent surtout du confort.

C++ parce que L'objet et le parallèle vont bien ensemble

Et C# parce que je m'amuse a lui faire paralléliser des trucs souvent.
C'est avec C# que je fais des tests parfois absurdes : Pas envie de mettre la conception avant le test : boom j'encapsule le point d'entrée que j'appelle dans un thread et j'attends que ça crashe !!

Le gros avantage est que la prise en charge sous debugger est vraiment si bonne que je lance le programme parfois avant même de réfléchir aux conséquences c'est le debugger qui me les donne !

Je pourrais imaginer mettre au point une approche parallèle en C# pour la porter en C une fois que j'ai tout débuggé (voire réécrit) Mais on pourrait sûrement dire la même chose de tous les ide's avec un bon debugger...

Parfois il faut se prendre le chou AVANT de concevoir l'algorithme. Perso je fais ça sur papier avec trois stylos de couleur différente... Boucles parralèles ou récursivité donnent du fil à retordre et le site d'Intel m'a sauvé plus d'une fois.

[Invité]

Après réflexion : il me semble qu'il n'existe pas de "meilleur" langage parallèle ni de hiatus entre langage et librairie. L'OS est déjà très parallèle quant au réseau il n'a pas son pareil pour parallèliser n'importe quoi même en vba !!
Dans ce cas la difficulté consiste même parfois à forcer un comportement mono thread pour rester synchrone.
C'est un peu pour ça que j'insiste sur le debugger.
A mon avis le sens de l'article parle surtout de multicore car la problématique des développeurs "moderne" passe par ce paradigme. Le multithread est une forme de paralèlisme ou chaque "fork" peut donner lieu à de multiples threads mais on ne sait pas vraiment comment un processeur donné va distribuer ces tâches dans ses cores. On espère juste que les process ne se bloqueront pas entre eux et peut-être un gain de performance.
Je pense que pour répondre à cette myriade de cas il faudrait mieux préciser le domaine couvert par le mot "parallèle"

Selon moi le casse-tête vient souvent du fait qu'on attend d'un multicore qu'il soit x fois plus rapide qu'un monocore et ce "malentendu" n'est pas le seul mais c'est le plus fréquent dans l'esprit des clients ou des commerciaux..
Hélas cette approche est généralement trop simpliste. Il vaut mieux gérer un affichage asynchrone (parallèle donc) car c'est relativement simple à faire qu'une connexion aux données asynchrone qui est complexe et génératrice de nombreux bugs de synchro qui sont parfois presque indétectables.

Dans ce contexte le language est moins le problème que le rapport entre le besoin formulé et la technique employée.
Pour revenir à nos moutons : dans le cas d'un programme qui tirera parti du multicore : C# est génial
Le C on ne sait pas bien car les plateformes embarquées multicores sont encore rares (pas pour longtemps)
Un chose est sûre : l'expérience du développeur compte plus que le language !!

[sekaijin]

UPC ?

[pvincent]

La première question à se poser me semble être: parallèle pour quoi faire?

Pour le calcul intensif, les compilateurs FORTRAN offrent souvent des options permettant une parallèlisation automatique ou controlée, avec l'avantage d'une compatibilité qui rend le code non spécifique.

N'en déplaise à certains, FORTRAN <<is well and alive>> et toujours fort utilisé dans le domaine du calcul scientifique.

[dargaud]

Il y a bien 20 ans j'avais trouvé Ada remarquablement clair pour le parallélisme/multithread. Mais j'en n'ai pas fait depuis ! J'ai bien essayé Erlang, mais j'ai eu du mal à accrocher. Je fais du C 90% de mon temps et je dois bien avouer que c'est pas du tout adapté au parallélisme qq soit la librairie, c'est un peu comme de mettre un réacteur d'avion sur un vélo. Sinon, bash finalement ça marche pas mal en multithread