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.

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.