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 ...

[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

[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.

[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.

[sparthane777]

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.

Enfin de toute façon c'est l'ordonnanceur qui gère tout ça non ?

[FR119492]

Bonjour à tous!

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

De toute manière, il n'est possible de former qu'aux techniques actuelles, mais une bonne formation est celle qui donne la possibilité, par la suite, de maîtriser les techniques futures. Je programme depuis 49 ans, mais, pour mes 70 ans, je me mettrai à la programmation parallèle, promis, juré...
Jean-Marc Blanc

[sparthane777]

Bonjour à tous!

De toute manière, il n'est possible de former qu'aux techniques actuelles, mais une bonne formation est celle qui donne la possibilité, par la suite, de maîtriser les techniques futures. Je programme depuis 49 ans, mais, pour mes 70 ans, je me mettrai à la programmation parallèle, promis, juré...
Jean-Marc Blanc

En fait ce qui serait idéal c'est pouvoir effectivement comme vous dites découvrir les nouveautés, c'est d'ailleurs mon dada en info. Seulement comme ça évolue trop rapidement on peut pas tout maîtriser. Là je lis plusieurs articles sur le Web et je suis surpris de voir à quel point ça avance.
Faut dire que je m'intéresse à beaucoup de choses, mais il est très dur de maîtriser toutes les technologies

[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

[Naquada]

Ne serait-il pas plus rentable de travailler sur un ordonnanceur qui permette d'optimiser en "live" la gestion des différents coeurs ?

Je suis pleinement conscient de la complexité de la chose, mais je ne pense pas que cela soit impossible.

[sparthane777]

Ne serait-il pas plus rentable de travailler sur un ordonnanceur qui permette d'optimiser en "live" la gestion des différents coeurs ?

Je suis pleinement conscient de la complexité de la chose, mais je ne pense pas que cela soit impossible.

Ça c'est la partie développement, mais je pense qu'il parlait de l'archi du pross. Mais à mon avis on doit y travailler à la R&D