Multicore crisis : la crise des multicoeurs

La loi de moore ne reflète plus l’évolution du marché des microprocesseurs.

Les fréquences stagnent, les processeurs voient leur coeurs se multiplier au détriment de l’augmentation de la fréquence :

On parle de multicore crisis, la crise des multi-coeurs.

SmoothSpan, à la suite d’une remarque initale de O’Reilly a pris le sujet très à coeur, si je puis dire. Il a bien raison, et qu’il lui soit rendu hommage.

Le problème de cette crise des multicoeurs, c’est que la façon dont on écrit la plupart des codes informatiques repose sur des processeurs ne disposant que d’un seul coeur, voire quelques coeurs, mais pas plus. Cela va donc changer si l’on regarde la road map des fondeurs.
C’est toute l’industrie logicielle qui est potentiellement menacée, à plus ou moins long terme bien sûr. Pour certains, cela peut aller très vite ; c’est comme si, lancé à 200 km/h sur l’autoroute, vous aperceviez tout à coup un panneau qui vous dit « Virage à Gauche dans 50 m » !

De fait, les logiciels actuels commencent à partir dans le décor. Il ne sont pas faits pour exploiter les processeurs multi-coeurs qui arrivent sur le marché depuis quelques mois. Cela tient la route avec le nombre de coeurs actuels où le problème n’est pas encore extrèmement critique, mais au-delà 16-20 coeurs, comment va-t-on faire ?

L’aspect procédural des langages de programmation actuels est directement mis en cause. Un programme qui dit : « tu fais çà puis çà et ensuite çà », ne dit pas qui le fait, et comment l’exécution des tâches doit être répartie et éclatée sur x processus possédant y coeurs.

On peut bien sûr spécifier « en dur » des logiciels pour qu’ils exploitent des processeurs multi-coeurs. Écrire des programmes qui tirent partie de plusieurs coeurs de processeurs est une chose, mais que va-t-il se passer quand le nombre de processeurs multiplié par le nombre de coeurs va être à la fois très important et en même temps indéterminé ? Comment va tourner mon logiciel calibré pour 8 coeurs avec 64 coeurs ?
Les solutions logicielles centralisées, et ne disposant que d’une seule instance pour l’ensemble des utilisateurs (en mode Software as a Service donc), sont bien sûr très gourmandes en ressources de calcul, et ce n’est pas un hasard si ce sont les acteurs du SaaS qui vont être les plus sensibles à cette crise des multi-coeurs.

Une solution pourrait être l’utilisation de langages de programmation prennant en considération le parallel computing, donc la présence de processeurs multi-coeurs.
On parle de programmation parallèle lorsqu’il faut réaliser plusieurs tâches en même temps, c’est pour cela que l’on parle de plus en plus d’Erlang (Erlang pour Ericsson language, origine telecom donc), langage de programmation fonctionnel et concurrent capable de paralleliser des tâches et donc d’exploiter les possibilités offertes par les processeurs multi-coeurs.

J’attends avec impatience le bouquin Programming Erlang commandé récemment sur Amazon, mais je crois déjà comprendre que l’apprentissage du langage n’est pas une sinécure, et beaucoup semblent s’en plaindre.

Le Dataflow est-il une porte de sortie ?

Le Dataflow, tout le monde connaît. Les formules que nous utilisons dans nos tableurs ne s’activent que lorsque qu’une cellule utilisée par la formule est modifiée. Avec le Dataflow il n’y a pas d’ordre strict dans l’exécution générale des étapes du traitement de l’information. Et l’on sort ainsi de l’aspect procédural et linéaire de la plupart des langages de programmation qui les rend ineptes à l’exploitation des processeurs multi-coeurs.

Le Dataflow, c’est aussi le principe qui est utilisé dans le pipe des shell ainsi que dans Yahoo Pipe. Autre intérêt pour moi, le Dataflow utilise un schéma de modélisation de type Directed Graph (et çà vous fait penser à quoi ? Voir plus bas)
Parmi les acteurs de l’industrie logicielle du Dataflow il faut souligner un des plus important : Labview, qui utilise le Dataflow avec de la programmation via interface graphique. (Labview qui se réjouit de cette crise des multicoeurs car ils peuvent récupérer un marché gigantesque)

Il faut toutefois remarquer que les approches de type Dataflow sont bien adaptées à la manipulation des nombres, mais moins à l’aise dès qu’il s’agit de manipuler des textes.

Qu’à cela ne tienne, la cerise sur la gateau arrive.
Le lien n’a toujours pas été fait explicitement par ceux qui ont commencé à réfléchir à la crise des mutli-coeurs, mais les normes du web sémantique, et là avec OWL et les moteurs d’inférence en plus de RDF, sont dans l’axe direct du Dataflow comme issue de secours aux enjeux posés par la crise des multi-coeurs.

Le Web n’est pas fait pour les processus, mais pour les flux avec une approche orientée évennementiel. Et si le Web sémantique est la réponse aux enjeux majeurs de l’industrie logicielle dès quelle aborde le « cloud-computing », je ne vais pas m’en plaindre.

Un sujet, intéressant qui impacte déjà les développeurs :
http://code.google.com/p/google-web-toolkit/issues/detail?id=1589

[Reply]

[…] Du point de vue de la programmation et du développement, ces interfaces placent selon moi la programmation événementielle sur le devant de la scène (Data FLow). Et l’Action Script d’Adobe a certainement de beaux jours devant lui. L’utilisateur devra traiter des signaux informationnels qui arrivent de manière distribué, par plusieurs canaux, puis réagir à ces événements. Mais on ne vire dans la dimension ludique que si l’attention de l’utilisateur est en permanence stimulée par des événements vis à vis desquels on doit réagir et prendre des décisions. Pour cela il faut que l’information arrive sous forme d’un flux qui accapare notre attention. Mais que l’information deviennent un flux, çà on commence à s’y habituer avec les flux RSS. Il y aura bien sûr différents niveaux de complexité. C’est ici comme dans un jeu d’échec : plus une information va modifier le contexte de la “partie”, plus la réaction de l’utilisateur nécessitera de la réflexion. […]

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.