Quel est le meilleur langage pour la programmation parallèle ?

**dourouc05** · 23/05/2011, 10h21

Petit sondage pour l'ouverture de ce forum : quel langage trouvez-vous le meilleur pour la programmation parallèle/concourante ?

Le but n'est pas d'avoir une suite de réactions disant que tel langage est meilleur, sans plus d'explications : pourquoi tel langage vous semble-t-il le plus approprié pour la programmation parallèle ? Quels sont les éléments qui vous font pencher en sa faveur : les outils disponibles, la syntaxe... ?

Peut-être un paradigme de programmation vous semble plus approprié que les autres : impératif, objet, fonctionnel, logique... ?

Exprimez-vous dans le sondage et précisez votre opinion en répondant à ce message, de manière aussi constructive et détaillée que possible !

**gangsoleil** · 23/05/2011, 13h36

Bonjour,

Pour moi, le C est l'un des langages de la programmation parallele, car il est suffisamment bas niveau pour permettre d'interragir finement avec la machine.

Mais bien sur, outre le langage, la bibliotheque parallele, et plus encore son implementation, restent fondamentales. Le langage le plus adapte avec une mauvaise bibliotheque ne peut donner de bons resultats.

**Traroth2** · 23/05/2011, 14h37

J'aurais dit Erlang. C'est un langage pour le calcul parallèle avec mémoire distribué, et sa logique dans laquelle les variables ne peuvent être affectées qu'une seule fois et qui rend donc impossible l'accès concurrent en écriture à une donnée (puisqu'elle ne peut être écrite qu'une seule fois, si vous suivez) diminue radicalement les effets de bord et les erreurs de synchronisation. Tout passe par un transfert de message, de manière analogue à MPI.

Sinon, Clojure, un dialecte Lisp pour la JVM, est bien aussi.

**lenny32** · 23/05/2011, 15h13

C# pour la simplicité d'utilisation.

**TropMDR** · 23/05/2011, 16h21

Envoyé par gangsoleil

Pour moi, le C est l'un des langages de la programmation parallele, car il est suffisamment bas niveau pour permettre d'interragir finement avec la machine.

J'avoue ne pas voir le lien entre le début de la phrase (être adapté à la programmation parallèle) et la fin de la phrase (être bas niveau)...

Ce sont justement les langage bas niveau qui posent le plus de soucis pour la programmation parallèle, car ils n'offrent pas les abstractions indispensables à ce genre d'activité.

**dourouc05** · 23/05/2011, 16h35

Envoyé par TropMDR

J'avoue ne pas voir le lien entre le début de la phrase (être adapté à la programmation parallèle) et la fin de la phrase (être bas niveau)...

Ce sont justement les langage bas niveau qui posent le plus de soucis pour la programmation parallèle, car ils n'offrent pas les abstractions indispensables à ce genre d'activité.

Le bas niveau te permet de savoir précisément ce qui se passe sur tes processeurs, tu peux contrôler presque jusqu'à l'instruction près ce qui est exécuté, dans quel ordre, sur quel processeur, etc.

Un peu comme quand on compare la programmation orientée objet et l'assembleur : d'un côté, du très haut niveau, c'est beaucoup plus facile à comprendre pour un être humain que l'assembleur, de l'autre côté, très proche de la machine, de ce qu'on lui demande de faire, pas de la pensée, de l'abstraction humaine.

**TropMDR** · 23/05/2011, 17h32

Envoyé par dourouc05

Le bas niveau te permet de savoir précisément ce qui se passe sur tes processeurs, tu peux contrôler presque jusqu'à l'instruction près ce qui est exécuté, dans quel ordre, sur quel processeur, etc.

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%

**dourouc05** · 23/05/2011, 17h39

Envoyé par 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%

Et c'est bien dommage : dur de comprendre pourquoi une telle optimisation ne fonctionne pas au final, quand on reste à du très haut niveau. L'explication se situe parfois au très bas niveau. Et ce n'est pas valable que pour la programmation parallèle, c'est valable partout, même en dehors du développement ou de l'informatique : quand on sait comment fonctionnent les boutons de la machine, on peut les utiliser à bon escient.

**gbdivers** · 23/05/2011, 18h00

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%

Peut être la même proportion que ceux qui font de la programmation parallèle...

Il ne faut pas se faire d'illusion, la programmation parallèle (SIMD, GPU computing) nécessite souvent (toujours ?) de connaître le bas niveau de sa machine (transfert de données, buffers, organisation des treads, etc.), simplement parce qu'il faut parfois (souvent ?) adapter l'algorithme au matériel. Je ne crois pas que ce soit possible d'écrire 1 algorithme et qu'il soit parfaitement optimisé sur n'importe quelle plateforme.
En partant de là, un langage bas niveau sera plus intéressant puisqu'il permet de mieux adapter l'implémentation de l'algorithme.

Mais je n'ai peut être pas une vision globale de la problématique. Ca serait intéressant d'avoir l'avis de JoelF (c'est son domaine de recherche ; et il a peut être testé aussi la programmation parallèle avec les langages fonctionnelles)

**banche** · 23/05/2011, 20h56

Pour ma part je trouve que les langages C/C++ (j'ai une préférence pour le C++) sont tous les deux bien adaptés. Des bonnes bibliothèques simples d'utilisation existent déjà. J'ai déjà utilisé sans aucune difficulté intelTBB, boost, Qthread et Qrunnable avec toujours les mêmes gains : à savoir proportionnel aux nombres de cœurs/ processeurs utilisés. Bien sur tous les algorithmes ont été si besoin revu afin de pouvoir fonctionner en parallèle donc différents des versions séquentielles.

Concernant les GPU j'ai mené deux projets à terme et la compréhension du matériel est primordiale car elle influence directement l'algorithmie utilisée derrière. Il faut en effet déterminée les tailles des sous problèmes afin d'utiliser au maximum les capacité de la carte (surtout la mémoire rapide, shared memory pour ceux qui connaissent) tout en faisant attention à la propagation des erreurs qui étant différente peut conduire à des résultats différents.

Je rejoins donc un peu l'avis de gbdivers, cependant concernant la programmation classique sur CPU une connaissance du matériel est un plus mais pas nécessaire car les bibliothèques de relativement haut niveau fonctionnent très bien, la partie algorithmique est par contre indispensable.
Sur le GPU les deux sont à mon avis nécessaires, ou du moins pour obtenir un gain minimum d'un facteur 10

**cs_ntd** · 23/05/2011, 23h21

J'ai voté C/C++ pour les raisons que l'on connait (bas niveau, librairie existantes, ...), mais aussi C# pour la "Parallel Task Library" du framework 4, et d'autres innovations du genre (instruction await, async) qui permettent des trucs vraiment sympa, et très naturellement, vraiment facilement.

La programmation parrallele est très bien intégrée dans ce langage

**lapinferoce** · 24/05/2011, 08h48

erlang !!!
pourquoi ? concurrency done right ! en plus c'est un langage fonctionnel

**yann.falevoz** · 24/05/2011, 09h22

LabVIEW, sans aucune hésitation!

**gangsoleil** · 24/05/2011, 09h23

Bonjour,

Envoyé par 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. C'est ce que font pas mal de physiciens, avec d'assez bons resultats. Mais lorsqu'ils veulent de vrais programmes paralleles, ils s'adressent a des informaticiens dont c'est le metier, et les performances sont bien meilleures.

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.

**ulspider** · 24/05/2011, 09h44

Pour la programmation parallèle, j'aurai tendance à dire le C, notamment avec l'API MPI qui est très puissante

Elle est d'ailleurs utilisée par le CEA et le CNRS

**Traroth2** · 24/05/2011, 10h07

Envoyé par dourouc05

Le bas niveau te permet de savoir précisément ce qui se passe sur tes processeurs, tu peux contrôler presque jusqu'à l'instruction près ce qui est exécuté, dans quel ordre, sur quel processeur, etc.

Un peu comme quand on compare la programmation orientée objet et l'assembleur : d'un côté, du très haut niveau, c'est beaucoup plus facile à comprendre pour un être humain que l'assembleur, de l'autre côté, très proche de la machine, de ce qu'on lui demande de faire, pas de la pensée, de l'abstraction humaine.

Le problème est au niveau de la question. Ca veut dire quoi, "le meilleur langage" ? Si c'est le langage plus efficace pour la programmation parallèle, ce n'est clairement pas le C, où on est obligé de comprendre ce qui se passe jusqu'au niveau le plus bas avant de pouvoir faire quoi que ce soit...

**barmic** · 24/05/2011, 10h09

Très souvent, on a des algorithmes en O(N^x) ou toute la partie lourde consiste à traiter de manière séquentielle l'ensemble des données d'entrée. Pour ces cas là, où quand on les écris on sens bien que c'est pas très complexe à paralléliser, il y a la bibliothèque OpenMP qui aide énormément et qui permet de diviser le temps de calcule par 2 à 3 sur la plupart des processeurs SMP actuels.

Elle est extrêmement simple à utiliser et donne de bons résultats, si déjà ce genre de solution étaient plus utilisées ça donnerais un bon bol d'air frais à tout les utilisateurs de CPU multi-coeur. Peut être que des langages de plus haut niveau (Java ou C#) intègre directement ce genre d'optimisation de manière transparente dans le compilateur (ou au runtime), je n'ai pas essayé.

Mais vraiment, je ne pense pas que c'est en jouant les élitistes pour garder son bout de viande ("je suis irremplaçable parce que moi je sais faire") que l'utilisation des architectures multiprocesseurs va évoluer dans le bon sens.

**Traroth2** · 24/05/2011, 10h09

Envoyé par ulspider

Pour la programmation parallèle, j'aurai tendance à dire le C, notamment avec l'API MPI qui est très puissante

Elle est d'ailleurs utilisée par le CEA et le CNRS

La combinaison MPI / OpenMP / OpenCL permet de faire des choses puissantes, mais pas facilement. J'aime mieux la combinaison MPJ / JOMP / JoCL. Au moins Java prend en charge une partie de la complexité !

**vaild** · 24/05/2011, 10h20

bah moi je dirai le Go ??
après tout, c'est un langage jeune, et donc censé être adapté aux technologies modernes, et en plus il est fait pour ça...

d'accord, il est encore loin d'être parfait, mais...

**Grimly_old** · 24/05/2011, 10h31

Je pense que c'est plus de l'ordre du développeur que du langage.

Les différents problèmes d’inter-blocages persistent dans presque tous les langages.