Discussion :

[Traroth2]

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.

Pas dans des langages comme Erlang ou Lisp, ni en C si on utilise MPI mais pas OpenMP. Les deadlocks sont clairement un problème spécifique à la programmation parallèle avec mémoire partagée.

[dourouc05]

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.

[Firwen]

S'interroger sur quel est le meilleur langage de programmation parallèle, c'est comme s'interroger sur quel est le meilleur langage de programmation tout court : ça n'a aucun sens.

Il y a des cas d'utilisations, et des langages appropriés à ces cas, la programmation parallèle ne change rien à ça.
Pour un projet où les performances sont critiques ( calcul scientifique ), C++ couplé à OpenMP et MPI fait des miracles.
Pour un projet de haut niveau multi-threadé ou avec un système de com inter-process évolué, Scala ou Erlang n'ont rien à envier aux autres.

Ceci dit, voir un sondage de ce type ne proposant pas Erlang qui est une reference dans le domaine, me choque pas mal .

[Camille_B]

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.

[dourouc05]

S'interroger sur quel est le meilleur langage de programmation parallèle, c'est comme s'interroger sur quel est le meilleur langage de programmation tout court : ça n'a aucun sens.

C'est pour ça qu'il y a un grand espace libre d'expression en-dessous, pour spécifier pourquoi ce choix, dans quels cas il vaut mieux aller dans telle ou telle direction .

Ceci dit, voir un sondage de ce type ne proposant pas Erlang qui est une reference dans le domaine, me choque pas mal .

C'est corrigé, il est apparu dans la liste des langages proposés !

[Firwen]

C'est corrigé, il est apparu dans la liste des langages proposés !

Merci Master Qt

[dourouc05]

Merci Master Qt

N'hésite pas non plus à proposer d'autres ajouts de langages, je ne suis pas du tout expert dans le domaine, il est bien possible que je sois passé à côté de beaucoup d'autres langages très utilisés.

[FloMo]

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]

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]

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 ?) :

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]

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.

[Idwakest]

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]

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.

[octal]

Votre sondage oublie un langage extrêmement important (et pionnier)... OCCAM
il a été spécialement conçu pour la programmation parallèle sur Transputer et met en oeuvre directement les concepts de programmation CSP

http://en.wikipedia.org/wiki/Occam_(...ming_language)

[dourouc05]

Votre sondage oublie un langage extrêmement important (et pionnier)... OCCAM
il a été spécialement conçu pour la programmation parallèle sur Transputer et met en oeuvre directement les concepts de programmation CSP

Ajouté !

[Joel F]

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)

Alors:

- connaitre par coeur son ISA/DIE ne sert pas beaucoup mais savori qu'est-ce qu'un cache, qu'on a ou pas de ISA SIMD sur son proc, connaitre le sproblematiques de false sharing, etc est plus qu'utile. Je ne compte plus les projets de recherches ou des missions "experts" ou j'ai empoché 10k pour inverser 3 boucles, rendre le cache content et obtenir x50

- C/C++ sont vraiment dans le meme bateau. Les gens qui pensent que C++ est lent sont des gens qui ne savent pas programmer en C++ ou, du moins, restent coller sur c'est que j'appel du JAVA++ plein de virtual et de new.

- Quelque soit le langage, les algos, les algos , les algos. On parallelisent rarement du O(N^4), on cherche le O(N^?) avec ? < 4 PUIS on parallelise.

Pour repondre au problematique des langages fonctionnels, Haskel est pas degeu, tout comme les variantes compilables de ML. Ca reste rude car peu de gens n'ont l'habitude de reflechir dans ce paradigme.

[Ubiquité]

J'ai voté C et C++ pour le GPGPU et l'utilisation d'instruction particuliére, comme les SIMD. Et Haskell et Erland pour le reste (multithreading au dessus de l'os & co)

[Heimdall]

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.

[tomlev]

Bon, mon avis est un peu biaisé, mais je dirais C#, depuis la 4.0, avec la Task Parallel Library qui permet de faire des choses vraiment propres...
Et C# 5.0 intègrera directement dans le langage la gestion des traitements asynchrones, ce qui permettra de faire du parallélisme beaucoup plus facilement (cette fonctionnalité est actuellement en CTP). Voir cet article pour plus de détails

[Joel F]

concurrence != parallelisme