calcul parallèle et thread

bonjour

je dois faire tourner une application assez lourde en temps calcul,
je souhaiterais la parallèliser, mais je n'ai pas le temps pour l'instant,

pour l'instant je me demandais comment tirer partie du fait que je dispose d'une machine biprocesseur, lorsque je lance l'application un seul CPU est utilisé, je voulais introduire plusieurs threads dans cette application pour qu'elle utilise les 2 processeurs en même temps

j'ai fait un programme test assez simple , un programme qui crée des thread et leur fait faire un nombre "n" d'opérations, si je dis que "t" est le nombre de thread, je répartis les "n" opérations sur les t threads, chaque thread a n/t opérations à faire,

je me disais que le temps calcul devait être plus faible lorsque l'on utilise plus d'1 thread,
et bien c'est tout le contraire ! si je fais tourner cette application test avec un thread s'occupant des "n" opérations, le temps calcul est plus court que si je fais tourner cette application avec t thread s'occupant de n/t opérations !!!

tout thread confondu le programme doit pourtant faire le même nombre d'opérations
la seule chose encourageante est que avec 1 thread j'occupe 99% du processeur, et avec plusieurs thread j'occupe 199% du processeur (bi-proc)

est-ce que vous y comprenez qqch ?
est-ce que les thread sont automatiquement répartis sur les différents processeurs pour les bi-proc ?

PS : mon système est linux, Debian, noyau SMP ...

Cette question aurait plus sa place sur le forum linux...

Regarde du coté de la fonction "pthread_attr_setaffinity()" dans glibc (Native POSIX Threads Library - NPTL)

Citation:

---

Envoyé par pseudocode

Cette question aurait plus sa place sur le forum linux...

Regarde du coté de la fonction "pthread_attr_setaffinity()" dans glibc (Native POSIX Threads Library - NPTL)

---

merci pour votre réponse, mais je ne trouve pas d'explications pour la fonction "pthread_attr_setaffinity()"

j'ai repris mon programme test, en fait quel que soit le nombre de thread le temps calcul est à peu près le même, comme si les threads étaient effectués à la suite (alors que mon PC est un bi proc)

par ailleurs j'ai remarqué que tous les threads avaient le même PID, alors qu'il est sensé être différent sur les machines GNU/linux (?)

je dirais avant de se lancer dans ce genre de répartition, il faudrait être sûr que ton code NE PEUT PAS être plus optimisé.

Donc il faut avant tout passer par une phase d'optimisation du CODE.

Ensuite, il peut être normal que cela soit aussi long (cela dépend du calcul, mais si ton calcul n'est pas parallélisé, tout ce que tu fais c'est éventuellement donner la possibilité de choisir un autre CPU). Et même en étant parallèle, si ce qui est parallélisé réeelement prend en tout peu de temps, et nécessite par exemple autre chose qui se trouve être dispatché sur un autre CPU, que ce soit via MPI ou autre, les temps de synchronisation peuvent annuler les gains...

Tu peux tenter de poster le code sur le forum approprié, voir si on pourrait l'optimiser d'abord (on peut éventuellement gagner jusquà 2000 ou 8000 %)..

Citation:

---

Envoyé par deb75

j'ai repris mon programme test, en fait quel que soit le nombre de thread le temps calcul est à peu près le même, comme si les threads étaient effectués à la suite (alors que mon PC est un bi proc)

par ailleurs j'ai remarqué que tous les threads avaient le même PID, alors qu'il est sensé être différent sur les machines GNU/linux (?)

---

non, c'est normal. Les Threads et les Processus sont 2 choses differentes. Pour faire simple, le Processus est un container de code/data et les Threads sont les pointeurs d'execution.

Au lancement d'un processus, L'OS "attache" ce processus a un des 2 processeurs. Par défaut, tous les threads du processus s'executeront sur ce meme processeur.

Je me suis peut-etre trompé sur le nom de la function... pthread_setaffinity() ? sched_setaffinity() ? en tout cas, quelquechose avec "affinity"

Citation:

---

Envoyé par souviron34

je dirais avant de se lancer dans ce genre de répartition, il faudrait être sûr que ton code NE PEUT PAS être plus optimisé.

Donc il faut avant tout passer par une phase d'optimisation du CODE.

Ensuite, il peut être normal que cela soit aussi long (cela dépend du calcul, mais si ton calcul n'est pas parallélisé, tout ce que tu fais c'est éventuellement donner la possibilité de choisir un autre CPU). Et même en étant parallèle, si ce qui est parallélisé réeelement prend en tout peu de temps, et nécessite par exemple autre chose qui se trouve être dispatché sur un autre CPU, que ce soit via MPI ou autre, les temps de synchronisation peuvent annuler les gains...

Tu peux tenter de poster le code sur le forum approprié, voir si on pourrait l'optimiser d'abord (on peut éventuellement gagner jusquà 2000 ou 8000 %)..

---

bonjour

c'est un programme test très simple qui ne nécessite pas d'optimisation, même si votre remarque est tout à fait valable, volià le code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

#include <pthread.h> #include <stdio.h>   /* Parameters to print_function. */   struct char_print_parms { /* The character to print. */ double sum; /* The number of times to print it. */ long count; };   /* Prints a number of characters to stderr, as given by PARAMETERS,   which is a pointer to a struct char_print_parms. */   void* char_print (void* parameters) { /* Cast the cookie pointer to the right type. */ struct char_print_parms* p = (struct char_print_parms*) parameters; int i;   for (i = 1; i < p->count; i++) p->sum = p->sum + i;   return NULL; }   /* The main program. */   int main () { pthread_t thread1_id; pthread_t thread2_id;   struct char_print_parms thread1_args; struct char_print_parms thread2_args;   thread1_args.sum = 0.0; thread1_args.count = 000000000; pthread_create (&thread1_id, NULL, &char_print, &thread1_args);   thread2_args.sum = 0.0; thread2_args.count = 200000000; pthread_create (&thread2_id, NULL, &char_print, &thread2_args);   pthread_join (thread1_id, NULL); pthread_join (thread2_id, NULL);   fprintf(stderr,"%f \n",thread1_args.sum); fprintf(stderr,"%f \n",thread2_args.sum);   /* Now we can safely return. */ return 0; }

---

Citation:

---

Envoyé par pseudocode

non, c'est normal. Les Threads et les Processus sont 2 choses differentes. Pour faire simple, le Processus est un container de code/data et les Threads sont les pointeurs d'execution.

Au lancement d'un processus, L'OS "attache" ce processus a un des 2 processeurs. Par défaut, tous les threads du processus s'executeront sur ce meme processeur.

Je me suis peut-etre trompé sur le nom de la function... pthread_setaffinity() ? sched_setaffinity() ? en tout cas, quelquechose avec "affinity"

---

si j'ai bien compris, aucune chance donc d'utiliser les deux processeurs physiques disponibles en lançant plusieurs threads, ils s'éxécuteront tous à la suite sur le même proc, pourtant j'avais lu que tout l'intérêt des thread étaitent qu'ils pouvaient être répartis sur plusieurs proc ...

Citation:

---

Envoyé par deb75

si j'ai bien compris, aucune chance donc d'utiliser les deux processeurs physiques disponibles en lançant plusieurs threads, ils s'éxécuteront tous à la suite sur le même proc, pourtant j'avais lu que tout l'intérêt des thread étaitent qu'ils pouvaient être répartis sur plusieurs proc ...

---

J'ai juste dit que, par défaut, tous les threads s'executent sur le mm processeur.

Mais tu peux forcer un thread a utiliser un autre processeur avec les fonctions machin_setaffinity().

Edit: voila, j'ai retrouvé: http://www.ibm.com/developerworks/li...-affinity.html

Citation:

---

Envoyé par pseudocode

J'ai juste dit que, par défaut, tous les threads s'executent sur le mm processeur.

Mais tu peux forcer un thread a utiliser un autre processeur avec les fonctions machin_setaffinity().

Edit: voila, j'ai retrouvé: http://www.ibm.com/developerworks/li...-affinity.html

---

problème résolu !!

en fait lorsque j'utilise 2 threads au lieu d'un pour le même nombre d'opérations, le temps calcul est bien divisé par 2 ! et les thread sont par défaut répartis sur les 2 proc,
mon erreur vient du fait que le "user time" est toujours le même quelque soit le nombre de thread (je ne comprends pas pourquoi), par contre le "elapsed time" (c'est-à-dire le temps réel passé de vant la machine) est bien divisé par 2 ! Les temps que j'observais étaient trop court et je ne me rendais pas compte

merci pour votre aide

merci pour ta référence pseudocode, mais cela semble être une commande pour manipuler les processus, pas les threads, je suis toujours preneur si qqn connaît une commande qui permet de diriger les threads vers tel ou tel proc

Citation:

---

Envoyé par deb75

problème résolu !!

en fait lorsque j'utilise 2 threads au lieu d'un pour le même nombre d'opérations, le temps calcul est bien divisé par 2 ! et les thread sont par défaut répartis sur les 2 proc,
mon erreur vient du fait que le "user time" est toujours le même quelque soit le nombre de thread (je ne comprends pas pourquoi), par contre le "elapsed time" (c'est-à-dire le temps réel passé de vant la machine) est bien divisé par 2 ! Les temps que j'observais étaient trop court et je ne me rendais pas compte

---

Ah oui... Je me suis trompé ! Le scheduler repartit le travail des threads sur les processeurs disponibles (encore heureux d'ailleur). Et ce, meme si ce sont 2 threads du meme processus.

J'ai confondu avec l'affinité d'une thread / CPU au cours du temps (time slice). Dans ce cas, le scheduler essaye de toujours faire tourner une thread sur le meme processeur.

Citation:

---

merci pour ta référence pseudocode, mais cela semble être une commande pour manipuler les processus, pas les threads, je suis toujours preneur si qqn connaît une commande qui permet de diriger les threads vers tel ou tel proc

---

Citation:

---

Envoyé par man page pour "sched_setaffinity()"

NOTE: The affinity mask is actually a per-thread attribute that can be adjusted independently for each of the threads in a thread group. The value returned from a call to gettid(2) can be passed in the argument pid.

---