Questions de base sur le multithreading

Version imprimable

07/02/2010, 14h00
math_lab

Questions de base sur le multithreading

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.
07/02/2010, 22h36
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.
08/02/2010, 10h30
3DArchi

Bonjour,

Citation:

Envoy� par math_lab

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.

Citation:

Envoy� par math_lab

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...
08/02/2010, 12h33
Mac LAK

Citation:

Envoy� par math_lab

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.

Citation:

Envoy� par 3DArchi

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.
11/02/2010, 15h17
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� ?
11/02/2010, 17h15
3DArchi

Citation:

Envoy� par math_lab

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).
16/02/2010, 18h06
yan

Dans un premier temps, regarde peut �tre OpenMP.
16/02/2010, 21h20
JolyLoic

Citation:

Envoy� par Mac LAK

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...).
17/02/2010, 09h45
Mac LAK

Citation:

Envoy� par JolyLoic

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.

Citation:

Envoy� par JolyLoic

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.

Citation:

Envoy� par JolyLoic

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... ;)
18/02/2010, 23h35
JolyLoic

Citation:

Envoy� par Mac LAK

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

Citation:

Envoy� par Mac LAK

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.

Citation:

Envoy� par Mac LAK

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) ?

Citation:

Envoy� par Mac LAK

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.
19/02/2010, 11h48
Mac LAK

Citation:

Envoy� par JolyLoic

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).

En fait, lorsque tu es dans un cas o� il n'est pas possible d'atteindre 100% de charge avec un thread par c�ur [ce qui est souvent signe de donn�es trop volumineuses, mais on n'a pas toujours le choix], tu vas devoir avoir un thread suppl�mentaire pour r�cup�rer le reste de charge disponible... Et dans un tel cas, tu ne dois avoir qu'un seul thread d�pla�able, les autres doivent rester verrouill�s sur un c�ur en particulier.

Citation:

Envoy� par JolyLoic

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

A un d�tail pr�s : qui te dit qu'il sera possible d'am�liorer la granularit� de tes calculs ? Typiquement, tous les calculs de suite/s�rie ne peuvent pas �tre individuellement parall�lis�s, par exemple... Et ils peuvent pourtant porter sur des donn�es volumineuses.

Citation:

Envoy� par JolyLoic

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.

Jusqu'� pr�sent, j'ai toujours d� �quilibrer manuellement mes threads pour obtenir des performances maximales. L'OS n'est absolument pas suffisant � ce niveau, m�me s'il offre une assistance non n�gligeable.
De plus, les syst�mes d'aide au parall�lisme ne savent en g�n�ral pas correctement g�rer les �l�ments dynamiques (threads cr��s � la vol�e en r�ponse � un �v�nement ext�rieur, par exemple).

Citation:

Envoy� par JolyLoic

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.

Sauf que c'est cette partie que tu d�cris la plus longue et la plus difficile, et de tr�s tr�s loin !! La "tripaille" derri�re, notamment le r�glage de l'affinit�, n'est qu'une broutille en comparaison.

Citation:

Envoy� par JolyLoic

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.

Heu, si t'as un calculateur pour lequel tu ne sais pas ni quelle est sa charge restante, ni si quelque chose tourne ou pas derri�re, crucifies son administrateur : c'est un charlot... ;)
Tu as l'affinit� processeur pour chaque processus devant �tre ex�cut� (les threads devant faire avec ce qui est allou� au processus), sans m�me parler d'�ventuelles plages de r�servation du calculateur, donc c'est un argument qui ne tient pas la route. Que ce soit dans le monde de l'embarqu� ou du calcul intensif, la ma�trise de la machine est essentielle.

Citation:

Envoy� par JolyLoic

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) ?

En fait, c'est important pour pouvoir traiter beaucoup de calculs dans des laps de temps tr�s courts et r�p�titifs (acquisition de donn�es notamment). En effet, tu ne peux pas te permettre de pics de charge, ni de prendre du retard. Donc, tu dois non seulement r�agir vite � l'arriv�e de donn�es brutes, mais EN PLUS les rendre trait�es avant une �ch�ance donn�e... Sans perturber pour autant le reste du syst�me, bien entendu.
Ce que je reproche au parall�lisme "automatique", c'est justement cette absence de contr�le sur les pics de charge et sur la vitesse de r�action : en effet, tu ne sais PAS ce que les quelques macros / primitives que tu utilises provoquent r�ellement, et �a ne te permet donc pas d'�tre certain de ce qui va se passer.

Citation:

Envoy� par JolyLoic

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.

Je parle notamment des librairies POCO, ACE et ICE, qui poss�dent toutes une abstraction portable des threads.
19/02/2010, 14h36
JolyLoic

Citation:

Envoy� par Mac LAK

Que ce soit dans le monde de l'embarqu� ou du calcul intensif, la ma�trise de la machine est essentielle.

Sauf que justement, le parall�lisme sort des ces deux domaines, pour devenir un pr�requis aussi pour les applications tout venant tournant sur les portables de M. Toutlemonde. Donc le luxe de ma�triser sa machine n'est pas toujours disponible...

Citation:

Envoy� par Mac LAK

En fait, c'est important pour pouvoir traiter beaucoup de calculs dans des laps de temps tr�s courts et r�p�titifs (acquisition de donn�es notamment). En effet, tu ne peux pas te permettre de pics de charge, ni de prendre du retard. Donc, tu dois non seulement r�agir vite � l'arriv�e de donn�es brutes, mais EN PLUS les rendre trait�es avant une �ch�ance donn�e... Sans perturber pour autant le reste du syst�me, bien entendu.

Et on est l� dans le domaine du temps r�el, qui a ses propres contraintes diff�rentes du simple parall�lisme pour la performance.

Citation:

Envoy� par Mac LAK

Je parle notamment des librairies POCO, ACE et ICE, qui poss�dent toutes une abstraction portable des threads.

POCO et ICE, je ne connais pas, mais ACE est clairement fait pour g�rer des threads, dans un contexte r�activit�, par pour g�rer du parall�lisme pour les performances uniquement, avec des notions comme tasks, concurrency runtime, task stealing...
19/02/2010, 15h13
Mac LAK

Citation:

Envoy� par JolyLoic

Sauf que justement, le parall�lisme sort des ces deux domaines, pour devenir un pr�requis aussi pour les applications tout venant tournant sur les portables de M. Toutlemonde. Donc le luxe de ma�triser sa machine n'est pas toujours disponible...

Bof : pour 99% des gens, le parall�lisme, c'est des threads d'IHM et de communication, avec �ventuellement un ou deux trucs plus ou moins parall�lis� pour utiliser plus d'un seul c�ur...

Des "M. Toutlemonde" qui ont BESOIN de perfs brutales, je n'en connais pas beaucoup (pour ne pas dire un seul !), c'est presque syst�matiquement quelque chose pour le boulot, ou alors ce sont des fondus d'informatique (et l�, ce n'est plus le lambda moyen).

Pour les utilisateurs uniquement (car ces API ne concernent que les d�vs, hein...), ils se contrefichent royalement de l'API sous-jacente tant que �a p�dale.

Citation:

Envoy� par JolyLoic

Et on est l� dans le domaine du temps r�el, qui a ses propres contraintes diff�rentes du simple parall�lisme pour la performance.

Le temps r�el est quand m�me un des plus gros "client" du parall�lisme, avec le calcul intensif... Et les deux domaines ont besoin de pouvoir contr�ler la charge.
Or, n'oublie pas quand m�me que ce sont des domaines qui peuvent, de par le grand nombre d'applications li�es, �tre les plus � m�me de tester intensivement les API MT. C'est pour �a que je trouve franchement cr�tin de ne pas permettre de g�rer l'affinit� dans ces API : ce n'est qu'une poign�e de fonctions en plus, dont l'utilisation n'est ni obligatoire, ni requise.

Il est quand m�me extr�mement courant d'avoir des API fournissant une partie "basique", simple d'utilisation et convenant � 90% des cas, plus une partie "avanc�e" pour r�soudre les quelques probl�mes sp�cifiques qui ne peuvent pas se contenter des fonctions de base. Win32 ou POSIX en sont remplies, tout comme la quasi-totalit� des librairies ou frameworks courants.

Cela ne d�range personne, et �a rend service � ceux qui en ont besoin : c'est pour �a que je trouve cr�tin de ne pas les ajouter.

Citation:

Envoy� par JolyLoic

POCO et ICE, je ne connais pas, mais ACE est clairement fait pour g�rer des threads, dans un contexte r�activit�, par pour g�rer du parall�lisme pour les performances uniquement, avec des notions comme tasks, concurrency runtime, task stealing...

Les trois librairies sont bas�es sur le m�me "principe" de base : l'abstraction du tronc commun de la gestion des threads entre les diff�rents OS sur lesquels elles existent.
EDIT : et, accessoirement, c'est AUSSI pour les perfs que je les utilise... ;)

Le probl�me, c'est qu'ils ont "un peu" oubli� au passage certaines parties sp�cifiques... Certaines sont ajout�es / refaites (ex : mutex avanc�s, type lecteurs/r�dacteur), d'autres sont adapt�es (ex : fonctionnalit� type "pthread_join"), et d'autres sont cruellement absentes (l'affinit� et le partage m�moire inter-processus notamment).
22/02/2010, 00h51
math_lab

Bonjour � tous. J'ai finalement pu r�gler tout �a en utilisant les fonctions de Windows. Pour ceux qui sont int�ress�s, voila en gros l'architecture du programme:
- Le programme principal cr�e n threads qui tournent en continu et attendent le signal pour commencer � bosser.
- A un certain point (quand j'ai besoin du calcul parall�lis� de physique), le programme principal divise le boulot en n petit paquets de primitives (dans mon cas, plein de petits t�tra�dres) et donne le signal de d�part.
- Chaque thread calcule la physique sur ses primitives, (comme mes t�tra�dres ont des sommets en commun, il y a un mutex qui prot�ge l'�criture des forces) et envoi un signal au programme principal pour dire quand il a termin�.
- Le programme principal attend le signal de tous les threads et peut ensuite continuer normalement.

Ceux qui auraient besoin d'explications ou d'un peu de doc sur les commandes, allez voir ce tutorial: http://bob.developpez.com/tutapiwin/article_46.php

�a s'est r�v�l� plus simple que je le pensais. Et merci � ceux qui ont pu m'�clairer quelque peu.