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

**dourouc05** · 07/05/2015, 09h07

Quatre ans après le dernier sondage, comment vos positions ont-elles évolué concernant le meilleur langage pour la programmation parallèle ? Deux langages s'étaient tirés du lot — C et C++ —, largement plus haut que vénérable mais toujours très présent Fortran ; ensuite venaient Java et C#, deux langages de bien plus haut niveau.

Depuis lors, de nouveaux langages ont fait leur apparition dans le domaine, comme Julia ; côté Python, le duo NumPy et SciPy continue à se développer et est une alternative de plus en plus sérieuse à des environnements propriétaires comme MATLAB. Aussi, de nouveaux langages sortent des laboratoires pour faciliter le développement en parallèle, comme Charm++, Nim ou encore Chapel. Par contre, les outils de parallélisation que sont MPI et OpenMP restent omniprésents — parfois accusés de tuer le HPC, par manque d'adaptation aux besoins des utilisateurs, contrairement aux technologies rassemblées sous l'ombrelle « big data », comme Apache Hadoop ou Spark.

D'un autre côté, un langage n'est pas la seule partie utile pour un programme parallèle, les accélérateurs matériels sont de plus en plus fréquents : les GPU sont de plus en plus utilisés par les supercalculateurs du Top500 pour atteindre de telles puissances de calcul (avec l'inconvénient de devoir utiliser d'autres paradigmes de programmation, avec NVIDIA CUDA ou encore OpenCL), Intel contre-attaque avec ses Xeon Phi (des processeurs habituels, mais avec bien plus de cœurs), sans oublier AMD et son HSA (calcul hétérogène : exploiter différents types de matériel, chacun pour ses spécificités) ou encore les FPGA (puces logiques entièrement programmables, sans jeu d'instructions).

Quel langage reçoit vos lauriers ? Pourquoi 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… ?

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 !

**fenkys** · 07/05/2015, 09h43

Une fois de plus, le système de vote refuse d'enregistrer ma réponse.

MikeRowSoft · 07/05/2015, 09h48

Il y en a quand même beaucoup de librairies complémentaires dédiés à la programmation parallèle. Certains langages de bases utilisent les bus systèmes seulement et avec l'ajout d'une librairie par exemple utilisent en plus les supports réseaux pour communiquer d'une "instance" de traitement à l'autre, il passe du système de base au "cluster" puis supercalculateur. De la folie douce comme dirait un de mes anciens surveillant.

P.S.: Le surveillant en question serait sûrement ravi d'ajouter des multimètres électronique sur le bus de communication comme anti-snif ou anti-modchip.

**timidou** · 07/05/2015, 11h42

Erlang à 100%, pourquoi?
Car le langage Erlang utilise le Pattern Matching et le passage de message asynchrone pour plus de simplicité lors de son utilisation sur plusieurs noeud Erlang :-)

**Cr3a_Hal0** · 07/05/2015, 13h08

Autre initiative à OpenMP et MPI : Intel TBB. A ma connaissance ce dernier ne propose pas de répartir la charge à des terminaux distants cependant ce dernier possède une gestion des tasks relativement plus rapide que de simples threads ou que MPI/OpenMP.

j'ai également pu faire un peu d'OpenCL mais après je suppose que l'utilisation de technologies GPGPU est à réserver pour certains types de traitements massifs c'est à dire sans doute pas comme la plupart des applications multithreadées qui ne sont pas orientée multimédias.