Discussion :

[Amnael]

Bonjour,

depuis un certains temps je suis amené à paralléliser mes programmes, ce que j'arrive à faire, mais c'est un peu de la pratique bête car je ne comprends pas toujours ce que je fais, aussi, j'aimerais bien un éclaircissement à ce sujet.


Tout d'abord, en C, il existe la bibliothèques pthread , permettant de créer des threads qui sont des processus légers.

Ce que je remarque lorsque j'exécute mes programmes avec cette librairie, c'est que je peux créer autant de thread que je veux. (Tout comme je peux faire autant de process avec des fork).


Oui, mais voilà ! Lorsque je vais dans les propriétés de ma machine, je m’aperçois que j'ai 2 cœurs. De mon point de vue il est donc impossible de créer plus de 2 threads.

D'ailleurs, récemment, j'ai commencé à utiliser la lib Open MP permettant également de paralléliser ces programmes. Hors, cette lib optimise de base le nombre de thread en se calquant sur le nombre de cœurs; et il n'est pas possible de créer plus.


Je ne comprends donc pas pourquoi selon la méthode Open MP je suis limité au nombre de cœurs, et pourquoi selon la méthode phthread / fork je ne suis pas limité.

Est-ce qu'il s'agit de la différence entre multi-thread et multi-proc ?


Enfin bref vous l'aurez compris j'aurai bien besoin de mettre plusieurs choses au clair ici, parce que j'aimerais bien comprendre ce que je fais et ne pas le faire bêtement.

[Matt_Houston]

Un thread n'est, comme son nom l'indique, qu'un fil d'exécution dédié à une tâche indépendante, un contexte. Peu lui chaut les caractéristiques physiques de la machine sur laquelle il s'exécute, cela lui est totalement abstrait. Les threads et les processus en cours d'exécution partagent simplement la puissance de calcul disponible comme s'ils s'exécutaient en parallèle, le plus souvent sous la forme de quanta de temps. Qu'il y ait un seul ou 128 cœurs, la manière de les synchroniser reste la même. Le parallélisme est donc simulé lorsqu'il n'y a qu'un seul processeur disponible, et effectif lorsque plusieurs threads peuvent être répartis sur autant de processeurs.

Il est rarement désirable pour un processus s'exécutant sur une machine multi-cœurs de créer plus de threads que de processeurs physiques, tout simplement car dans ce contexte on recherche ce parallélisme effectif. Lorsque l'on a n threads sur n cœurs, on utilise 100% de la puissance disponible. Moins de threads et les quanta de certains cœurs seront inutilisés ou alloués à d'autres processus, plus de threads et ces derniers feront la queue.

Ce que je remarque lorsque j'exécute mes programmes avec cette librairie, c'est que je peux créer autant de thread que je veux. (Tout comme je peux faire autant de process avec des fork).

Il existe en réalité une limite au nombre de threads qu'un processus peut engendrer, fixée par le système d'exploitation.

[dalfab]

Bonjour,

Il y un intérêt à avoir plus de thread que de cœurs. Quand un thread se met en attente, immédiatement un autre thread va utiliser le CPU devenu disponible.
En regardant mon PC, il y a à cet instant :
650 threads,
* dont 40 'ready non running' (c-a-d qu'ils attendent que la disponibilité d'un des 4 cœurs)
* 4 'running' (ce sont le 4 qui à cet instant précis utilisent les cœurs, dans moins d'une millisecondes s'en seront d'autres)
* les 606 autres sont en attente d'un événement ou de la disponibilité d'une ressource.
Le threads 'ready' vont donc se partager les cœurs en utilisant au mieux le CPU. En créant des threads de calcul simple, il est évident qu'il ne gagnent rien à dépasser le nombre de coeurs; en réalité il existe de nombreux points d'attente dans un code (p.e un simple printf devra communiquer et donc attendre) et on peut tout à fait en avoir plus pour encore gagner en performance.

[picodev]

[...]
D'ailleurs, récemment, j'ai commencé à utiliser la lib Open MP permettant également de paralléliser ces programmes. Hors, cette lib optimise de base le nombre de thread en se calquant sur le nombre de cœurs; et il n'est pas possible de créer plus.


Je ne comprends donc pas pourquoi selon la méthode Open MP je suis limité au nombre de cœurs, et pourquoi selon la méthode phthread / fork je ne suis pas limité.

OpenMP ne limite pas le nombre de «threads». Un programme quick and dirty te le montre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <stdio.h>
#include <stdlib.h>
#include <omp.h>
 
int main(int argc, char *argv[])
{
  int id;
 
  if (argc==2)
    omp_set_num_threads(atoi(argv[1]));
  #pragma omp parallel private(id)
  {
    id = omp_get_thread_num();
    printf("id : %d\n", id);
  }
 
  return 0;
}

Tu le compiles par exemple avec un gcc -Wall -Wextra -fopenmp -o omp omp.c. Si tu ne donnes pas d'arguments tu vas te retrouver avec un nombre de threads par défaut, pour mon architecture 4 par exemple :

Code :

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

1
2
3
4
5
$ ./omp 
id : 2
id : 0
id : 3
id : 1

Si tu lui dis combien de thread tu veux :

Code :

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

1
2
3
4
5
6
7
8
9
$ ./omp 8
id : 2
id : 3
id : 4
id : 5
id : 6
id : 0
id : 7
id : 1

Tu peux également préciser le nombre de threads par une variable d'environnement :

Code :

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

1
2
3
4
5
6
7
$ OMP_NUM_THREADS=6 ./omp
id : 1
id : 2
id : 3
id : 0
id : 4
id : 5

[sambia39]

Bonsoir.

Bonjour,
......
Ce que je remarque lorsque j'exécute mes programmes avec cette librairie, c'est que je peux créer autant de thread que je veux. (Tout comme je peux faire autant de process avec des fork).
....
Oui, mais voilà ! Lorsque je vais dans les propriétés de ma machine, je m’aperçois que j'ai 2 cœurs. De mon point de vue il est donc impossible de créer plus de 2 threads.
...
Est-ce qu'il s'agit de la différence entre multi-thread et multi-proc ?
....
Enfin bref vous l'aurez compris j'aurai bien besoin de mettre plusieurs choses au clair ici, parce que j'aimerais bien comprendre ce que je fais et ne pas le faire bêtement.

Quelque explication.
Un processus (sans trop rentrer dans les détails) est une unité d’exécution (c'est-à-dire de partage de temps processeur et mémoire) qui correspond à une suite d’action dynamique réalisée lors d’une exécution.
Un thread comme ce qui a été dit est un fil d’exécution et permet de dérouler plusieurs suites d’instructions, en parallèle à l’intérieur d’un processus.
Donc, un processus correspond plus exactement à un espace indépendant de mémoire dans lequel un ou plusieurs « thread » s’exécutent. ( On peut également dire qu’un processus est une structure d’allocation des ressources (espace d’adressage) pour les threads et que les threads peuvent être vus comme étant comme des processus qui partagent toutes les ressources, sauf la pile et certains registres. Mais attention un thread exécute une fonction, car il ne voit que la région de code processus qui l’héberge. Le changement de contexte où le partage mémoire ne s’applique uniquement qu’entre threads crée dans le même processus);

Attention au terme parallélisme, pourquoi?. Parce qu'elle est "également" caractérisée par l’architecture matérielle (parallélisation physique pour être plus exacte) et n’a pas le même sens d’emplois dans des termes qui vont suivre, car les noyaux Linux considèrent qu'il existe deux types de systèmes (Les ordinateurs monoprocesseurs sur lequel les fils d’exécution sont présents à des moments donnés et les ordinateurs multiprocesseurs qui permettent l’exécution de plusieurs tâches)

• Multiprocesseur: C’est plusieurs processeurs qui partagent de la mémoire on parle alors de « Symetric Multi Processor : SMP» pour des ordinateurs dotés de plusieurs coeurs, mais d’une mémoire unique
• Multicoeur: Un seul processeur physique est présent, mais il dispose de plusieurs décodeurs d’instruction qui travaille en parallèle
• Hyperthreading: Un seul processeur assure une commutation entre deux séquences d’instruction différente.

Aux finales il y a vrai parallélisme quand plusieurs « threads » partagent la mémoire pour s’exécuter en parallèle sur plusieurs processeurs dans le cas contraire il s’agit de parallélisme logique du multitâche (du multitâche).

Il n’y a pas de limite sur les "threads", mais comme il y a des limites sur le nombre de créations de processus (fork)il y a donc indirectement un nombre max de thread.

à bientôt

[Amnael]

Merci beaucoup pour toutes vos réponses, je n'ai bien sûr pas tout compris dans le détail, mais je vais m'y plancher sérieusement.

Une question si j'ai bien compris:

Lorsque l'on a n threads sur n cœurs, on utilise 100% de la puissance disponible.

Si j'ai donc 2 cœurs de disponibles, le niveau de performance sera meilleur avec 2 threads qu'avec 3 thread donc ?

Si oui, quel est l'argument permettant de dire que n thread pour n coeur = 100% puissance ?

[foetus]

Si oui, quel est l'argument permettant de dire que n thread pour n coeur = 100% puissance ?

C'est l'équilibrage de charge

Prends un jeu vidéo : tu vas avoir un thread pour l'affichage, un pour les interactions, un pour l'audio (du moins avec les vieux jeux)

Or l'audio c'est même pas 7-10% de processeur en plein charge. Le clavier c'est encore moins. Mais l'affichage c'est minimum 50-60%.

Il faut équilibrer ces threads afin d'occuper le plus ces processeurs

[dalfab]

Si j'ai donc 2 cœurs de disponibles, le niveau de performance sera meilleur avec 2 threads qu'avec 3 thread donc ?

C'est peu probable, car il ne faut pas oublier qu'un thread peut (et souvent doit) se mettre par moment en attente, et dans ce cas le troisième utilisera le CPU disponible à ces instants.

Si oui, quel est l'argument permettant de dire que n thread pour n coeur = 100% puissance ?

C'est rarement le cas car très dépendant des interactions entre les threads. Essaie de créer N threads faisant la même chose et mesure le temps mis. Si N est trop petit ou trop grand, les performances diminuent. Si c'est un test sur PC, en refaisant le même test un autre jour la valeur optimale ne sera pas la même.
N = 4 pour un bicœur est assez bon pour des threads 'simples', mais parfois l'optimum sera atteint plus plusieurs dizaines de threads.

[Matt_Houston]

Si j'ai donc 2 cœurs de disponibles, le niveau de performance sera meilleur avec 2 threads qu'avec 3 thread donc ?

Non c'est impossible à déterminer à l'avance, ça dépend totalement des traitements réalisés, de l'architecture cible et de l'environnement d'exécution. Comme d'habitude.

On recommande toujours de mesurer les performances avant d'optimiser, et surtout de ne pas optimiser avant d'avoir mesuré. C'est toujours valable en programmation concurrente.


Lorsque j'écris cela :

Il est rarement désirable pour un processus s'exécutant sur une machine multi-cœurs de créer plus de threads que de processeurs physiques,

En théorie c'est vrai, pour une famille de threads qui réalisent des calculs similaires indépendamment de ressources externes partagées.

En pratique il faut régulièrement synchroniser les traitements concurrents, les threads réalisent en permanence des appels système, provoquent des cache misses, sont préemptés au profit des autres processus qui tournent sur la machine, etc...

Des sections parallèles de calcul scientifique implémentées via OpenMP, par exemple, peuvent avoir un comportement approchant la théorie. La paire de threads de simulation et de rendu d'un jeu vidéo ont en revanche un comportement très différent. On ne parallélise pas forcément pour des raisons de performance, la réactivité est aussi très importante lorsqu'il s'agit d'interagir avec l'utilisateur.

[Amnael]

Parfait, merci beaucoup je pense avoir un peu mieux saisi le fonctionnement global.