On associe souvent programmation parallèle et programmation asynchrone. C’est  en fait plus compliqué : pour faire (très) court, nous dirons que l’asynchronisme est à voir comme un moyen utilisé dans la  problématique de distribution et de synchronisation des branches de traitement. Nous passerons sur la distinction entre parallèle et concurrent. Un post n’y suffirait pas.

Un acteur majeur de l’IT l’a bien compris : Microsoft est occupé à étoffer ses langages de facilités pour la programmation parallèle.

Mais attention : les difficultés inhérentes à la programmation parallèle rendent cette tâche très complexe et favorable à l’apparition de bugs difficiles à identifier et à corriger. La programmation parallèle n’est certainement pas à mettre entre toutes les mains !

Il faut donc rendre transparent au développeur l’utilisation parallèle des processeurs. En implémentant le parallélisme au cœur du langage, son utilisation se fait à moindre coût et moindre risque.

Sur ce sujet des initiatives nombreuses voient le jour :
– celle de Microsoft déjà citéé, pour ses langages C# et VB, avec la librairie TPL (https://msdn.microsoft.com/fr-fr/vstudio/async.aspx)
– le laboratoire Programming Methods Laboratory de l’EPFL, à l’origine de Scala, a  obtenu un financement sur cinq ans de l’union Européenne, afin de soutenir le développement de Scala et notamment son utilisation dans la programmation parallèle.
– le framework Java JPPF (www.jppf.org – www.parallel-matters.com), pour la programmation parallèle distribuée
– le plugin DPJizer pour Eclipse

Dans le cadre de la problématique de scalabilité, il pourrait être utile d’évaluer l’intérêt pour un framework tel que JPPF (à discuter avec la cellule architecture).

Pour conclure, devrons-nous investir sur la programmation parallèle ou, comme par le passé, miser sur les gains de performance des processeurs émanant de la loi de Moore?

Deux éléments de réponse. La loi de Moore ne sera  sans doute pas éternellement valable (aux dires mêmes de son auteur) – ceci étant dit, le recours aux nanotechnologies ⁽¹⁾  [dont l’horizon d’industrialisation en micro éléctronique reste difficile à prévoir] pourrait lui donner un second souffle. Plus important les préoccupations liées au Green IT vont demander d’améliorer la performance énergétique des centres de calcul. Ceci pourrait demander de renoncer à la recherche de puissance par augmentation de la fréquence des processeurs … en se penchant sur l’intérêt de la programmation parallèle. Avec peut-être alors un intérêt pour le langage Scala.

⁽¹⁾ dans lesquelles deux voies sont explorées : l’approche classique dite top-down, par gravure, et que l’on continue à tenter de maximiser – l’approche nouvelle dite bottom-up, par assemblage de matière (au niveau atomique), et qui va demander à la micro électronique de s’intéresser bien davantage aux connaissances fondamentales en physique et chimie