Discussion :

[Gordon Fowler]

La loi de Moore est elle encore pertinente ?
Plus pour les CPU, répond un responsable de Nvidia qui appelle au développement de la programmation parallèle


Bill Dally est un des ingénieurs les plus importants de Nvidia.

Dans une tribune publiée dans le magasine Forbes, l'ingénieur en chef doute fortement que la loi de Moore puisse encore s'appliquer aux processeurs (CPU) : « Les performances des CPUs ne peuvent plus doubler tous les 18 mois », constate-t-il, « et cela va poser un grave problème à de nombreuses industries qui reposent sur cette croissance des performances ».

Optimiste, Bill Dally en tire cependant une raison d'espérer « La bonne nouvelle, c'est que […] la programmation parallèle peut relancer la loi de Moore et fournir une nouvelle base pour la croissance et l'innovation commerciale ».

Le scientifique sait cependant qu'il ne suffit pas de dire « y'a qu'à » pour que les choses se fassent.

« Le défi pour l'industrie va être d'abandonner des pratiques vieilles de plusieurs dizaines d'années et de s'adapter à cette nouvelle plateforme […] il existe une énorme résistance au changement ».

Cette résistance ne viendra pas, d'après lui, que des fondeurs.

Elle touchera aussi les développeurs. Surtout par manque de formation, précise-t-il. « Convertir la quantité gigantesque de programmes séquentielles (NDR : ou linéaires) existant pour les faire tourner sur une architecture parallèle est une formidable tache, qui est rendue encore plus difficile par la pénurie de programmeurs formés à la programmation parallèle ».

La programmation dite linéaire consiste à exécuter les instructions les unes après les autres pour obtenir un résultat souhaité. La programmation parallèle consiste au contraire à décomposer les tâches pour les faire exécuter simultanément par différents CPU. On comprend aisément le gain de vitesse que peut représenter ce modèle.

Mais les problèmes posés sont nombreux. Comme le note Lainé Vincent « toutes les tâches ne peuvent pas être parallélisées […]. De manière générale, celles qui peuvent être threadées, peuvent être parallélisées. Il existe cependant quelques exceptions ». Les choses ne seront donc pas si simples à mettre en place.

Bref, « après 40 ans de programmation linéaire […] une rupture avec les pratiques de longue date » serait devenue plus que nécessaire.

Mais qu'on se rassure, il ressort de cette interview que la loi de Moore n'est pas (encore) de l'histoire ancienne.


Source : La tribune de Bill Dally dans Forbes


Lire aussi :

Introduction à la programmation parallèle par Lainé Vincent

NVIDIA travaille étroitement avec Microsoft, pour préparer une nouvelle technologie de processeurs graphiques pour les calculs parallèles
Microsoft se paye Interactive Supercomputer, spécialiste du calcul parallèle

Les rubriques (actu, forums, tutos) de Développez :

Hardware

Et vous ?

Etes-vous d'accord avec cette analyse ou pensez-vous au contraire que la Loi de Moore est d'ores et déjà à mettre au musée de l'Histoire Informatique ?

Les développeurs francophones sont-ils suffisamment formés à la programmation parallèle ?

[Invité]

Etant donné que l'on va vers des archi type cloud (on va dire que le gros du travail est fait sur les serveurs, type web), le multi threading n'est pas obsolète ? Etant donné qu'on va être dans un cas ou des serveurs lancent en même en parallèle des applications linéaires, du coup au niveau performance ça revient au même.

je m'étais renseigné pour savoir si sur une appli asp.net il était utile de faire du multithreading mais au final les réponses étaient plutot négatives : le serveur s'en charge.

Après j'ai peut-être louppé quelques choses.

[B.AF]

Etant donné que l'on va vers des archi type cloud (on va dire que le gros du travail est fait sur les serveurs, type web), le multi threading n'est pas obsolète ? Etant donné que on va être dans un cas ou des serveurs lancent en même en parallèle des applications linéaires, du coup au niveau performance ça revient au même.

je m'étais renseigné pour savoir si sur une appli asp.net il était utile de faire du multithreading mais au final les réponses étaient plutôt négatives : le serveur s'en charge.

Après j'ai peut etre louppé quelques chose.

Oui,tu développes sur un niveau trop élevé.

Aujourd'hui la plupart des développements sont linéaires :

Si je dois faire la vente d'un produit en stock,
En linéaire, tu vas :
- Enregistrer la vente
- Chercher le stock
- Recalculer le stock
- Comptabiliser la vente

MT ou parallélisé cela revient à dire, je peux chercher le stock et le calculer pendant que j'enregistre, et au join des tasks, j'aurai les éléments pour comptabiliser.

[daimoc]

En même temps la loi de Moore c'est le doublement du nombre de transistors des microprocesseurs tous les plus ou moins 18 mois.
Pour suivre cette loi on a du mal à faire des cœurs d'exécution plus gros et efficaces, du coup la solution : on rajoute des cœurs d'exécution et du cache .

Jusqu'au début des années 2000, le doublement du nombre des transistors s'accompagnait d'une augmentation systématique la puissance de calcul pour tous les programmes par l'amélioration du cœur d'exécution.
C'est plus le cas avec les multicoeurs , donc pour pouvoir exploiter tous ces transistors pas d'autre solution que la programmation parallèle ...

[Invité]

Oui,tu développessur un niveau trop élevé.

Aujourd'hui la plupart des développements sont linéaires :

Si je dois faire la vente d'un produit en stock,
En linéaire, tu vas :
- Enregistrer la vente
- Chercher le stock
- Recalculer le stock
- Comptabiliser la vente

MT ou parallélisé cela revient à dire, je peux chercher le stock et le calculer pendant que j'enregistre, et au join des tasks, j'aurai les éléments pour comptabiliser.

Justement par rapport à ce que tu dis, imaginons un environnement avec un serveur où il y a 4 demandes en même temps pour la vente d'un produit.

Version linéaire :
proc1 : enregistre,cherche,recalcule,compte
proc2 : enregistre,cherche,recalcule,compte
proc3 : enregistre,cherche,recalcule,compte
proc4 : enregistre,cherche,recalcule,compte

Version parallèle :

proc1 : enregistre,enregistre,enregistre,enregistre
proc2 : cherche,cherche,cherche,cherche
proc3 : recalcule,recalcule,recalcule,recalcule
proc4 : compte,compte,compte,compte


C'est simplifié mais en gros c'est ça, donc les 4 demandes de vente prennent le même temps

[sparthane777]

Justement par rapport à ce que tu dis, imaginons un environnement avec un serveur où il y a 4 demandes en même temps pour la vente d'un produit.

Version linéaire :
proc1 : enregistre,cherche,recalcule,compte
proc2 : enregistre,cherche,recalcule,compte
proc3 : enregistre,cherche,recalcule,compte
proc4 : enregistre,cherche,recalcule,compte

Version parallèle :

proc1 : enregistre,enregistre,enregistre,enregistre
proc2 : cherche,cherche,cherche,cherche
proc3 : recalcule,recalcule,recalcule,recalcule
proc4 : compte,compte,compte,compte


C'est simplifié mais en gros c'est ça, donc les 4 demandes de vente prennent le même temps

Et pour optimiser les performances et la rapidité, quelle méthode est la plus adaptée ?

[Invité]

J'aurais limite tendance a dire la version linéaire : le proc n'est jamais en attente de la fin d'une tache vu qu'elles sont faites dans l'ordre donc pas de temps proc perdu.

[B.AF]

Justement par rapport à ce que tu dis, imaginons un environnement avec un serveur où il y a 4 demandes en même temps pour la vente d'un produit.

Version linéaire :
proc1 : enregistre,cherche,recalcule,compte
proc2 : enregistre,cherche,recalcule,compte
proc3 : enregistre,cherche,recalcule,compte
proc4 : enregistre,cherche,recalcule,compte

Version parallèle :

proc1 : enregistre,enregistre,enregistre,enregistre
proc2 : cherche,cherche,cherche,cherche
proc3 : recalcule,recalcule,recalcule,recalcule
proc4 : compte,compte,compte,compte


C'est simplifié mais en gros c'est ça, donc les 4 demandes de vente prennent le même temps

Non ça c'est l'inverse strict de la logique d'une programmation paralléle !


Ce qui est important à comprendre c'est qu'en déléguant des tâches, tu peux faire une vraie distribution donc faire des domaines fonctionnels cohérents et t'appuyer sur des technologies qui seraient inaccessibles en linéaire.

Là ton exemple ne tient pas compte de l'aspect transactionel ni de la gestion des tâches.

Donc désolé, mais copie à revoir !

Pourquoi ? Parce que tu es justement tombé dans le travers du programmeur 'linéaire' qui se dit que le parallèle est un morcellement du linéaire ou une délégation spécialisé. Or non justement ! Le parallèle c'est une distribution.

[laflak]

J'aurais limite tendance a dire la version linéaire : le proc n'est jamais en attente de la fin d'une tache vu qu'elles sont faites dans l'ordre donc pas de temps proc perdu.

Roohhhh pessimiste. En parallèle il y a pas de temps perdu. Il y a du temps gratuit.
Quand un proc est pas utilisé tu lui fais faire des trucs qui potentiellement pourront être utile pour la suite.

(Je précise que je n'y connais rien en programmation parallèle, c'était juste une idée comme ça)

Cordialement,
Moi

[Invité]

Non ça c'est l'inverse strict de la logique d'une programmation paralléle !


Ce qui est important à comprendre c'est qu'en déléguant des tâches, tu peux faire une vraie distribution donc faire des domaines fonctionnels cohérents et t'appuyer sur des technologies qui seraient inaccessibles en linéaire.

Là ton exemple ne tient pas compte de l'aspect transactionel ni de la gestion des tâches.

Donc désolé, mais copie à revoir !

Pourquoi ? Parce que tu es justement tombé dans le travers du programmeur 'linéaire' qui se dit que le parallèle est un morcellement du linéaire ou une délégation spécialisé. Or non justement ! Le parallèle c'est une distribution.

Peux-tu être plus explicite ? J'ai déjà fait un peu de programmation parallèle, mais je ne vois pas ce que tu veux dire par "domaines fonctionnels cohérents", "transactionnel" ,"gestion des taches" ou "le parallèle c'est une distribution".

Tu me dis que mon exemple est faux , je veux bien, mais stp dit moi pourquoi il est faux, comment se comporte les processeur (ou cœur), et en quoi répartir des éléments d'une taches plutôt que les taches elles mêmes fait gagner du temps.

merci

[Franck SORIANO]

Justement par rapport à ce que tu dis, imaginons un environnement avec un serveur où il y a 4 demandes en même temps pour la vente d'un produit.

Version linéaire :
proc1 : enregistre,cherche,recalcule,compte
proc2 : enregistre,cherche,recalcule,compte
proc3 : enregistre,cherche,recalcule,compte
proc4 : enregistre,cherche,recalcule,compte

Version parallèle :

proc1 : enregistre,enregistre,enregistre,enregistre
proc2 : cherche,cherche,cherche,cherche
proc3 : recalcule,recalcule,recalcule,recalcule
proc4 : compte,compte,compte,compte


C'est simplifié mais en gros c'est ça, donc les 4 demandes de vente prennent le même temps

Ce que B.AF suggérait c'était :

Version linéaire :
- proc1 : enregistre, cherche, recalcule, compte

Version Parallèle :
- proc1 : enregistre
- proc2 : cherche, recalcule
Lorsque proc1 et proc2 ont terminé :
- proc3 : compte

Dans la version linéaire, tu as la réponse en 4 temps.
Dans la version parallèle, seulement en 3 temps.

Du moins c'est la théorie, qui serait à peu près vrai à faible charge (si la machine n'a qu'une seule transaction à traiter, ou si tu fais du calcul lourd pour un seul utilisateur).

Mais sur un serveur, lorsque la charge augmente et que le serveur doit traiter un grand nombre de transactions simultanées, tu as un problème de files d'attentes qui se rajoute :
Tu n'as pas suffisament de processeurs pour traiter immédiatement toutes les opérations de chaque transactions.
- Donc dans la version linéaire : Tu fais la queue une fois. Ton tour arrive sur le CPU, tu fais tes 4 opérations et tu as la réponse.
- Dans la version parallèle, tu prends une première file d'attente pour le proc1 et tu exécutes les deux opérations. En même temps, tu prends une deuxième file d'attente pour le proc2 et tu fais ton opération. Une fois que les deux ont terminé (donc tu gardes la plus grande des deux durées : Attente1 + operation 1 + operation 2, Attente 2 + Opération 3), tu prends une troisième file d'attente pour avoir le processeur et exécuter la dernière opération.
Donc tu passes de 1 attente + 4 opérations à 2 attentes + 3 opérations.

Sachant que lorsque la charge augmente, la durée des opérations ne changent pas, mais les temps d'attentes augmentent avec la longueur des files...

Et pour couronner le tout, une fois que tu as obtenu le CPU, tu peux avoir besoin d'autres ressources pour effectuer ton traitement (par exemple des accès disques ou réseau)... C'est alors que surviennent les risques de blocages et de famines...

C'est toute la difficultée de la programmation parallèle, on ne peut pas découper n'importe quoi n'importe comment pour obtenir de meilleures performances. Il faut trouver la bonne architecture de découpage, et le bon ordonnencement des traitements.

J'aurais limite tendance a dire la version linéaire : le proc n'est jamais en attente de la fin d'une tache vu qu'elles sont faites dans l'ordre donc pas de temps proc perdu.

C'est plus compliqué que ça.
Car en fait, même dans la version linéaire, tu vas faire des I/O (accès disques, réseaux...). Donc le processeur va être bloqué en attente des résultats.
Avec un minimum de parallélisme, le processeur pourrait être utilisé pour faire autre chose. Par exemple, commencer les calculs d'une autre transaction...

Donc il n'y a pas de réponse évidente à la question. Il faut savoir ce qu'on fait et ce qui se passe dans les traitements pour établir l'architecture qui donnera les meilleurs résultats :
- En termes de temps de réponse.
- En termes d'utilisation des ressources (charger au maximum les CPU pour qu'ils ne soient pas à se tourner les pouces alors qu'il y a des traitements en attente).

[sparthane777]

Car en fait, même dans la version linéaire, tu vas faire des I/O (accès disques, réseaux...). Donc le processeur va être bloqué en attente des résultats.
Avec un minimum de parallélisme, le processeur pourrait être utilisé pour faire autre chose. Par exemple, commencer les calculs d'une autre transaction...

Il y a pas les protocoles IRQ qui se chargent des périphériques ?

[davrous]

Etant donné que l'on va vers des archi type cloud (on va dire que le gros du travail est fait sur les serveurs, type web), le multi threading n'est pas obsolète ? Étant donné qu'on va être dans un cas ou des serveurs lancent en même en parallèle des applications linéaires, du coup au niveau performance ça revient au même.

Je m'étais renseigné pour savoir si sur une appli asp.net il était utile de faire du multithreading mais au final les réponses étaient plutôt négatives : le serveur s'en charge.

Après j'ai peut-être loupé quelques choses.

Hello,

C'est une remarque que j'entends souvent étant en charge de la relation technique avec les développeurs chez Microsoft sur les technologies Web & Cloud. Pourtant, même un développeur Web a intérêt à s'intéresser au développement parallèle pour toutes les bonnes raisons déjà citées dans ce thread. En effet, un développeur Web aura 2 choix dans une architecture Cloud pour gérer des pics de charge/améliorer les performances de son appli :

1 - augmenter le nombre de serveurs dédiés à son application en laissant la plateforme (ex: Windows Azure) lui attribuer davantage de ressources
2 - revoir son code et voir comment mieux tirer parti du hardware en analysant les sections parallélisables

L'avantage du point 2 est qu'il devrait lui couter moins cher en consommation/hosting s'il se débrouille bien. Ensuite, plus tard, une fois l'ensemble optimisé, il pourra envisager l'option 1 pour laquelle le cloud a été conçu. Sinon, il peut toujours opter pour la solution de facilité, mais elle va lui couter plus cher et son employeur ne va peut-être pas apprécier.

Les développeurs Web pensent souvent que le // n'est pas fait pour eux car ils assistent à des démos de calculs de Raytracing ou autres calculs complexes qui ont l'avantage d'être facilement parallélisable et très visuels pour faire comprendre aux gens l'avantage de ce mode de programmation. Effet pervers: on se sent moins concerné. Alors que l'on pourrait imaginer paralléliser des traitements sur la couche d'accès aux données, du traitement d'image côté serveur, des recherches en mémoire/base, etc. Mais bon, c'est sûr que ça en jette moins qu'un lancer de rayon avec des réflexions dans tous les sens! ;-)

Pour revenir sur l'ensemble du thread, je suis d'accord sur le fait que cela fait longtemps que les concepts // existent. Mais jusqu'à présent, ils étaient confinés à des usages et une population très réduite et spécifique. Le défi est de rendre accessibles ces concepts à la masse. Il aura donc un gros boulot d'éducation/formation mais également le besoin d'outillage et de nouveaux frameworks. Par exemple, chez nous, .NET 4.0/VS 2010 a eu un gros focus sur la simplification du développement //. Bien sûr, comme vous l'avais dit, il ne suffira pas de mettre ".EnableParallel = true;" pour bénéficier magiquement de tous les coeurs. Mais sur certaines parties, comme LINQ et son pendant P/LINQ, rendre // un parcours de fichier XML ou une collection en mémoire devient super simple. Il y a donc certainement une partie de la réponse du côté des frameworks. Il me semble d'ailleurs qu'il y a quelque chose dans le pipe pour la prochaine version de Java aussi. Nous avons également constaté (d'expérience!) que le debbuging d'applications fortement multi-threadées ou multi-tâches était un vrai cauchemar. Le simple fait de s'attacher à l'application changeant son état et empêchant de reproduire le bug pour le corriger... De ce côté-là, VS 2010 a également revu le debugger et il y a des projets de recherches innovant chez nous. Il s'appelle Chess : http://research.microsoft.com/en-us/projects/chess/ et vous pouvez trouver un bout d'explications en FR ici : http://blogs.msdn.com/ericmitt/archi...-et-chess.aspx

Pour terminer, vous avez oublié d'évoquer il me semble que la programmation parallèle va plus loin que la meilleure utilisation des CPUs multi-coeurs x86. Il va falloir également mieux utiliser en // les énormes capacités de traitement que nous offrent les GPUs et autres puces spécialisées. DirectX 11 apporte une première réponse de ce côté-là. Mais on pourrait imaginer un framework de haut niveau capable de distribuer les tâches sur les différentes puces en fonction de leur spécialisation.

Donc la loi de Moore est bien morte, mais on savait depuis longtemps que cela arriverait.

Bref, la programmation parallèle s'avère particulièrement passionnante et va tous nous faire bosser dans les années qui viennent avec le Cloud computing également. Profitez de votre prise de conscience avant-gardiste. Cette compétence va vite devenir critique sur le marché !

Bye,

David
PS : un membre de mon équipe anime un blog sur ce sujet : http://blogs.msdn.com/devpara/

[trashyquaker]

Comme le note Lainé Vincent [I]« toutes les tâches ne peuvent pas être parallélisées […].

Oui... J'avais un prof qui avait sorti un truc assez drôle à ce sujet:
Une femme a besoin de 9 mois de grossesse pour faire un bébé. Vous avez beau mettre 9 femmes sur cette tâche, elles n'arriveront pas à faire un bébé en 1 mois.

[sparthane777]

" qui est rendue encore plus difficile par la pénurie de programmeurs formés à la programmation parallèle"

Y as pas des formations pour ça ? Je suis pas sur d'avoir compris ce que ça signifie

"Etes-vous d'accord avec cette analyse ou pensez-vous au contraire que la Loi de Moore est d'ores et déjà à mettre au musée de l'Histoire Informatique ?"

Je suis désolé mais je suis pas d'accord avec vous. La loi de Moore certes s'avère être dépassée mais restera quand-même la base de la technologie des processeurs : voir ici et ici

Enfinsi une loi remplace celle de Moore, ça restera quand même dans l'histoire de l'informatique. C'est pas pasque l'informatique évolue en permanence qu'il faut négliger son histoire

[Pomalaix]

La loi de Moore certes s'avère être dépassée mais restera quand-même la base de la technologie des processeurs : voir ici et ici

Bonjour

Je trouve assez extraordinaire d'arriver à justifier une phrase qui ne veut rien dire par un lien d'une extrême qualité ! (Grand merci pour ce lien).
1) parler de "loi de Moore", ça a à peu près autant de sens que de parler de "loi d'Elisabeth Teissier". Il ne s'agit de rien de plus que d'une conjecture, d'une prédiction, d'une prévision.
2) l'article explique que cette prédiction (pour peu qu'on trouve un consensus sur sa signification) a globalement toujours été fausse
3) comment peut-on dire qu'une prédiction, serait "à la base de la technologie des processeurs", alors que cette technologie existait avant le prédiction, et que la prédiction s'est révélée fausse ??

[Invité]

Oui... J'avais un prof qui avait sorti un truc assez drôle à ce sujet:
Une femme a besoin de 9 mois de grossesse pour faire un bébé. Vous avez beau mettre 9 femmes sur cette tâche, elles n'arriveront pas à faire un bébé en 1 mois.

Je suis d'accord avec ça. Le parrallélisme est un voeu pieux dans de nombreux cas.

La "parrallélisation" d'algoritmes parfaitement maîtrisés en monothread fait un usage important de boucles d'évenements et de communications. Le résultat est souvent illisible et l'avantage peu évident. Dès que le résultat d'une itération est utilisé dans la suivante, on est comdamné au monothread. C'est particulièrement vrai dans les applicatifs spécifiques. Peu de programmes doivent gérer trois devices en même temps. La plupart du temps, le monothread et sa synchronicité sont quasi-incontournables.

[sparthane777]

Bon j'ai été sur votre thread "Introduction à la programmation parallèle " mais bon c'est pour les gens calés en dotnet et comme mordicus j'aime pas les langages de Microsoft, ça va être difficile de se motiver pour s'y initier.

Ok je vais chercher d'autres tutoriels en ligne sur d'autres langages et je vous tiens au courant

[B.AF]

Oui... J'avais un prof qui avait sorti un truc assez drôle à ce sujet:
Une femme a besoin de 9 mois de grossesse pour faire un bébé. Vous avez beau mettre 9 femmes sur cette tâche, elles n'arriveront pas à faire un bébé en 1 mois.

En fait c'est à la base une phrase peu flatteuse pour les informaticiens d'un ingénieur allemand (Wernher von Braun) et qui est :

Les logiciels plantent car ils se basent sur la théorie qu'avec neuf femmes enceintes vous pouvez avoir un bébé en un mois.

C'est le père de la fusée V2, et malgré son passé de SS, il est mort ...administrateur de la Nasa.

La référence n'est pas très glorieuse. Ce mec avait son usine de V2 à Dora, et a reconnu 25 ans plus tard avoir construit grâce aux "esclaves" (je ne trouve pas le mot juste) pris dans le camp de buchenwald entre autres.

C'est aussi lui le concepteur du moteur qui a propulsé le controversé premier homme à avoir mis le pied sur la lune.

Une pourriture réhabilitée pour ses connaissances scientifiques, mort avec les honneurs, et un parfait exemple de l'absolution capitaliste.

Je ne voulais pas faire un godwin, mais juste à relater l'histoire pas si anodine de cette phrase.

[publicStaticVoidMain]

[B][SIZE="4"]
Dans une tribune publiée dans le magasine Forbes, l'ingénieur en chef doute fortement que la loi de Moore puisse encore s'appliquer aux processeurs (CPU) : « Les performances des CPUs ne peuvent plus doubler tous les 18 mois », constate-t-il, « et cela va poser un grave problème à de nombreuses industries qui reposent sur cette croissance des performances ».

Je n'ai pas envie de lancer un débat trollesque mais je trouve que cet article n'est pas assez clair sur certains points.
Déjà la définition de la loi de Moore n'est pas exacte. L'auteur en donne une définition précise :

The backdrop to this issue is a paper written by Gordon Moore, the co-founder of Intel ( INTC - news - people ). Published 45 years ago this month, the paper predicted the number of transistors on an integrated circuit would double each year (later revised to doubling every 18 months). This prediction laid the groundwork for another prediction: that doubling the number of transistors would also double the performance of CPUs every 18 months.

Elle stipule que c'est le nombre de transistors sur un circuit intégré qui doublera tous les 18 mois pas la performance du CPU. L'augmentation de la performance CPUs n'est qu'une conséquence directe de la loi Moore.
Aujourd'hui, on constate que bien que la vitesse des CPU a baissé mais le nombre de transitors que l'on met sur un circuit a augmenté.

La programmation dite linéaire consiste à exécuter les instructions les unes après les autres pour obtenir un résultat souhaité. La programmation parallèle consiste au contraire à décomposer les tâches pour les faire exécuter simultanément par différents CPU. On comprend aisément le gain de vitesse que peut représenter ce modèle.

Programmation dite "linéaire"??? Tu parles de la programmation batch?? Cela fait plusieurs années (> 20) que l'on fait du temps partagé. Cela plusieurs années que les processeurs peuvent lire des blocs d'instruction.
Il est bien possible de faire la programmation parallèle sur une architecture monocoeur. Sinon les librairies développées en C (pthread), en ou java (java.lang.Runnable) ou dans n'importe quel langage n'aurait pas lieu d'etre.

Elle touchera aussi les développeurs. Surtout par manque de formation, précise-t-il. « Convertir la quantité gigantesque de programmes séquentielles (NDR : ou linéaires) existant pour les faire tourner sur une architecture parallèle est une formidable tache, qui est rendue encore plus difficile par la pénurie de programmeurs formés à la programmation parallèle ».

Je ne sais pas pour d'autres, mais moi à la fac, j'en fais. On développe meme sur la PS3 pour faire des calculs matriciels.