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.