Discussion :

[kidpaddle2]

Bonjour,

J'ai un calcul plut�t lourd (qui correspondrait grossi�rement � une double boucle for imbriqu�e) � effectuer, et j'aimerais profiter de l'octocoeur pr�sent sur la machine client pour r�duire le temps de traitement au maximum.

Je ne connais pas grand-chose � la programmation thread�e, je me demandais donc si la biblioth�que TBB d'Intel permettrait � mon programme, monoinstance et sans d�claration de threads, d'effectuer des calculs parall�les sans modification majeure (tout ce qui est langage, ok, mais si on va plus loin dans la gestion de threads, je serai probablement perdu).

Edit: J'ai Boost � ma disposition. Visiblement, boost::threads n'a pas l'air bien compliqu�, mais est-ce que la d�claration de plusieurs threads les fait ex�cuter automatiquement (donc sans TBB) sur tous les coeurs disponibles ?

Qu'en pensez-vous ?

Merci d'avance.

Cordialement,

Kidpaddle2

[oodini]

Je crois que tu devrais jeter un �il � OpenMP, auparavant.

[JolyLoic]

Pour ce genre de choses, openMP ou TBB sont probablement de meilleurs choix que boost::thread, puisque ce dernier demande � g�rer les threads manuellement.

Apr�s, pour ce qui est des modifications majeures, �a d�pend de la nature de ce que tu fais dans tes boucles. En particulier, est-ce que tu acc�des en �criture � de la m�moire dans ta boucle ? Si oui, est-ce la m�me zone m�moire d'une it�ration � l'autre, ou bien chaque it�ration a-t-elle sa propre m�moire bien d�finie ?

[kidpaddle2]

Merci de vos r�ponses. J'avais effectivement entendu de OpenMP, mais je me demandais si c'�tait r�ellement efficace...

Finalement, je me suis renseign� en parall�le pour un sujet compl�mentaire et il s'est av�r� qu'il a d�riv� sur le coeur de celui-ci ; ma conclusion : je dois cr�er plusieurs threads qui ouvriront des fichiers en parall�le.

Par contre, pour �crire par blocs plut�t que ligne par ligne (ce qui est nettement plus rapide), j'aurai de toutes mani�res un double for � faire. Me conseillez-vous donc TBB ou OpenMP ? Il s'agit tout simplement d'une combinaison lin�aire... Donc en th�orie, oui, il y aurait partage en �criture sur le tableau de sortie/r�sultat.

[koala01]

Salut,

De mani�re g�n�rale, d�s que tu as une donn�e partag�e � laquelle tu dois acc�der en �criture / modification dans un thead, tu dois veiller � ce que cette �criture / modification soit, au minimum, prot�g�e par un mutex et sans doute par du "double checking".

En effet, si tu ne prend pas cette pr�caution �l�mentaire, de te trouver dans une situation dans laquelle deux (ou plusieurs) threads risquent de vouloir... modifier la variable partag�e en m�me temps, avec des r�sultats parfois surprenants.

Ce qui semble donc le plus int�ressant est donc:
1- de cr�er une file de gestion des informations � �crire. Cette file peut �tre aliment�e par plusieurs threads (seul le "raccordement" des nouveaux �l�ments devant �tre prot�g� par rapport � des acc�s concurrents).

2- d'utiliser un thread unique qui se chargera d'�crire dans un fichier le contenu de la file d�finie plus haut.

[simong]

Salut,

De mani�re g�n�rale, d�s que tu as une donn�e partag�e � laquelle tu dois acc�der en �criture / modification dans un thead, tu dois veiller � ce que cette �criture / modification soit, au minimum, prot�g�e par un mutex et sans doute par du "double checking".

En effet, si tu ne prend pas cette pr�caution �l�mentaire, de te trouver dans une situation dans laquelle deux (ou plusieurs) threads risquent de vouloir... modifier la variable partag�e en m�me temps, avec des r�sultats parfois surprenants.

Ce qui semble donc le plus int�ressant est donc:
1- de cr�er une file de gestion des informations � �crire. Cette file peut �tre aliment�e par plusieurs threads (seul le "raccordement" des nouveaux �l�ments devant �tre prot�g� par rapport � des acc�s concurrents).

2- d'utiliser un thread unique qui se chargera d'�crire dans un fichier le contenu de la file d�finie plus haut.

Salut, je suis moi aussi en train de faire mes armes en progra multithread�e et c'est un peu rude je dois dire! Koala01, je crois que tu mets le doigt sur un probl�me que je rencontre directement: estce que tu voudrais bien poser ici un cas-type d'illustration de ton ton intro sur la question du partage de variables ("situation dans laquelle deux (ou plusieurs) threads risquent de vouloir... modifier la variable partag�e en m�me temps") et des points 1. et 2. suivants? En particulier je voudrais mieux saisir ce que tu appelles "file de gestion" car je ne vois pas du tout. Je fais sinon moi le choix d'utiliser TBB. J'ai vu sous Boost l'utilisation des "Mutex", mais pas sous TBB. Comment se g�re la synchro avec cette librairie? Merci et@ +

[kidpaddle2]

Jette un coup d'oeil � ce lien : http://www.justsoftwaresolutions.co....variables.html

En faisant h�riter tes threads de cette classe, tu as une file de gestion !