Code Multi Processeurs

**ketchupi** · 23/06/2009, 13h27

Bonjour,

j'ai réalisé un programme qui tourne sous un seul processeur, mais mon PC est un biprocesseur (2 dual core), j'aimerais donc savoir où je pourrais trouver, sur ce forum ou ailleurs, des informations pour débuter une programmation en multi processeur.
J'ai lu qu'il fallait utiliser un multiframework style qt ou autre.

Quelqu'un pourrait-il m'aiguiller ?

Je vous remercie++

**Mac LAK** · 23/06/2009, 13h54

Envoyé par ketchupi

J'ai lu qu'il fallait utiliser un multiframework style qt ou autre.

Non, ça n'a absolument rien d'obligatoire. Le nœud d'une ventilation correcte sur les cœurs, c'est la fonction SetThreadAffinityMask.

Après, si ton programme est monothread, ça ne changera absolument rien... De même, si tes threads passent leur temps à attendre et non pas à calculer (threads de communication notamment), ça n'améliorera quasiment rien de les répartir sur les différents cœurs.
Dernière "illusion" : deux threads de calcul lourd impliquant beaucoup d'accès mémoire ne seront pas non plus beaucoup accélérés par cette méthode, car le bus mémoire est "unique" sur le processeur et il est donc partagé entre les divers cœurs... Si l'un des cœurs monopolise le bus, l'autre sera obligé d'attendre qu'il soit libre.

Si par contre tu as plusieurs threads de communication, quelques threads "légers" genre gestion d'IHM, puis un thread de calcul lourd, alors tu auras par exemple intérêt à déporter le thread lourd sur un autre cœur.

**ketchupi** · 23/06/2009, 15h20

oui mais, une question.

Si j'ai deux threads lourds, et que chacun calcule dans son coin, et qu'à la fin de tous les calculs, chacun communique avec le thread principal, on peut s'attendre à ce que la méthode de multithread soit avantageuse, non ?

**Mac LAK** · 23/06/2009, 15h40

Non, pas forcément justement !!

Je t'encourage à aller lire ce topic et ce topic pour plus de détails. Cela t'expliquera quelques principes généraux et quelques "mauvais" cas de figure...

Après, dès que tu as réglé l'affinité générale de ton processus pour le répartir sur plusieurs coeurs (GetProcessAffinityMask), tu peux régler individuellement les threads sur l'un ou l'autre, le "truc" étant en fait de les interdire sur tous les cœurs autre que celui que tu as choisi.
Pour plus de détails / infos / conseils, il faudra que tu expliques un peu mieux ce que tu fais, et décrire les divers threads qui composent ton application.

**caradhras** · 23/06/2009, 15h49

J'ajoute ma pierre à l'édifice : Est-ce qu'une lib comme openMP ne pourrait pas se charger de ça en répartissant correctement les calculs si nécessaire sur les différents coeurs accessibles?
(Si bien entendu il y a un intérêt à partager les calculs)

**Mac LAK** · 23/06/2009, 16h07

Envoyé par caradhras

J'ajoute ma pierre à l'édifice : Est-ce qu'une lib comme openMP ne pourrait pas se charger de ça en répartissant correctement les calculs si nécessaire sur les différents coeurs accessibles?
(Si bien entendu il y a un intérêt à partager les calculs)

La répartition automatique fonctionne rarement correctement... Elle est (heureusement !) rarement pire que pas de répartition du tout, toutefois.

OpenMP sert à écrire du code parallèle plus facilement, et sans devoir taper dans la tripaille de l'OS pour créer un thread et des éléments de synchronisation, et c'est tout (c'est déjà pas mal quand même). Derrière tout ça, la librairie ne sait pas ce que tu voulais faire, elle te donne "seulement" les outils pour le faire, pas plus, pas moins.

Je te cite un avertissement de la documentation OpenMP :

Envoyé par Open MP

The user is responsible for using OpenMP in his application to produce a conforming program. OpenMP does not cover compiler-generated automatic parallelization and directives to the compiler to assist such parallelization.

Aucune librairie ne t'empêchera de paralléliser des choses qui ne devraient pas l'être, d'utiliser des blocs de données de façon incorrecte en paralysant/monopolisant le bus commun, d'oublier de protéger par synchro des éléments critiques, et de manière générale de faire tout et n'importe quoi.

Tu as déjà un élément de synchronisation automatique : ton système d'exploitation, qui tente d'utiliser au mieux les cœurs disponibles... Le simple fait qu'il existe des versions de certains programmes optimisées pour 2 OU 4 cœurs (rarement les deux en même temps...) devrait te prouver qu'il y a encore de la place pour le jus de cerveau quand on commence à toucher à la programmation parallèle...

**white_tentacle** · 23/06/2009, 17h04

Je dirais qu'avant de commencer à jouer avec SetThreadAffinityMask & co, il faudrait peut-être commencer par multithreader ton application.

En effet, un programme monothreadé ne s'exécutera jamais que sur un seul core, affinité ou pas. Après, des framework comme OpenMP fournissent des outils pour paralléliser facilement des portions de code, mais c'est loin d'être adapté à tous les cas de figure.

La première chose à faire, c'est effectivement découper ton traitement en sous traitements indépendants, qui donc peuvent être effectués en parallèle. Avant de paralléliser le programme, il faut en effet paralléliser l'algorithme. Pour cette étape, pas besoin de framework, pas besoin d'ordinateur, juste d'un papier, un crayon et un peu de réflexion

.

Ensuite, en fonction de l'algorithme obtenu, tu pourras choisir une solution adaptée (openMP, multithread "classique", MPI, etc...)

**loufoque** · 24/06/2009, 06h53

Dernière "illusion" : deux threads de calcul lourd impliquant beaucoup d'accès mémoire ne seront pas non plus beaucoup accélérés par cette méthode, car le bus mémoire est "unique" sur le processeur et il est donc partagé entre les divers cœurs... Si l'un des cœurs monopolise le bus, l'autre sera obligé d'attendre qu'il soit libre.

Y'a pas que le SMP dans la vie, y'a NUMA aussi.