Discussion :

[math_lab]

Bonjour, je développe actuellement un programme de simulation physique qui se trouve être un poil trop lent à mon gout. J'ai donc pensé a paralléliser calcul en donnant une liste de primitives à chaque core. Le problème est que je n'ai bien evidemment jamais fait de multithreading avant.

J'aimerai tout d'abord savoir si le multithreading vaut le coup car chaque thread risque de lire et écrire dans des variables utilisées par d'autres threads (et si je les bloque, je me retrouve avec les mêmes performances qu'un simple thread, non ?).
Ensuite, d'après ce que j'ai pu lire, la bibliothèque boost ne permet pas de choisir sur quel core le thread sera exécuté. Faut-il donc impérativement passer par les commandes de windows ?

Merci d'avance.

[Aratox]

Salut,
Il est effectivement vrai que si deux threads écrivent dans la même variable ça peu poser problème, exemple :
si tu lance 2 threads qui font l'action suivante :
++var;

imaginons que var vaut initialement 0, les deux threads vont lire la variable, faire chaqu'un de son coté 0 + 1 = 1... puis ils vont tous les deux écrire 1 dans var...

var sera donc égal à 1, et non pas 2...

Sinon pour la question de quel thread sur quel core, j'ai toujours travailler avec plusieurs thread sous linux ou avec Qt. J'ai un quad-core et si je lance 4 threads, mes 4 cores tourne à 100%, jamais eu de soucis. Sauf erreur c'est toujours le système qui choisi que thread va sur quel coeur.

[3DArchi]

Bonjour,

J'aimerai tout d'abord savoir si le multithreading vaut le coup car chaque thread risque de lire et écrire dans des variables utilisées par d'autres threads (et si je les bloque, je me retrouve avec les mêmes performances qu'un simple thread, non ?).

Ca peut dépendre de beaucoup de paramètres.
D'abord si des données sont uniquement accédées en lecture et donc constantes tous le long de la simulation (typiquement, une géométrie), alors pas besoin de mettre en oeuvre un mécanisme de verrou pour gérer l'accès concurrent.
Si des données sont écrites par un ou des threads avec des risques de race conditions, alors là effectivement, il faudra un mécanisme de contrôle de l'accès concurrent qui aura un coût. Mais cela peut être fait uniquement au moment de l'accès. Tu peux aussi regarder des patterns type reader/writer consumer/producer, etc.
A la base, tu peux commencer par voir comment découper tes simulations pour minimiser ces éventuels conflits.

Ensuite, d'après ce que j'ai pu lire, la bibliothèque boost ne permet pas de choisir sur quel core le thread sera exécuté. Faut-il donc impérativement passer par les commandes de windows ?

Je ne sais pas si avec boost c'est possible. Peut être que d'autres bibliothèques le permettent ? Sinon, faudra passer par l'api windows...

[Mac LAK]

J'aimerai tout d'abord savoir si le multithreading vaut le coup car chaque thread risque de lire et écrire dans des variables utilisées par d'autres threads (et si je les bloque, je me retrouve avec les mêmes performances qu'un simple thread, non ?).

De façon générale, passer en MT coûte plus de temps CPU que du monothread. Si tu préfères, tu gagnes du temps "réel" (humain, des heures / minutes / secondes), mais au prix de plus de ressources consommées (threads et objets de synchronisation) et plus de temps CPU.

Pour t'expliquer brièvement : imagine un traitement qui se fait en une minute en monothread. Une fois en MT (deux threads), tu vas le faire en, disons, 35 secondes, c'est à dire proche du gain maximum possible.
Or, si tu calcules le temps CPU consommé, tu vas arriver à 35 s X 2 (threads), donc ... 70 secondes ! Plus que les 60 initiales. Tu charges donc plus ta machine, même si (heureusement !) la plupart du temps ça ne gêne en rien car tu as largement plus de puissance disponible que tu n'en utilises.

Donc, comme le précise 3DArchi, ça va dépendre de beaucoup de paramètres, et il n'y a pas de règle absolue. Certains traitements ne peuvent pas être parallélisés par nature (ex : calcul d'une série / suite mathématique), d'autres sont difficilement parallélisables (sous-entendu "en obtenant un gain significatif"), d'autres sont quasi-triviaux.

Je ne sais pas si avec boost c'est possible. Peut être que d'autres bibliothèques le permettent ? Sinon, faudra passer par l'api windows...

C'est une grosse lacune de beaucoup de librairies portables de gestion des threads : elles ne gèrent pas l'affinité processeur.
Donc, direction l'API Windows pour ça. Pour ma part, je ne connais pas de librairie portable permettant de gérer l'affinité processeur, du moins dans les dernières versions que j'ai pu voir.

[math_lab]

Merci pour vos réponses.
Étant donné que ma fonction n'écrira dans les variables qu'à la fin du traitement, je pense que la synchro ne devrait pas être trop handicapante, et au pire, j'imagine que je peux même m'en passer en construisant un tableau temporaire qui stockerait les résultats et qui permettrait au programme principal de faire la mise à jour des variables.
Sinon, je me rend bien compte que le multithreading a un certain cout et que le programme sera moins efficace, mais j'ai 8 cœurs a ma disposition, donc ce serait stupide de pas en tirer avantage.

J'en profite d'ailleurs pour poser une autre question: doit-on créer et supprimer les threads à la volée quand on a besoin ? Je sais qu'avec join, on peut attendre la fin du thread, mais doit-il être détruit et reconstruit après pour pouvoir être re-exécuté ?

[3DArchi]

doit-on créer et supprimer les threads à la volée quand on a besoin ?

Lorsque on doit le faire souvent, alors on peut passer par un pool de threads.
Ils sont créés en début de programme et se mettent en attente de boulot. Lorsque tu as un traitement, tu en prends un libre, tu l'actives en lui donnant le traitement à faire. Lorsqu'il a finit il revient dans le pool des threads dispo et s'endort (çad se met en attente d'un évènement pour un nouveau traitement).

[yan]

Dans un premier temps, regarde peut être OpenMP.

[JolyLoic]

C'est une grosse lacune de beaucoup de librairies portables de gestion des threads : elles ne gèrent pas l'affinité processeur.
Donc, direction l'API Windows pour ça. Pour ma part, je ne connais pas de librairie portable permettant de gérer l'affinité processeur, du moins dans les dernières versions que j'ai pu voir.

En quoi est-ce problématique quand il s'agit de faire du parallélisme pour les performances ?
L'idée dans ce cas est de faire abstraction des primitive bas niveau et coûteuses comme les thread, les outils de lock au niveau du noyau,... et encore plus de l'affinité. Si tu règles l'affinité, comment fonctionnera le programme quand tu aura upgradé ta machine pour une avec 64 cœurs ?

Côté bibliothèque, je conseillerais plus TBB d'Intel ou PPL de Microsoft que boost::thread pour ce genre d'usage. Elles fournissent des API permettant de s'abstraire de cette tuyauterie, et d'être plus efficace (notion de tâche plus légère qu'un thread, conteneur pour des échange de donnée multithread règlés finement en temre de minimisation des locks...).

[Mac LAK]

En quoi est-ce problématique quand il s'agit de faire du parallélisme pour les performances ?

Parce que la charge n'est pas toujours idéalement répartie, tout simplement. Tu peux voir une illustration de ce problème sur ce vieux topic.

En règle générale, dans le cas d'une optimisation maximale, tu en viens à être plus ou moins obligé de régler les affinités de façon à éviter la migration involontaire de threads, et/ou le regroupement de threads qui seraient soit "légers", soit non-concurrents.

Mais pour faire ça, il faut avoir très bien compris ce que font chacun des threads de son application, et compris comment ils se synchronisent. Je te concède bien volontiers que ce n'est pas à la portée du premier débutant en parallélisme, et que ce n'est pas non plus un niveau d'optimisation requis pour toutes les applications.

L'idée dans ce cas est de faire abstraction des primitive bas niveau et coûteuses comme les thread, les outils de lock au niveau du noyau,... et encore plus de l'affinité.

C'est bien pour ça que j'utilise usuellement des API portables à ce sujet, qui sont d'ailleurs encore encapsulées dans des objets d'encore plus haut niveau de façon à simplifier tout ça au maximum... Tout en gardant une implémentation performante, car c'est souvent fait à base de templates et donc inliné un maximum.

Et je continue donc de trouver très con de ne pas implémenter ces API d'affinités, quitte à les stubber sur les OS où cela pose problème... Tout le reste est implémenté, t'as même parfois des systèmes de priorité (inclus la modification du scheduling), et totalement portables, qui sont implémentés... L'affinité ne "coûtait" pas bien plus "cher" à ajouter.

Si tu règles l'affinité, comment fonctionnera le programme quand tu aura upgradé ta machine pour une avec 64 cœurs ?

Première règle d'une application gérant manuellement l'affinité : compter le nombre de cœurs / CPU disponibles réellement (= analyse du masque d'affinité du processus) en début d'application, et obtenir une map des coeurs/CPU utilisables.
Ensuite, penser à utiliser cette map, avec les contraintes de répartition des threads requises par l'algo bien sûr, lors de la création de nouveaux threads.

Je ne vois absolument pas où est le problème...

[JolyLoic]

Parce que la charge n'est pas toujours idéalement répartie, tout simplement. Tu peux voir une illustration de ce problème sur ce vieux topic.

J'ai parcouru ce topic, mais je n'ai rien vu qui permette de penser que tripatouiller l'affinité aurait améliorer quoi que ce soit en l'occurrence (par contre, un meilleur découpage des tâches avec une meilleure gestion de la mémoire, oui, probablement). Et j'ai envie de dire que, d'autant plus quand la charge n'est pas idéalement répartie, il vaut mieux laisser le système faire du task stealing, ce qui est incompatible avec une affinité gérée par le développeur

En règle générale, dans le cas d'une optimisation maximale, tu en viens à être plus ou moins obligé de régler les affinités de façon à éviter la migration involontaire de threads, et/ou le regroupement de threads qui seraient soit "légers", soit non-concurrents.

Sauf que le système de tâche placé au dessus des threads est déjà fait pour ça, normalement, et j'ai l'impression que c'est le genre de chose qui peut se gérer automatiquement mieux qu'à la main (sauf éventuellement si la main est celle d'un véritable génie), tout comme à une époque l'attribution des registres était une activité normale d'optimisation, alors que maintenant on laisse faire le compilateur. Tout ce que l'utilisateur a à faire est de fournir un découpage avec la bonne granularité (ni trop, ni trop peu), qui respecte bien l'agencement mémoire (des données devant être touchées par deux tâches différentes doivent être physiquement loin les unes des autres, et inversement), et qui minimise les synchronisations nécessaires (dans l'idéal, aucune). A partir de là (ce qui est déjà beaucoup demander), au système de se débrouiller.
C'est d'autant plus vrai hors du monde embarqué, où l'on ne maîtrise par tout ce qui tourne sur la machine et où une optimisation manuelle fine risque de devenir une vraie pessimisation pour peu qu'un autre programme tourne derrière, et fasse lui aussi beaucoup de calculs.

Mais pour faire ça, il faut avoir très bien compris ce que font chacun des threads de son application, et compris comment ils se synchronisent. Je te concède bien volontiers que ce n'est pas à la portée du premier débutant en parallélisme, et que ce n'est pas non plus un niveau d'optimisation requis pour toutes les applications.

J'ai l'impression que c'est aussi inutile, voire néfaste, dans la très grande majorité des cas. As-tu un cas réel ou ça a eu un impact en tête (attention, je ne parle pas de parallélisme pour répondre à un évènement rapidement, là l'affinité peut avoir de l'intérêt, mais du parallélisme pour calculer vite) ?

L'affinité ne "coûtait" pas bien plus "cher" à ajouter.

Je ne sais pas trop de quel système tu parles, mais dans ceux que je connais un peu (TBB et PPL), j'ai l'impression que ne pas exposer l'affinité n'est pas un manque, mais une décision consciente visant à "obliger" les développeurs à prendre de la distance par rapport au système.