Version imprimable
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++
Non, ça n'a absolument rien d'obligatoire. Le nœud d'une ventilation correcte sur les cœurs, c'est la fonction SetThreadAffinityMask.Citation:
Envoyé par ketchupi
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.
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 ?
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.
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.Citation:
Envoyé par caradhras
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 :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.Citation:
Envoyé par Open MP
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... :mouarf:
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...)
Y'a pas que le SMP dans la vie, y'a NUMA aussi.Citation:
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.
Tu n'as pas toujours (pour ne pas dire "jamais") le choix du matériel sur lequel tu travailles... Et les systèmes SMP sont nettement majoritaires.Citation:
Envoyé par loufoque