Discussion :

[FR119492]

Salut!

Seulement comme ça évolue trop rapidement on peut pas tout maîtriser.

C'est vrai; alors, il faut faire des choix.
Jean-Marc Blanc

[benzoben]

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.

Cela ne sert à rien de paralléliser tes taches "enregistre", "cherche", "recalcule" et "compte" pour un même acheteur puisque chacune de ces tâches est dépendante de la précédente (où alors tu es capable de débiter le compte du mec sans qu'il ait choisi son article ... ce qui est du vol )

Sur un serveur d'application, chaque requête entrante est associée à un thread et chaque thread sera exécuté entièrement sur 1 proc. Dans l'exemple que tu donnes, le développeur n'a rien à gérer.

On parle des développeurs mais moi je pense que tant que les langages n'intègrent pas intrinsèquement la notion de parallélisme dans leur syntaxe, on restera avec une gestion historique et complexe de ce parallélisme.
Plus on abstrait cette notion, plus elle sera utilisée.

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

[sparthane777]

Salut!

C'est vrai; alors, il faut faire des choix.
Jean-Marc Blanc

T'en fait pas pour mes choix mais merci

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

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

[Franck SORIANO]

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'être.

Il n'a jamais été dit que la programmation parallèle était une nouveauté. Bien sûr elle existe depuis l'apparition des traitements interactifs dans l'informatique. A la base c'était pour rentabiliser au mieux les processeurs en servant un autre utilisateur pendant que le premier réfléchissait à ce qu'il voulait faire.

Mais même si elle existe depuis longtemps, elle reste encore assez peu utilisée. Mis à part le système d'exploitation et les drivers de périphériques, la plupart des appli sont purement monotâches.
En grande partie à cause de la difficulté pour paralléliser efficacement un problème séquentiel par nature !
Depuis des années on a amélioré les performances des ordinateurs en faisant des processeurs plus rapides, afin que les traitements séquentiels soient plus performants.

Le sujet de cette discussion, c'est qu'aujourd'hui, les concepteurs des processeurs n'arrivent plus à gagner en performances pures.
Donc pour continuer à avoir des machines plus puissantes, à faire des traitements plus rapidement, il faut faire en sorte de se tourner vers le parallélisme.
Or s'il est assez simple de multiplier les CPU sur un serveur et gérer des transactions indépendantes en parallèle, il est beaucoup plus difficile de découper efficacement une même transaction en éléments parallélisables.

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

[sparthane777]

Or s'il est assez simple de multiplier les CPU sur un serveur et gérer des transactions indépendantes en parallèle, il est beaucoup plus difficile de découper efficacement une même transaction en éléments parallélisables.

Ou beaucoup plus simples, et moins gourmands en ressource que d'utiliser des multicores, mais l'inconvénient reste quand même le prix

[Franck SORIANO]

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

Les IRQ servent à interrompre le traitement en cours sur le processeur pour lui dire qu'un périphérique nécessite son attention.

Dans un fonctionnement parfaitement linéaire et synchrone, si tu dois lire un fichier, il va falloire que tu positionnes la tête de lecture au dessus du cylindre que tu veux lire, donc que tu attendes que le mouvement mécanique soit terminé. Il faut aussi que tu attendes que le secteur à lire passe sous la tête...
Tout ces temps d'attente sont relativement long. Le CPU aurait le temps de faire beaucoup de calcul pendant ce temps.
Donc dans un fonctionnement purement linéaire, tu as de nombreux temps d'attentes qui sont perdus et qui pourraient servir à autre chose.

Au contraire, avec un fonctionnement multi-tâche, tu as un premier traitement qui veut réaliser un accès disque. Il lance son I/O sur le périphérique et la tâche est bloquée jusqu'à ce que le périphérique ait terminé.
Donc le processeur est libre et va commuter pour exécuter une autre tâche activable.
Lorsque le périphérique a terminée son I/O, il va déclencher une IRQ pour que le processeur sache que l'opération est terminée. Il pourra alors rendre la première tâche activable, et elle reprendra son exécution dès que le CPU sera disponible...
Mais on est déjà dans une architecture parallèle. Pour tirer parti de ce fonctionnement, il faut avoir quelque chose à faire pendant qu'on attend la fin de l'I/O.
C'est comme ça qu'on peut faire du multi-tâche avec un seul CPU...

Ou beaucoup plus simples, et moins gourmands en ressource que d'utiliser des multicores, mais l'inconvénient reste quand même le prix

Désolé, je ne comprends pas ce que tu veux dire.

[sparthane777]

Les IRQ servent à interrompre le traitement en cours sur le processeur pour lui dire qu'un périphérique nécessite son attention.

Dans un fonctionnement parfaitement linéaire et synchrone, si tu dois lire un fichier, il va falloire que tu positionnes la tête de lecture au dessus du cylindre que tu veux lire, donc que tu attendes que le mouvement mécanique soit terminé. Il faut aussi que tu attendes que le secteur à lire passe sous la tête...
Tout ces temps d'attente sont relativement long. Le CPU aurait le temps de faire beaucoup de calcul pendant ce temps.
Donc dans un fonctionnement purement linéaire, tu as de nombreux temps d'attentes qui sont perdus et qui pourraient servir à autre chose.

Au contraire, avec un fonctionnement multi-tâche, tu as un premier traitement qui veut réaliser un accès disque. Il lance son I/O sur le périphérique et la tâche est bloquée jusqu'à ce que le périphérique ait terminé.
Donc le processeur est libre et va commuter pour exécuter une autre tâche activable.
Lorsque le périphérique a terminée son I/O, il va déclencher une IRQ pour que le processeur sache que l'opération est terminée. Il pourra alors rendre la première tâche activable, et elle reprendra son exécution dès que le CPU sera disponible...
Mais on est déjà dans une architecture parallèle. Pour tirer parti de ce fonctionnement, il faut avoir quelque chose à faire pendant qu'on attend la fin de l'I/O.
C'est comme ça qu'on peut faire du multi-tâche avec un seul CPU...

Ah oui ça remonte quand même à 2 ans

Désolé, je ne comprends pas ce que tu veux dire.

En fait, je voulais m'interroger sur l'avantage d'utiliser des technolgies multicores pour le développement en parallèle, si toutefois ça s'avérait utile.
Mettons que demain je me prenne un Athlon X6 (eh ouais je suis un fou ), je veux dire on reproduirait 6 * le développement parallèle, ou bien c'est prédestiné à carrément autre chose les technologies multicores ?

[gangsoleil]

Bonjour,

Ayant suivi une formation enseignant le parallelisme, je suis surpris de voir a quel point ce domaine est méconnu en informatique. D'ailleurs, ce que j'ai lu du débat jusqu'ici ne faisant que confirmer ce que je pensais.

Il n'y a pas un, mais des parallelismes. Et c'est d'ailleurs ce qui fait sa force, meme si c'est aussi ce qui participe a sa meconnaissance.

Si je reprend l'exemple :

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

Version parallèle 1 :

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


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

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

La version lineaire 1 est en fait du parallelisme (cas tres particulier, qui ne sera efficace que dans de rares cas), de meme que les deux versions paralleles.
La version parallele 2 est effectivement celle qui, dans le cas present, nous donne un meilleur temps, en ayant effectue une tache en 3 unites de temps au lieu de 4.
Mais le calcul parallele adresse principalement des calculs longs, pour lesquels le gain va etre sur la duree globale, et non pas sur le fait d'avoir une tache en moins.

Si on considere 4 processeurs, et un modele parallele en pipeline, on peut avoir la chose suivante (je passe volontairement la phase d'initialisation, et considere les calculs N a N+ ):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
proc1 : enregistre N,  enregistre N+1,  enregistre N+2,  
proc2 : cherche N-1,   cherche N,       cherche N+1, 
proc3 : calcul N-2,    calcul N-1,      calcul N, 
proc4 : compte N-3,    compte N-2,      compte N-1,

Ce modele permet, si on enleve les phases d'initialisation et de finalisation, de diviser le temps total de calcul par le nombre de processeurs !! Le gain est colossal, a condition que le probleme soit modelisable sous forme de pipeline, ce qui n'est pas toujours le cas.

Pour en revenir a la question premiere :
Cela fait des annees que je milite pour le calcul parallele au sein des entreprises, mais je constate que l'idee actuellement la plus repandue est que ca ne sert a rien, il suffit de 2 choses :

• multi-threader et laisser faire l'OS
• acheter une machine plus puissante

De ce que j'ai vu, les entreprises n'ont pas encore pris conscience que la loi de Moore (stricto-cinsu, c'est a dire en nombre de transistor ) est obsolete, et que donc leur sacro-sainte regle a la noix de changer de machine ne pourra continuer a fonctionner.

Peut-etre que certains s'apercevront que le parallelisme est la meilleure solution. Meme si, je l'avoue, cela demande de former pas mal de monde. Mais que l'on commence deja par s'y mettre avec ceux qui ont des competences dans le domaine

[gangsoleil]

Mettons que demain je me prenne un Athlon X6 (eh ouais je suis un fou ), je veux dire on reproduirait 6 * le développement parallèle, ou bien c'est prédestiné à carrément aut' chose les technologies multicores ?

Tu peux faire ce que tu veux : exécuter le même code sur des données d'entrées différentes, ou exécuter du code différent en fonction du processeur.
Tu peux aussi utiliser 4 processeurs pour une tache, 1 pour une autre et le dernier libre pour l'OS ou écouter de la musique.

Toutes les solutions sont envisageables. Le but est de trouver le meilleur rapport entre le temps de développement, la complexité de mise en oeuvre de la situation, le temps de calcul final, le type de processeurs à disposition, le nombre de processeurs, ...
Le bon parallélisme tient compte de tous ces paramètres, et te sort un joli programme miracle qui optimise tout ça. Enfin en théorie bien sûr

[sparthane777]

Tu peux faire ce que tu veux : exécuter le même code sur des données d'entrées différentes, ou exécuter du code différent en fonction du processeur.
Tu peux aussi utiliser 4 processeurs pour une tache, 1 pour une autre et le dernier libre pour l'OS ou écouter de la musique.

Toutes les solutions sont envisageables. Le but est de trouver le meilleur rapport entre le temps de développement, la complexité de mise en oeuvre de la situation, le temps de calcul final, le type de processeurs à disposition, le nombre de processeurs, ...
Le bon parallélisme tient compte de tous ces paramètres, et te sort un joli programme miracle qui optimise tout ça. Enfin en théorie bien sûr

Okay ... de ce que j'ai compris, le développement en plus du multicores optimise la répartition des tâches en fonction de toutes les données parmi lesquelles celles que tu as citées.
C'est parfaitement clair, pour l'instant j'ai pas trop le temps de voir des tutoriels là-dessus, mais si un jour j'en ai l'occasion je penserais à ce thread et je suis ouvert à des tutoriels en C/C++ là-dessus.
En tout cas, je vous remercie de ce briefing

"Peut-être que certains s'apercevront que le parallélisme est la meilleure solution. Même si, je l'avoue, cela demande de former pas mal de monde. Mais que l'on commence déjà par s'y mettre avec ceux qui ont des compétences dans le domaine "

J'approuve totalement

[gangsoleil]

le développement en plus du multicores optimise la répartition des tâches en fonction de toutes les données parmi lesquelles celles que tu as citées.

Je précise un peu : le développement du parallélisme doit se faire en plus de l'utilisation des multi-coeurs.

Si on prend, un PC standard avec un CPU a 4 coeurs, on peut envisager par exemple les scénarios suivants :
Mode normal : firefox, winamp, un petit jeu à la con dans un coin, avec en arrière-plan Thunderbird et open-office. Chacun doit pouvoir disposer d'un peu de puissance de calcul, et pour cela il semble raisonnable de laisser l'OS gérer le truc.
Mode gros jeu : la, incontestablement, le parallélisme explicite (c'est-à-dire que le jeu est développe pour utiliser plusieurs processeurs) devient intéressant : on calcule plusieurs choses en même temps sur les différents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
Dans ce cas, l'OS ne doit pas avoir en charge la répartition des différents calculs sur les processeurs ni sur les coeurs.

Ce mode est aussi applicable pour les PC que pour les serveurs, et pour tous les types d'applications. Mais il faut de la volonté, du temps, et de l'argent pour que ça commence à se démocratiser.

[sparthane777]

Je precise un peu : le developpement du parallelisme doit se faire en plus de l'utilisation des multi-coeurs.

Si on prend un PC standard avec un CPU a 4 coeurs, on peut envisager par exemple les scenarii suivants :
Mode normal : firefox, winamp, un petit jeu a la con dans un coin, avec en arriere plan thunderbird et open-office. Chacun doit pouvoir disposer d'un peu de puissance de calcul, et pour cela il semble raisonnable de laisser l'OS gerer le truc.
Mode gros jeu : la, incontestablement, le parallelisme explicite (c'est a dire que le jeu est developpe pour utiliser plusieurs processeurs) devient interessant : on calcule plusieurs choses en meme temps sur les differents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
Dans ce cas, l'OS ne doit pas avoir en charge la repartition des differents calculs sur les processeurs ni sur les coeurs.

Ce mode est aussi applicable pour les PC que pour les serveurs, et pour tous les types d'applications. Mais il faut de la volonté, du temps, et de l'argent pour que ca commence a se democratiser.

Si on prend mon cas à moi qui veut profiter des nouveautés qui sortent parce que le métier me tiens à coeur, je vais dépenser un budget pour avoir une carte mère récente , une CG récente et un pross récente avec une alim de base adaptée à la conso ... je pense que c'est plus de la volonté qu'il faut, après les autres facteurs temps et argent relèvent plus de l'indécision .
Enfin c'est perso mon avis. Je veux réellement apprendre en restant en veille technologique permanente.
Sinon pour en revenir au multicores, les cartes mères permettent de les activer ou pas, donc effectivement ça change rien au développement en parallèle et linéaire, sur un Core, après quand on active tout les coeurs, faudrait surtout se mettre à la page, et développer des méthodes permettant d'optimiser le parallèle en fonction des coeurs présents dans le pross ... enfin, moi je me la sens tester sur du multicores un script par exemple permettant d'effectuer du parallèle.
Bref, merci du renseignement, je reviendrais bientôt vers vous pour de plus amples informations

[Franck SORIANO]

Il n'y a pas un, mais des parallélismes.

Oui, "programmation parallèle" c'est un terme générique qui désigne simplement le fait de faire plusieurs choses en même temps.
Après il peut se décliner d'un grand nombre de façons (multi-threading, calculs vectoriels, ...).

Si je reprends l'exemple :

La version linéaire 1 est en fait du parallélisme (cas très particulier , qui ne sera efficace que dans de rares cas),

Détrompe-toi. C'est le fonctionnement classique d'un serveur. Et c'est généralement ce qui donne les meilleures performances : Tu attends une fois pour obtenir le processeur, tu fais tes 4 opérations, tu as terminé.
D'un point de vue, théorie des files d'attente, tu es dans la configuration où tu as une file d'attente unique, avec N guichets pour dépiler la file. C'est la configuration optimale qui permet de minimiser le temps d'attente des clients et d'utiliser au maximum chaque guichet.
Dans les autres architectures, tu attends un processeur libre pratiquement à chaque opération.
Dans le premier cas, tu fais la queue une fois. Tu arrives au guichet, tu réalises toutes tes opérations.
Dans les autres cas, tu fais la queue une fois. Tu arrives au guichet, tu réalises une seule opération. Et tu retournes faire la queue pour pouvoir faire la deuxième.
Dans les deux cas, les guichets travaillent de la même façon. Le nombre total d'opérations traitées est le même. Le temps de traitement est le même. Mais dans le deuxième cas, tu ajoutes de nombreux temps d'attente qui allongent les temps de réponse... le tout à charge constante.

Si on considère 4 processeurs, et un modelé parallèle en pipeline, on peut avoir la chose suivante (je passe volontairement la phase d'initialisation, et considère les calculs N a N+ ):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
proc1 : enregistre N,  enregistre N+1,  enregistre N+2,  
proc2 : cherche N-1,   cherche N,       cherche N+1, 
proc3 : calcul N-2,    calcul N-1,      calcul N, 
proc4 : compte N-3,    compte N-2,      compte N-1,

Ce modelé permet, si on enlève les phases d'initialisation et de finalisation, de diviser le temps total de calcul par le nombre de processeurs !! Le gain est colossal, à condition que le problème soit modélisable sous forme de pipeline, ce qui n'est pas toujours le cas.

En fait, c'est la même chose que dans "linéaire 1", mais en pire : Le calcul se fait aussi en 4 temps, mais avec des synchronisations obligatoires entre chaque étape :
Proc1 exécute "enregistre N". Il faut attendre que Proc2 ait terminé "cherche N-1" pour pouvoir enchaîner "Cherche N". Et si Proc2 termine "Chercher N-1" avant que proc1 n'ait terminé "Enregistre N", il va devoir attendre que Proc1 ait fini !
Dans cette version, tu vas diviser le temps de traitement global par le nombre de processeurs, mais il faut ajouter les temps d'attente dûs aux synchronisations.
Dans la version linéaire 1, tu n'as pas ces temps de synchronisation alors que tu divises également le temps de traitement global par le nombre de CPU du fait que tu traites une transaction par CPU.

Mais dans la pratique, du fait des blocages, linéaire 1 et parallèle 2 seront identiques, car tu découpes ton traitement en tâches à exécuter, et l'OS va attribuer le CPU en fonction des tâches activables. Dès que le traitement d'une étape va bloquer sur une E/S, le CPU sera ré-attribué à une autre tâche, ce qui donnera parallèle 2 en pratique.

Pour en revenir a la question première :
Cela fait des années que je milite pour le calcul parallèle au sein des entreprises, mais je constate que l'idée actuellement la plus répandue est que ça ne sert a rien, il suffit de 2 choses :

• multi-threader et laisser faire l'OS
• acheter une machine plus puissante

Pourtant comme tu l'as dit toi-même, multi-threader c'est déjà du calcul parallèle.
Et oui, il vaut mieux faire confiance à l'OS pour attribuer le CPU aux threads activables plutôt que d'essayer de faire le travail à sa place.

Je reprends ton exemple de Parallèle 2. Si tu affectes les tâches aux CPU sans qu'un CPU ne puisse servir à un autre traitement, tu vas rapidement rencontrer des problèmes de synchronisation : Les 4 opérations ne mettant pas exactement le même temps pour s'exécuter, le CPU qui exécute la tâche la plus longue sera rapidement saturé, tandis que les autres seront en famine...
Si tu laisses faire l'OS, il fera en sorte que les CPU soient chargés au maximum de ce qui est exécutable.

Mode gros jeu : la, incontestablement, le parallélisme explicite (c'est-à-dire que le jeu est développe pour utiliser plusieurs processeurs) devient intéressant : on calcule plusieurs choses en même temps sur les différents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
Dans ce cas, l'OS ne doit pas avoir en charge la répartition des différents calculs sur les processeurs ni sur les coeurs.

Le jeu est un bon exemple où le parallélisme est intéressant en effet. Mais pas en attribuant explicitement les tâches aux CPU.
C'est même un bon exemple d'inefficacité : le GPU ne peut exécuter que des calculs graphiques. Donc si les CPU sont saturés par exemple pour calculer l'IA, tu ne peux pas utiliser la puissance du GPU pour décharger le CPU.
C'est un peu moins vrai dans l'autre sens, mais même dans ce cas, on ne fait pas un équilibrage dynamique de la charge entre "calcule par le GPU" ou calcul par le CPU.
Donc on se retrouve avec une puissance de calcul d'un côté qui n'est pas utilisée, et une autre de l'autre qui est saturée !

Bon dans ce cas, on ne peut pas vraiment faire autrement.
Mais le principe reste le même si tu réserves manuellement les CPU pour des tâches données.

Ca a un sens si tu fais du temps réel et que tu veux être sûr d'avoir un CPU disponible pour réagir à un événement donné critique, mais si tu cherches une utilisation optimale de ta puissance de calcul, il ne faut jamais qu'un CPU se tourne les pouces (ou alors il qu'a ce moment il n'y ait rien à faire).
Et le meilleur moyen d'y parvenir, c'est de laisser l'OS attribuer le CPU aux tâches activables.

Sinon pour en revenir au multicores, les cartes mères permettent de les activer ou pas, donc effectivement ça ne change rien au développement en parallèle et linéaire, sur un Core, après quand on active tout les coeurs, faudrait surtout se mettre à la page, et développer des méthodes permettant d'optimiser le parallèle en fonction des coeurs présents dans le pross ... enfin, moi je me la sens tester sur du multicores un script par exemple permettant d'effectuer du parallèle.

Et bien si, si tu programmes en linéaire, tu ne multi-thread pas ton appli. Donc tu ne tireras profis des différents coeurs que si tu as d'autres applications à exécuter en même temps, ou que c'est un serveur qui exécute plusieurs transactions en même temps (mais dans ce cas, c'est le serveur qui est multi-threadé). Pour une appli cliente pure, ce n'est pas très intéressant. Tu as acheté de la puissance de calcul que tu n'utilises pas.
Pour faire de la programmation parallèle dans ton appli, il faut la multi-threadée, mettre en place les synchros indispensables.
Et ça ne servira probablement à rien dans l'hypothèse d'un serveur.

[gangsoleil]

Bonjour,

Dans mon post, j'ai confondu deux cas. Merci de m'avoir corrigé.

Concernant le calcul sur GPU, cela fait l'objet actuellement de tres nombreuses recherches, afin de pouvoir calculer dessus et aussi de pouvoir recuperer le resultat (ce qui est evident avec un CPU et qui ne l'est plus sur un GPU). Mais il s'agit la d'un autre debat.

Concernant le fait de laisser un OS organiser les processus sur les differents coeurs disponibles, je ne suis pas d'accord avec toi pour dire que c'est la meilleure chose a faire. Ou tout du moins pas tant que les algorithmes des OS seront ceux qui sont actuellement implementes.
Prenons un programme mono-threade, qui prend 100% d'un coeur. Faisons-le tourner sur une machine à 4 coeurs, avec un OS actuel, et regardons ce qui se passe :
Le système te dit que le CPU global est utilisé à 25%, ce qui est vrai
Si tu regardes la charge réelle par CPU, tu t'aperçois que ton processus se ballade un quantum sur un coeur, deux sur un autre, etc etc etc ... Ceci est également vrai sur des machines multi-processeurs.
Dans ce cas précis, tu as 3 CPU qui ne font rien, et un qui tourne à bloc. Et plutôt que de dédier un CPU à cette tache, ce qui implique de ne pas avoir a recharger tous les registres et les mémoires caches, le système le ballade de partout, perdant un temps fou.
D'ailleurs, si tu as l'occasion de faire le test en dediant un processeur du système à ta tache, tu verras le gain de performance (enfin la encore, ce n'est pas vrai, car ça va dépendre de la tache, et principalement de ses accès mémoires).


Je pense que le problème du parallélisme est bien montré ici : il est nécessaire de l'adapter en fonction d'un très grand nombre de paramètres, et il est difficile de trouver des règles géneriques.

On peut aussi évoquer le parallélisme utilisé par les physiciens, qui programment en Fortran. Pourquoi ce langage ?? L'une des raisons est qu'il existe des compilateurs qui sont capables de générer des codes parallèles à partir de code linéaire. Alors certes, on n'a pas le même gain que si le programme était écrit de manière parallèle, mais cela ne mobilise pas un informaticien en plus du physicien lors de la phase de developpement. Et le gain par rapport à un programme linéaire est tout même important d'après ce que j'ai compris.

[OWickerman]

Et moi qui croyais que le seul instrument fiable de traitement parallèle de l'information était le Yi-King...

[Franck SORIANO]

Concernant le fait de laisser un OS organiser les processus sur les différents coeurs disponibles, je ne suis pas d'accord avec toi pour dire que c'est la meilleure chose à faire. Ou tout du moins pas tant que les algorithmes des OS seront ceux qui sont actuellement implémentes.
Prenons un programme mono-thread, qui prend 100% d'un coeur. Faisons-le tourner sur une machine à 4 coeurs, avec un OS actuel, et regardons ce qui se passe :
Le système te dit que le CPU global est utilisé à 25%, ce qui est vrai
Si tu regardes la charge réelle par CPU, tu t'aperçois que ton processus se ballade un quantum sur un coeur, deux sur un autre, etc etc etc ... Ceci est également vrai sur des machines multi-processeurs.
Dans ce cas précis, tu as 3 CPU qui ne font rien, et un qui tourne à bloc. Et plutôt que de dédier un CPU à cette tache, ce qui implique de ne pas avoir à recharger tous les registres et les mémoires caches, le système le ballade de partout, perdant un temps fou.
D'ailleurs, si tu as l'occasion de faire le test en dédiant un processeur du système à ta tache, tu verras le gain de performance (enfin la encore, ce n'est pas vrai, car ça va dépendre de la tache, et principalement de ses accès mémoires).

La situation que tu décris n'est un problème que dans le cas où :
1. La tâche dure suffisamment longtemps sans réaliser la moindre I/O ni synchronisation pour se faire préempter.
2. Le traitement qui est aussi long est capable de travailler en ayant toutes les données dans le cache, sans jamais aller chercher de données en mémoire centrale.

C'est quand même un cas assez rare. D'autre part, tu ne peux changer de coeur qu'à l'issue de la fenêtre de préemption (ou d'une synchronisation), et même à ce moment-là, il n'est pas dit que l'OS te réaffecte sur un autre.

Mais la plupart du temps, tu n'utilises pas le CPU pendant plus de 15 minutes sans réaliser une E/S (ou alors il faut revoir ton algorithme...). Donc ta tâche va être suspendue en attente d'une E/S.
Et au moment où elle pourra repartir, tu as tout intérêt à ce qu'elle reparte sur le premier CPU disponible, plutôt que de devoir attendre que celui sur lequel tu l'as affecté soit libre !