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.

**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.

**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...

**dourouc05** · 24/05/2011, 11h05

Envoyé par Traroth2

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...

C'est le meilleur d'un point de vue très personnel : pour toi, le C n'est clairement pas un bon langage pour faire de la programmation parallèle pour certaines raisons, tu as donc un langage qui te semble plus approprié, ce sera celui-là le meilleur de ton point de vue.

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

LabVIEW, sans aucune hésitation!

**Camille_B** · 24/05/2011, 11h13

Les réponses données sont bonnes

Il me semble que C est un langage indémodable car il a su trouver la bonne distance entre haut-niveau et bas-niveau pour être utilisable dans tous les cas sans sombrer dans l'extrême complexité (ne serait-ce que lorsque l'on vise plusieurs plateformes) des assembleurs.

Cela dit l'usage de langages de plus haut niveau dans ce domaine peut-être heureux. Clojure se dépatouille bien non ?

Le mélange C + langage de plus haut niveau étant une solution, une fois maîtrisée, souvent heureuse.

**FloMo** · 24/05/2011, 11h37

C / Objective-C avec Grand Central Dispatch ( libdispatch, Open Source ), c'est le pied. C'est efficace et simple à aborder.

Sinon, toujours en C, j'ai testé OpenCL : c'est plus complexe à aborder, mais aussi très efficace.

En technologie plus ancienne, les threads POSIX sont un peu casse-têtes, mais relativement efficaces.

**Kajan** · 24/05/2011, 12h11

Qu'est-ce qu'il en est d'ADA?

J'ai jamais utilisé ce langage, mais j'ai entendu qu'il est très utilisé dans tout ce qui est temp réel/embarquée/parallèle etc...

A moins que je me trompe sur le dernier point?

**dourouc05** · 24/05/2011, 12h23

Envoyé par Kajan

Qu'est-ce qu'il en est d'ADA?

Ajouté à la liste, en même temps que MATLAB (pour sa toolbox http://www.mathworks.com/products/parallel-computing/, qui permet de faire passer un for à sa version parallèle en remplaçant le for par parfor, tout simplement : difficile de faire plus simple que ça !)

!

Pour Ada, il semblerait qu'il y soit adapté, au moins depuis la version 95 (maintenant, est-il utilisé pour ça ? fait-on mieux depuis lors ?) :

Envoyé par http://www.dwheeler.com/lovelace/s1s1.htm

Also, Ada's parallel constructs can take advantage of today's more advanced operating systems (such as Microsoft's Windows NT and Linux).

(Premier résultat Google sur ada parallel).

**gangsoleil** · 24/05/2011, 13h27

Tres peu utilise aujourd'hui, mais qui a ete largement utilise par le passe : le fortran.

Il existe d'ailleurs des paralleliseurs de code en fortran, mais ceux-ci sont surtout utilises par les physiciens.

**Heimdall** · 24/05/2011, 23h10

Envoyé par gangsoleil

Tres peu utilise aujourd'hui, mais qui a ete largement utilise par le passe : le fortran.

Il existe d'ailleurs des paralleliseurs de code en fortran, mais ceux-ci sont surtout utilises par les physiciens.

En effet... la grande majorité des codes de simulation numérique en physique sont écris en fortran, et les codes parallèles c'est pareil.

Le second langage le plus utilisé dans ces programmes scientifiques parallèles est le C... et en troisième le C++ je dirais.

**Idwakest** · 24/05/2011, 13h29

Qu'est-ce qu'il en est d'ADA?

J'ai jamais utilisé ce langage, mais j'ai entendu qu'il est très utilisé dans tout ce qui est temp réel/embarquée/parallèle etc...

L'Ada est en fait le seul langage certifié pour faire du code critique embarqué pour l'avionique et l'aérospatial.

Sinon pour en revenir au sujet. De mon point de vue, il faut quand même bien dissocier les différentes utilisations du parallélisme et les besoins.
Par exemple, pour tout ce qui est calcul parallèle hautes performances, je trouve C/C++/Fortran plutot adaptés car ils permettent un contrôle assez fin du code.
Mais il ne faut pas oublier Cuda et OpenCL (via C ou C++) pour tout ce qui est calcul/algo sur GPU.

**Luckyluke34** · 24/05/2011, 13h54

J'aurais tendance à dire un langage purement fonctionnel, étant donné que l'aspect thread-safe et l'absence d'effets de bord favorise la parallélisation.