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

Partagez vos retours d'expérience

Le 2011-05-23 10:21:20, par dourouc05, Responsable Qt & Livres

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 !

Discussion forum

70 commentaires

Joel F
Membre chevronné

Envoyé par gbdivers

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.

le 24/05/2011 à 16:07
lapinferoce
Membre à l'essai

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

le 24/05/2011 à 8:48
Alp
Expert éminent sénior

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

le 25/05/2011 à 10:37
Traroth2
Membre émérite

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.

le 23/05/2011 à 14:37
TropMDR
Membre éprouvé

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

le 23/05/2011 à 16:21
TropMDR
Membre éprouvé

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%

le 23/05/2011 à 17:32
dourouc05
Responsable Qt & Livres

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.

le 23/05/2011 à 17:39
Grimly_old
Membre averti

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.

le 24/05/2011 à 10:31
Joel F
Membre chevronné

concurrence != parallelisme

le 25/05/2011 à 2:26
NicoL__
Membre confirmé

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.

le 25/05/2011 à 11:35

Poster une réponse