Exécution ralentie en multithread

Bonjour à tous,
je compile et j'exécute un proto de code C++ multithreadé (je m'appuie sur boost::thread). Mon problème est qu'alors que je m'attendais au global à une réduction du temps de d'exécution de mon programme, celui-ci autmente avec le nombre de threads que je crée ! (4 threads sur un quadricore). Quelqu'un a t-il un avis ? Merci

Salut,
Tu accèdes à une ressource système ou partagée qui nécessite synchronisation (allocation dynamique ?) ?

Salut,
Non pas l'impression et pas de ressource partagée en tout cas :
l'idée est à la base, simplement de balancer en parallèle un traitement (boucle) qui s'exécute en local, sur les processeurs. Mon algo est un random simulator, je souhaite réaliser N simuls, faire à terme en sorte que mon traitement soit réparti sur les n proc. De la machine. Il y aurait ruse particulière? Merci à toi.

C'est possible de voir le code parallélisé ?
Tu peux aussi avoir des impacts de perfs selon la façon dont tu accèdes aux données (pb de cache)

t'utilise quoi comme pRNG ? rand() ? si oui rand contient des données statiques en interne qui emepche son usage propre en MT. y a rand_r sinon.

Salut,
On peut effectivement constater des impacts « à la marge) en fonction de comment on adresse les données, j'ai vu ça.
Je n’utilise pas le Rand native de C++, mais boost
La classe que je teste en gros:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81

class Threaded_Sim_Class { private : Rand_Gen gen; size_t nbSimulations; bool isMT; struct MT_Data { Rand_Gen gen; size_t nbSimulations; Result result; }; vector<boost::shared_ptr<MT_Data>> threadData; size_t nbThreads; public : Threaded_Sim_Class(size_t _nbSimulations) //monothreading :isMT(false),nbSimulations(_nbSimulations),gen() { } Threaded_Sim_Class(size_t _nbSimulations,size_t _nbThreads) //multithread si _nbThreads>1 :nbThreads(_nbThreads),threadData(_nbThreads),nbSimulations(_nbSimulations),gen() { isMT=(nbThreads>1) ? true : false; } ~Threaded_Sim_Class() {}   double Pythagor(double _u) { return...; }   Result getResult() { Result res; if(!isMT) { for(size_t i=0; i<nbSimulations; ++i) { double tmp=Pythagor(gen.Next()); res.mean+=tmp; res.var+=tmp*tmp; } res.mean/=nbSimulations; res.var=res.var/nbSimulations-(res.mean*res.mean); } else { for(size_t i=0; i<nbThreads; ++i) { threadData[i]=boost::shared_ptr<MT_Data>(new MT_Data); threadData[i]->nbSimulations=nbSimulations/nbThreads; threadData[i]->gen.skip(2*i* (nbSimulations/nbThreads)); } boost::thread_group tg; for(size_t i=0;i<nbThreads;++i) { tg.create_thread(boost::bind(&Threaded_Sim_Class::getResult,this,i)); } tg.join_all(); for(size_t i=0;i<nbThreads;++i) { res.mean += threadData[i]->result.mean; //res.var +=threadData[i]->result.var; } res.mean/=nbThreads; } return res; }   void getResult(size_t _iThread) { boost::shared_ptr<MT_Data> td=threadData[_iThread]; //tempo for(size_t i=0; i<td->nbSimulations; ++i) { double tmp=Pythagor(td->gen.Next(),td->gen.Next()); td->result.mean += tmp; td->result.var +=tmp*tmp; } td->result.mean/=td->nbSimulations; td->result.var=td->result.var/nbSimulations-(td->result.mean*td->result.mean); } };

---

J'exécute getResult() dans mon main. Je peux comparer des calculs en monothread et sur plusieurs threads. Mon temps d'exé croît avec le nombre de threads! Je comrpends pas!!!

On va avancer à tâtons....
A quoi ressemble Pythagore ?
Quel est le volume de donnée (combien de boucles ) ? Et quel est le temps en mono thread vs multi thread.
Créés 1 thread de plus que le nb de core (5) et regarde si ça impacte.

Salut, sans problème:
Pythagor : mesure un écart quadratique dans l'idée: return (u*u-M*M), où u tirée aléatoirement avant, est passé à la fonction. Rien comme traitement supplémentaire à l’intérieur.
Volume de données: 10000000 de tirages
Mon impact 9.75s en mono (et 9.5 quand je construis un objet paramétré de façon explicite avec n=1 thread, pour comparer), puis 10.1s sur les 4, 14.7.7 sur 5, 18.7s sur 6, 22.9 sur 7, 26.6s sur 8…
Alors, à la base pas une différence folle entre mono et 4threads mais c’est déjà clairement pas le résultat auquel je me serais attendu. Et puis après, c’est carrément la misère (sans compter que ça a pas l'air très linéaire en impact, tout ça)!

Il n'y aurait pas un mutex sur ton générateur aléatoire ?
Une telle perte de perf me fait quand même penser que les threads se synchronisent ou s'excluent mutuellement régulièrement. Bref, il y a de l'attente quelque part.
Identifie tous tes appels systèmes (y compris allocation, vecteur, liste, flux, trace, etc.) et tous tes appels à des fonctions de bibliothèques tierces.

Salut,
Non aucun mutex nulle part pour l'instant. D'ailleurs il faudra p't^t que je regarde où en mettre c'est vrai... Ma classe de génération aléatoire implémente boost::random, et dans mon main je fais que construire un objet de type Threaded_Sim_Class sur lequel j'appelle la méthode getResult! Je fais aucune autre allocation ou ne traite aucun autre vecteur que ceux que tu vois...
=> "Identifie tous tes appels systèmes (y compris allocation, vecteur, liste, flux, trace, etc.) et tous tes appels à des fonctions de bibliothèques tierces.": Ce serait quoi les précautions à prendre avec ces appels système ?

=> quand tu parles des threads "qui se synchronisent ou s'excluent mutuellement régulièrement", ce serait à rechercher où où dans mon programme???? A+ et merci

Salut,
Prenons le problème autrement : instrumente chacun de tes threads de façon de plus en plus fine pour voir où le temps est consommé (boost.timer peut t'aider je pense pour mesurer le temps écoulé). Une fois que tu as identifié ce qui prend du temps, tu auras probablement la réponse à ton problème ;)

Citation:

---

Envoyé par 3DArchi

Salut,
Prenons le problème autrement : instrumente chacun de tes threads de façon de plus en plus fine pour voir où le temps est consommé (boost.timer peut t'aider je pense pour mesurer le temps écoulé). Une fois que tu as identifié ce qui prend du temps, tu auras probablement la réponse à ton problème ;)

---

la lecture du code source permet quand même de déduire quelques petits choses :

a. si c'est un problème de lock caché ce ne peut être que dans

Code:

---

1 2	tg.create_thread(boost::bind(&Threaded_Sim_Class::getResult,this,i));

---

boost::bind ne devant pas jouer directement avec des mutex, create_thread est le suspect, mais ce serait quand même surprenant… à moins qu'il ne crée un mutex sur l'objet passé en paramètre et que l'expansion de boost::bind provoque une situation où l'objet serait toujours le même… mais on rentre dans des hypothèses du genre "bizarre"… éventuellement un effet de bord d'une optimisation du compilateur…
…mais çà reste peu probable… de plus le comportement de l'augmentation du temps de calcul serait plus linéaire…
(encore que pour être certain de cela… il faudrait savoir exactement ce que vous avez mesuré et comment …)

b. si ce n'est pas un problème de mutex lié au threading, alors le suspect principal est :

Code:

---

1 2	threadData[i]->gen.skip(2*i* (nbSimulations/nbThreads));

---

que fait skip() et comment le fait-il ?


PS
petit détail : si le nombre de simulations n'est pas un multiple du nombre de threads le code n'exécutera pas le nombre de simulations espérés… (vous perdez nSimulations modulo nThreads)


NB
si skip() fait "while (toBeSkipped--) next();" alors c'est bien lui le coupable :

avec skip "enabled"

Code:

---

1 2 3 4 5 6

benchSimulator 1 threads: 168595199 ns benchSimulator 2 threads: 529154506 ns benchSimulator 4 threads: 547437236 ns benchSimulator 10 threads: 1308146160 ns benchSimulator 20 threads: 2578868055 ns

---

avec skip "disabled"

Code:

---

1 2 3 4 5 6

benchSimulator 1 threads: 171873820 ns benchSimulator 2 threads: 466571113 ns benchSimulator 4 threads: 242895564 ns benchSimulator 10 threads: 151853600 ns benchSimulator 20 threads: 146165826 ns

---

Salut,
@JeitEmgie : le cout de création de thread existe, mais pas au point de passer de 10s à 14s avec 5 threads (ou alors boost.thread est à jeter, ce que je ne crois pas).
Pour gen.skip, il n'est pas présenté. J'ai pensé qu'il s'agissait simplement d'une segmentation de son espace de valeurs selon le nombre de threads. Mais, je n'avais pas pensé que cette fonction pouvait être 'lourde'. C'est vrai que le sur-coût n'est peut être pas dans les fonctions exécutées dans le thread mais dans le travail de préparation avant. En tout cas, je pense qu'instrumenter un peu pour voir où se consomme le temps est peut être une façon rapide d'identifier le ou les lignes problématiques.

Citation:

---

Envoyé par 3DArchi

Salut,
@JeitEmgie : le cout de création de thread existe, mais pas au point de passer de 10s à 14s avec 5 threads (ou alors boost.thread est à jeter, ce que je ne crois pas).
Pour gen.skip, il n'est pas présenté. J'ai pensé qu'il s'agissait simplement d'une segmentation de son espace de valeurs selon le nombre de threads. Mais, je n'avais pas pensé que cette fonction pouvait être 'lourde'. C'est vrai que le sur-coût n'est peut être pas dans les fonctions exécutées dans le thread mais dans le travail de préparation avant. En tout cas, je pense qu'instrumenter un peu pour voir où se consomme le temps est peut être une façon rapide d'identifier le ou les lignes problématiques.

---

c'est bien pour cette raison que je parie plus sur le skip()...
les générateurs de nombre aléatoires ne sont pas des fonctions auxquelles ils suffit de passer un index N pour avoir le Nième élément...
la génération du Nième dépend en général des N-1 précédents...
donc çà n'aurait rien d'étonnant à ce qu'il fasse une boucle appelant next()... et dans ce cas inutile d'instrumenter... il est évident que le problème vient de là... d'autant plus que pour chaque "gen" il recalcule certainement depuis le début...

si c'est çà, la solution est de générer les nombre aléatoires avant l'étape du splitsing du travail en threads et de les stocker dans un tableau, chaque accédant en lecture au segment qui le concerne (donc pas de mutex nécessaire...)

ou de changer de générateur de nombre aléatoire (les digits de PI par exemple...) …

en utilisant un tableau contenant les nombres pré-calculés :

Code:

---

1 2 3 4 5 6

benchSimulator 1 threads: 70493335 ns benchSimulator 2 threads: 110037032 ns benchSimulator 4 threads: 76292946 ns benchSimulator 10 threads: 62239087 ns benchSimulator 20 threads: 51807857 ns

---

(PS ns = nanosecondes... autrement dit l'ensemble des benchmarks va plus vite que ce qu'il a mesuré comme son temps le plus rapide... :
real 0m0.730s
user 0m1.927s
sys 0m0.106s

d'où l'interrogation de ce qui a été mesuré et comment... et l'intérêt d'en savoir un peu plus sur le code qui n'a pas été montré...)

Citation:

---

Envoyé par JeitEmgie

la solution est de générer les nombre aléatoires avant l'étape du splitsing du travail en threads et de les stocker dans un tableau

---

C'est déjà ce qu'il fait (au - en partie), non ? skip est appelé avant la génération des thread :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

for(size_t i=0; i<nbThreads; ++i) { threadData[i]=boost::shared_ptr<MT_Data>(new MT_Data); threadData[i]->nbSimulations=nbSimulations/nbThreads; threadData[i]->gen.skip(2*i* (nbSimulations/nbThreads)); //// 3DArchi : Skip } boost::thread_group tg; for(size_t i=0;i<nbThreads;++i) { tg.create_thread(boost::bind(&Threaded_Sim_Class::getResult,this,i)); //// 3DArchi : création des threads } tg.join_all();

---

En revanche, c'est peut être dans next :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void getResult(size_t _iThread) { boost::shared_ptr<MT_Data> td=threadData[_iThread]; //tempo for(size_t i=0; i<td->nbSimulations; ++i) { double tmp=Pythagor(td->gen.Next(),td->gen.Next()); //// 3DArchi : Next ou Pythagor ? td->result.mean += tmp; td->result.var +=tmp*tmp; } td->result.mean/=td->nbSimulations; td->result.var=td->result.var/nbSimulations-(td->result.mean*td->result.mean); }

---

Citation:

---

Envoyé par JeitEmgie

et dans ce cas inutile d'instrumenter...

---

Disons, que l'instrumentation permet de voir tout de suite ce qui prend du temps, d'éviter les conjectures et c'est rapide et facile à mettre en oeuvre.

Citation:

---

Envoyé par 3DArchi

C'est déjà ce qu'il fait (au - en partie), non ? skip est appelé avant la génération des thread

---

et alors ? cette partie fait partie du benchmark... qui a priori est sur l'ensemble du calcul...

sauf erreur :

si skip fait une boucle sur next, pour 10.000.000 simulations et 10 threads :
pour le gen du thread n°0 : il appelle 0 fois next()
pour le thread n°1 : il appelle 2 * (nSimul / nThread) = 2.000.000 de next()
pour le thread n°2 : il appelle 4 * (nSimul / nThread) = 4.000.000 de next()
etc.
donc (2 + 4 + 6 + … + 18) = 90 millions de next()…
si au moins il utilisait les résultats du précédent, il n'en ferait que 9 * 2M = 18 millions... dans sa phase préparatoire...
+ les 20 millions implicitement faits dans les threads... (c'est quand même faire 2x le même travail...)

en préparant les nombres aléatoires dans un tableau avant on ne fait que 20 M de next() avant et 0 dans les threads...

Citation:

---

Envoyé par 3DArchi

Disons, que l'instrumentation permet de voir tout de suite ce qui prend du temps, d'éviter les conjectures et c'est rapide et facile à mettre en oeuvre.

---

question de goût : priorité au raisonnement...

Salut,
Merci pour vos contributions, je commence à y voir plus clair Les temps d’exécution présentés sont ceux de l’exécution du « main » sur la base des paramètre que j’annonce (10 millions de tirages, nombre de threads flottant). Skip génère à chaque fois la séquence entière de l'index 0 à l'index i*(nbSimulation/nbThreads) puisqu’il est clair en effet que l’accès à la séquence aléatoire ne se fait pas indépendamment de la séquence déjà tirée, au passage il y a une typo dans la recopie sur le forum de mon source, j'appelle bien sûr Skip sur (i+1)*(nbSimulation/nbThreads) et non 2*(nbSimulations/nbThreads)!
J’ai le code suivant pour Skip:
skip(size_t n)
{
for(size_t i=0; i<n; ++i)
uni();
}
Certes, il y aurait matière à dire sur cette procédure question opimalité mais je ne l’incriminais pas forcément car d’une part aucun aspect de franche dépendance linéaire de mon temps de traitement en fonction des nombres de threads (test effectué par ailleurs) ne se dégageaient réellement et d’autre part, je pensais cette brique de génération globalement peu coûteuse en temps de calcul.
L’approche stockage dans un vecteur préalablement à la distribution sur les threads, je ne l’avais pas retenue (et ai d’ailleurs dû adapté mon code) pour une affaire de portabilité: dépassement de mémoire sur une autre machine que je fais tourner.
Les précautions à apporter en termes de synchro (mutex) ici, y’a matière à? Merci bcp, à +

Citation:

---

Envoyé par simong

Salut,
Merci pour vos contributions, je commence à y voir plus clair Les temps d’exécution présentés sont ceux de l’exécution du « main » sur la base des paramètre que j’annonce (10 millions de tirages, nombre de threads flottant). Skip génère à chaque fois la séquence entière de l'index 0 à l'index i*(nbSimulation/nbThreads) puisqu’il est clair en effet que l’accès à la séquence aléatoire ne se fait pas indépendamment de la séquence déjà tirée, au passage il y a une typo dans la recopie sur le forum de mon source, j'appelle bien sûr Skip sur (i+1)*(nbSimulation/nbThreads) et non 2*(nbSimulations/nbThreads)!
J’ai le code suivant pour Skip:
skip(size_t n)
{
for(size_t i=0; i<n; ++i)
uni();
}
Certes, il y aurait matière à dire sur cette procédure question opimalité mais je ne l’incriminais pas forcément car d’une part aucun aspect de franche dépendance linéaire de mon temps de traitement en fonction des nombres de threads (test effectué par ailleurs) ne se dégageaient réellement et d’autre part, je pensais cette brique de génération globalement peu coûteuse en temps de calcul.
L’approche stockage dans un vecteur préalablement à la distribution sur les threads, je ne l’avais pas retenue (et ai d’ailleurs dû adapté mon code) pour une affaire de portabilité: dépassement de mémoire sur une autre machine que je fais tourner.
Les précautions à apporter en termes de synchro (mutex) ici, y’a matière à? Merci bcp, à +

---

vous avez d'autres typos dans le code que vous avez posté :
Pythagor est appelé une fois avec 1 paramètre, l'autre avec 2…
si effectivement il prend 2 paramètres alors le skip avec "2 * …" se comprenait…

et avec un seul paramètre : le (i+1) se justifie comment ? le premier thread (i=0) n'a rien à skipper, non ?

et maintenant vous introduisez "uni()" … "next()" appelle aussi "uni()" ? …

pour ce qui est de votre raisonnement sur le "coût" de skip : je vous ai posté des tests où l'on voir clairement que sa désactivation règle le problème…
ce qui se comprend aisément si l'on considère que selon vos propres explications "pythagor" à très certainement un coût CPU très inférieur à celui de "next()"… (une différence de carrés contre un "rand" ou équivalent…)

bref, ce serait quand même plus simple que vous postiez la totalité du code…

Citation:

---

Envoyé par JeitEmgie

vous avez d'autres typos dans le code que vous avez posté :
Pythagor est appelé une fois avec 1 paramètre, l'autre avec 2…
si effectivement il prend 2 paramètres alors le skip avec "2 * …" se comprenait…
Bonjour,
Il sera difficile (impossible) de mettre ici les sources sur lesquelles je travaille.
Les typos résultent de quelques découpes sauvages et empressées , comme je le soulignais, pour soumettre à la lecture de 3DArchi qui m’y avait invité (merci encore), la structure blobale de mon code. Par ailleurs je tenais principalement faire avaliser la mise en place des instructions du threading, (briques sur lesquelles je m’étais déjà bien fais mal à la tête et que je pensais à l’origine de mon pb. J’explore pour la première fois le C++ multithreadé, je ne sais même pas déboguer ça.
et avec un seul paramètre : le (i+1) se justifie comment ? le premier thread (i=0) n'a rien à skipper, non ?
et maintenant vous introduisez "uni()" … "next()" appelle aussi "uni()" ? …
Découpe d’une partie de mon code original là-encore: je réalise dans une « boucle « 1, la construction de mes « index sup » de tirage, puis je j’appelle Skip en consentant à chaque fois et modulo une bidouille pas très propre le « gaspillage » des i premières séquences du tirage pour le tirage courant. Pour moi, le thread 0 tire dans ce cadre une séquence longue de
1*nbSimulation/nbThread éléments?
pour ce qui est de votre raisonnement sur le "coût" de skip : je vous ai posté des tests où l'on voir clairement que sa désactivation règle le problème…
ce qui se comprend aisément si l'on considère que selon vos propres explications "pythagor" à très certainement un coût CPU très inférieur à celui de "next()"… (une différence de carrés contre un "rand" ou équivalent…)

bref, ce serait quand même plus simple que vous postiez la totalité du code

Je tâche de revenir avec un résultat sur les pistes de modifications que vous suggérez au niveau d'un stockage amont de tout le Rand. Merci bien de toute façon.

---

Citation:

---

Envoyé par JeitEmgie

et alors ? cette partie fait partie du benchmark... qui a priori est sur l'ensemble du calcul...

---

C'est pas pour chipoter, mais tu parlais d'appeler skip avant la génération des threads... Je me suis juste contenté de dire que c'était déjà le cas. Ensuite, que cela fasse partie du benchmark et que cela puisse être très consommateur de temps, c'est effectivement tout à fait probable.

Citation:

---

Envoyé par JeitEmgie

question de goût : priorité au raisonnement...

---

discussion ouverte il y a une semaine. En - d'une demi-journée on instrumente, on mesure et on a matière plus concrète pour raisonner :mouarf:

Citation:

---

Envoyé par simong

Les précautions à apporter en termes de synchro (mutex) ici, y’a matière à? Merci bcp, à +

---

Je rejoint JeitEmgie : à un moment, il va nous falloir un plus de code car là les infos ne sont pas suffisantes.

Alors bonjour, je vous ai fait une fusion de mes en-êtes et d’un bout de mes sources un peu plus propre, normalement, et puis j’ai mis mon main avec le boost::timer de 3DArchi. J’ai simplifié le traitement de Pythagor qui rend pour le cas qui m’intéresse une grandeur facile à analyser à travers l’échantillonnage de grandeurs statistiques (la moyenne et d’un écart type. D’une variable aléatoire qui est tirée entre 0 et 1)
Ca retrouve bien la moyenne (0.5), ça galère encore un peu pour la variance (1/12=0.083 normalement mais je vais regarder), ça galère surtout côté temps d’exécution:

Grandeurs comparables en « mono thread » et « 1 thread » (0.5s)
ça fait peur (?) dès qu’on met n>=2 threads: temps d’exécution fois 4!
Mais la nouveauté ici c’est que pour 2, 5 ou 10 threads, le temps de calcul ne bouge pas Je vois pas ce qui m’échappe en même temps je trouve pas ça très normal. J’ai aussi fait un essai mutex mais ça ébranle pas le bestiau. Voilà le tou:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156

typedef boost::mt19937 ref_generator_type; class Rand_Gen { private: ref_generator_type generator; boost::uniform_real<> uni_dist; boost::variate_generator<ref_generator_type&, boost::uniform_real<> > uni; public: Rand_Gen() :generator(42u),uni_dist(0,1),uni(generator,uni_dist) { } double Next() { return uni(); } vector<double> Skip(size_t _start_idx,size_t _length) { vector<double> v; size_t end_idx=_start_idx+_length; for (size_t i=_start_idx;i<end_idx;++i) v.push_back((*this).tempVec[i]); return v; } void sampleVect(vector<double> &_v, size_t _n) { for(size_t i=0;i<_n;++i) _v.push_back(Next()); } vector<double> tempVec, vec; void sampleVectAlea(size_t _n) { for (size_t i=0;i<_n;++i) (*this).tempVec.push_back(Next()); } };   struct Result { Result() :mean(0.0),var(0.0) {} double mean; double var; };   class Threaded_Sim_Class { private: Rand_Gen gen; size_t nbSimulations; bool isMT; struct MT_Data { Result mt_resStruct; size_t nbSimulations; Rand_Gen gen; }; vector<boost::shared_ptr<MT_Data>> threadData; size_t nbThreads; public: Threaded_Sim_Class(size_t _nbSimulations) :isMT(false),nbSimulations(_nbSimulations),gen() {} Threaded_Sim_Class(size_t _nbSimulations,size_t _nbThreads) :nbThreads(_nbThreads),threadData(_nbThreads),nbSimulations(_nbSimulations),gen() { isMT=true; } ~Threaded_Sim_Class() {} double Pythagor(double _u) { return _u; }   Result getResult() { Result res; if(!isMT) { for(size_t i=0; i<nbSimulations; i++) { double tmp=Pythagor(gen.Next()); res.mean+=tmp; res.var+=tmp*tmp; } res.mean/=nbSimulations; res.var=res.var/nbSimulations-(res.mean*res.mean); } else { gen.sampleVectAlea(nbSimulations);//alea global for(size_t i=0; i<nbThreads; i++) { threadData[i]=boost::shared_ptr<MT_Data>(new MT_Data); threadData[i]->nbSimulations=nbSimulations/nbThreads; gen.vec=gen.Skip(i*nbSimulations/nbThreads,nbSimulations/nbThreads); threadData[i]->gen.vec=(*this).gen.vec; } boost::thread_group tg; for(size_t i=0;i<nbThreads;++i) { tg.create_thread(boost::bind(&Threaded_Sim_Class::getResult,this,i)); } tg.join_all(); for(size_t i=0;i<nbThreads;i++) { res.mean+=threadData[i]->mt_resStruct.mean; res.var+=threadData[i]->mt_resStruct.var; } res.mean/=nbThreads; res.var/=nbThreads; } return res; } boost::mutex m; void getResult(size_t _j) { //m.lock(); boost::shared_ptr<MT_Data> td=threadData[_j]; size_t strace=td->nbSimulations; double dtrace=0; for(size_t i=0;i<td->nbSimulations;++i) { double tmp=Pythagor(td->gen.vec[i]); td->mt_resStruct.mean+=tmp; td->mt_resStruct.var+=tmp*tmp; } dtrace=td->mt_resStruct.var; td->mt_resStruct.mean/=td->nbSimulations; td->mt_resStruct.var=td->mt_resStruct.var/nbSimulations-(td->mt_resStruct.mean*td->mt_resStruct.mean); dtrace=td->mt_resStruct.var; //m.unlock(); } };   long main() { size_t N=1000000, n=2; { Threaded_Sim_Class tscObj(N); boost::timer t; Result result=tscObj.getResult(); cout << "runtime monothread: " << t.elapsed() << " s" << "\n"; cout << result.mean << '\t' << result.var << '\n'; } { Threaded_Sim_Class tscObj(N,n); boost::timer t; Result result=tscObj.getResult(); cout << "runtime " << n << " thread(s): "<< t.elapsed() << " s" << "\n"; cout << result.mean << '\t' << result.var << '\n'; } cout << "\n"; return 1; }

---

le travail effectué par chaque thread est sans doute trop léger par rapport à l'overhead des pthreads…

Ah ben voila, avec un peu de code c'est plus clair.
Il y a deux raisons qui expliquent tes performances décevantes simong.

1) Quelques maladresses dans l'implémentation de la version multi-thread plombent un peu tes perfs.

2) Ton opération Pythagor+moyenne est intrinsèquement beaucoup trop légère pour être accéléré par du multi-threading. Deux addition et une multiplication, c'est pas assez pour espérer gagner quoi que ce soit.

Par contre, si ton opération Pythagor est plus complexe, ça peut valoir le coup. Par exemple avec ta version on commence à voir des gains coté MT avec la fonction pythagore suivante :

Code:

---

1 2 3 4 5

double Pythagor(double _u) { return cos(cos(cos(cos(cos(cos(cos(_u))))))); }

---

:yaisse2: Et en Bonus :yaisse2:
Les threads bas niveau c'est has-been. :mrgreen:
Pour être awesome et épater vos amis, voici la version Intel TBB + C++0x!

RandGen.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

#include <boost/random.hpp> #include <vector> typedef boost::mt19937 ref_generator_type;   class RandGen { private: ref_generator_type generator; boost::uniform_real<> uni_dist; boost::variate_generator<ref_generator_type&, boost::uniform_real<> > uni; public: RandGen(): generator(42u),uni_dist(0,1),uni(generator,uni_dist) { }   double Next() { return uni(); }   std::vector<double> sampleVectAlea(size_t _n) { std::vector<double> alea; alea.reserve(_n);   for (size_t i = 0 ; i <_n ; ++i) alea.push_back(Next());   return alea; } };

---

main.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88

#include <tbb/tbb.h>   #include "RandGen.h" #include <vector> #include <boost/timer.hpp>   struct Result { Result():mean(0.0),var(0.0) {} Result(double mean, double var):mean(mean), var(var){} double mean; double var; };   Result operator+(const Result& r1, const Result& r2) { return Result(r1.mean + r2.mean, r1.var + r2.var); }   double Pythagor(double _u) { return _u; }   Result SingleThread_Sim(size_t nbSimulations) { RandGen gen; Result res;   for(size_t i=0; i <nbSimulations; i++) { double tmp=Pythagor(gen.Next()); res.mean+=tmp; res.var+=tmp*tmp; }   res.mean /= nbSimulations; res.var = res.var / nbSimulations - (res.mean * res.mean); return res; }   Result MultiThread_Sim(size_t nbSimulations) { RandGen gen; std::vector<double> alea = gen.sampleVectAlea(nbSimulations);   Result res = tbb::parallel_reduce( tbb::blocked_range<double*>(alea.data(), alea.data() + alea.size() ), Result(), [](const tbb::blocked_range<double*>& range, Result r) -> Result { for( double* a = range.begin(); a != range.end(); ++a ) { double p = Pythagor(*a); r.mean += p; r.var += p * p; } return r; }, std::plus<Result>() );   res.mean /= nbSimulations; res.var = res.var / nbSimulations - (res.mean * res.mean); return res; }   int main() { size_t N = 100000000;   { boost::timer t; Result result = SingleThread_Sim(N); std::cout << "runtime monothread: " << t.elapsed() << " s" << "\n"; std::cout << result.mean << '\t' << result.var << '\n'; }   { boost::timer t; Result result = MultiThread_Sim(N); std::cout << "runtime multithread: "<< t.elapsed() << " s" << "\n"; std::cout << result.mean << '\t' << result.var << '\n'; }   std::cout << "\n"; }

---

Avec cette version on obtient à peu près les mêmes timing entre la version mono et multi thread avec une fonction Pythagor vide. Des que Pythagor se complique un peu, le gain du MT apparait nettement. :ccool:

Citation:

---

Envoyé par Arzar

Ah ben voila, avec un peu de code c'est plus clair.
Il y a deux raisons qui expliquent tes performances décevantes simong.

1) Quelques maladresses dans l'implémentation de la version multi-thread plombent un peu tes perfs.

2) Ton opération Pythagor+moyenne est intrinsèquement beaucoup trop légère pour être accéléré par du multi-threading. Deux addition et une multiplication, c'est pas assez pour espérer gagner quoi que ce soit.

…

Avec cette version on obtient à peu près les mêmes timing entre la version mono et multi thread avec une fonction Pythagor vide. Des que Pythagor se complique un peu, le gain du MT apparait nettement. :ccool:

---

on est donc 2 du même avis…
pour compléter l'analyse voilà un benchmark en utilisant GCD (une autre librairie "light " de threading…) sur un 8 cœurs :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99

0.499926 0.0833593 10000000 benchSimulator 1 threads: 23087635 ns 0.0231 sec 0.499926 0.0833593 10000000 benchSimulator 2 threads: 11480357 ns 0.0115 sec 0.499926 0.0833593 10000000 benchSimulator 4 threads: 8781267 ns 0.0088 sec 0.499926 0.0833592 10000000 benchSimulator 8 threads: 11653867 ns 0.0117 sec 0.499926 0.0833592 10000000 benchSimulator 16 threads: 5853897 ns 0.0059 sec   0.499975 0.0833595 20000000 benchSimulator 1 threads: 46323583 ns 0.0463 sec 0.499975 0.0833595 20000000 benchSimulator 2 threads: 32905020 ns 0.0329 sec 0.499975 0.0833595 20000000 benchSimulator 4 threads: 17016605 ns 0.0170 sec 0.499975 0.0833595 20000000 benchSimulator 8 threads: 14129530 ns 0.0141 sec 0.499975 0.0833594 20000000 benchSimulator 16 threads: 13027681 ns 0.0130 sec   0.499963 0.0833506 30000000 benchSimulator 1 threads: 68635326 ns 0.0686 sec 0.499963 0.0833506 30000000 benchSimulator 2 threads: 49441516 ns 0.0494 sec 0.499963 0.0833506 30000000 benchSimulator 4 threads: 25205901 ns 0.0252 sec 0.499963 0.0833506 30000000 benchSimulator 8 threads: 21313353 ns 0.0213 sec 0.499963 0.0833505 30000000 benchSimulator 16 threads: 22071225 ns 0.0221 sec   0.49999 0.0833574 40000000 benchSimulator 1 threads: 89597187 ns 0.0896 sec 0.49999 0.0833574 40000000 benchSimulator 2 threads: 59447328 ns 0.0594 sec 0.49999 0.0833574 40000000 benchSimulator 4 threads: 36500150 ns 0.0365 sec 0.49999 0.0833574 40000000 benchSimulator 8 threads: 22690614 ns 0.0227 sec 0.49999 0.0833574 40000000 benchSimulator 16 threads: 25736769 ns 0.0257 sec   0.499984 0.0833481 50000000 benchSimulator 1 threads: 111737589 ns 0.1117 sec 0.499984 0.0833481 50000000 benchSimulator 2 threads: 74131346 ns 0.0741 sec 0.499984 0.0833481 50000000 benchSimulator 4 threads: 45278567 ns 0.0453 sec 0.499984 0.0833481 50000000 benchSimulator 8 threads: 28661595 ns 0.0287 sec 0.499984 0.0833481 50000000 benchSimulator 16 threads: 30730253 ns 0.0307 sec   0.499974 0.0833469 60000000 benchSimulator 1 threads: 139367362 ns 0.1394 sec 0.499974 0.0833469 60000000 benchSimulator 2 threads: 98164232 ns 0.0982 sec 0.499974 0.0833469 60000000 benchSimulator 4 threads: 49928390 ns 0.0499 sec 0.499974 0.0833469 60000000 benchSimulator 8 threads: 35138936 ns 0.0351 sec 0.499974 0.0833469 60000000 benchSimulator 16 threads: 35932576 ns 0.0359 sec   0.499984 0.0833443 70000000 benchSimulator 1 threads: 164312297 ns 0.1643 sec 0.499984 0.0833442 70000000 benchSimulator 2 threads: 113705721 ns 0.1137 sec 0.499984 0.0833442 70000000 benchSimulator 4 threads: 59007812 ns 0.0590 sec 0.499984 0.0833442 70000000 benchSimulator 8 threads: 44368048 ns 0.0444 sec 0.499984 0.0833442 70000000 benchSimulator 16 threads: 36701681 ns 0.0367 sec   0.5 0.0833414 80000000 benchSimulator 1 threads: 184234482 ns 0.1842 sec 0.5 0.0833414 80000000 benchSimulator 2 threads: 128443534 ns 0.1284 sec 0.5 0.0833414 80000000 benchSimulator 4 threads: 67449588 ns 0.0674 sec 0.5 0.0833414 80000000 benchSimulator 8 threads: 44285955 ns 0.0443 sec 0.5 0.0833414 80000000 benchSimulator 16 threads: 42433204 ns 0.0424 sec   0.499994 0.0833428 90000000 benchSimulator 1 threads: 239967578 ns 0.2400 sec 0.499994 0.0833428 90000000 benchSimulator 2 threads: 144906967 ns 0.1449 sec 0.499994 0.0833428 90000000 benchSimulator 4 threads: 79507369 ns 0.0795 sec 0.499994 0.0833427 90000000 benchSimulator 8 threads: 55318992 ns 0.0553 sec 0.499994 0.0833427 90000000 benchSimulator 16 threads: 49335229 ns 0.0493 sec

---

Citation:

---

Envoyé par JeitEmgie

on est donc 2 du même avis…
pour compléter l'analyse voilà un benchmark en utilisant GCD (une autre librairie "light " de threading…) sur un 8 cœurs :

---

Oui, mais tu benches quoi exactement là JeitEmgie ?
Tes résultats laissent entendre un gros gain à chaque thread rajouté, mais, chez moi, avec le code original de simong - c'est à dire avec une fonction pythagor qui ne fait rien - le temps passé à calculer mean et var est presque négligeable par rapport au temps nécessaire à générer les nombres aléatoires. Donc le nombre de thread ne devrait pas jouer ?

Citation:

---

Envoyé par Arzar

Oui, mais tu benches quoi exactement là JeitEmgie ?
Tes résultats laissent entendre un gros gain à chaque thread rajouté, mais, chez moi, avec le code original de simong - c'est à dire avec une fonction pythagor qui ne fait rien - le temps passé à calculer mean et var est presque négligeable par rapport au temps nécessaire à générer les nombres aléatoires. Donc le nombre de thread ne devrait pas jouer ?

---

bonne remarque…

le benchmark est sur la totalité du calcul… mais par paire de (nSimulations, nThreads)…
et la génération des nombres aléatoires est faite une seule fois par valeur de nSimulations…

si l'on inclut celle-ci au bench pour chaque paire (nSimulations, nThreads), alors l'amélioration de 1 thread à 8 threads est de l'ordre de 15 à 25% et négligeable de 8 à 16 threads…

et évidemment cette génération représente presque 95% du temps de calcul…

(et pour la petite histoire : je n'utilise pas le code original… j'ai utilisé ce sujet comme prétexte pour m'amuser avec GCD, par simple curiosité…)

tout çà ne change rien aux conclusions :

a. si les threads sont utilisés il faut que le calcul effectué par chaque thread en vaille la peine (un "gros" calcul CPU-bounded ou qu'il contienne un minimum d'IO…)
b. utiliser des librairies à faible overhead par rapport aux pthreads repousse la limite de "légèreté" acceptable du calcul mais ne change rien au raisonnement de base
c. on peut, sans crainte de se tromper beaucoup, ajouter que plus le calcul est léger plus le risque que ce soient les accès mémoire en écriture qui deviennent le bottleneck qui ralentit les threads est élevé (dans un cas où les résultats des calculs seraient stockés individuellement par exemple, mais ce n'est pas ce que nous avons ici… on lit beaucoup d'adresses mémoires différentes - les nombres aléatoires - mais on n'écrit que dans un nombre bien défini - les résultats locaux aux threads…)

et dans cet exemple-ci :
disposer d'un générateur de nombre aléatoire parallélisable apporterait un "énorme" gain…
donc avoir une API à laquelle on demanderait de remplir le tableau et qui se chargerait de le faire en utilisant les threads (légers) en fonction de la taille de celui-ci…

J'en encore eu 5 minutes pour tester une librairie parallélisable de générateur de nombres aléatoires : http://math.asu.edu/~eubank/webpage/rngStreamPaper.pdf
(j'ai remplacé OpenMP par GCD…)

et le benchmark complet "génération et calcul" donne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

0.499926 0.0833593 10000000 benchRngStream 1 threads: 229833484 ns 0.2298 sec 0.499926 0.0833593 10000000 benchRngStream 2 threads: 171874116 ns 0.1719 sec 0.499926 0.0833593 10000000 benchRngStream 4 threads: 169751145 ns 0.1698 sec 0.499926 0.0833592 10000000 benchRngStream 8 threads: 166911711 ns 0.1669 sec 0.499926 0.0833591 10000000 benchRngStream 16 threads: 159357028 ns 0.1594 sec

---

Salut, un merci à tous. Arzar, je fixe maintenant les « points chauds » de mon source de départ, c’est clair. J'avais pas trop analysé la dimension « charge-CPU » et recherche du gain MT sous cet angle.
Je vais peut-être pouvoir faire maintenant un essai avec TBB. Au passage tu entendais quoi exactement avec «threads bas niveaux »? JeitEmgie, je ne te cache pas que j'ai pas toujours percuté sur tous tes arguments (mon noviciat peut-être) mais je ne doute pas de la pertinence de ton argumentaire. Je ne manque pas de vous tenir au jus, Bien cool d’avoir pu avancer grâce à vous.

Salut,
Alors j'ai un peu regardé, pour TBB. Et voilà ce que j'ai :
en gardant tout pareil par ailleurs (RanGen et Result) j'ai déporté dans une classe (My_Sim_Class) mes variables

private :
(double*) pAleaVect
et
(Result*) pRes;
(Donc ce sont des pointeurs.)

Comme méthodes de la classe, j'ai moi la surcharge d'opérateur:
Public:

Code:

---

1 2 3 4 5 6 7

void operator() (const tbb::blocked_range<size_t> &r) ; //Qui fait : { Double tmp=0; for (size_t i=r.begin(); i!=r.end(); ++i) tmp+=pAleaVect[i]; pRes->mean=tmp; }

---

Et ja'i :

Code:

---

1 2 3 4 5 6 7 8

Result getResult_tbb(size_t _nbSimulations) qui fait : { Size_t blocked_range_size_=1000; tbb::parallel_for(tbb::blocked_range<size_t>(0, _nbSimulations,blocked_range_size_), My_Sim_Class(pAleaVect,pRes)); res_.mean=(*pRes).mean/(_nbSimulations/blocked_range_size_); return res_; }

---

Dans un main je fais:

Code:

---

1 2 3 4 5

{ size_t nbSimulations=100000; My_Sim simObj(aleaVectlea,res); res=simObj.getResult_tbb(nbSimulations); }

---

Donc initialisation de mon vecteur d'alea, une instanciation et un appel du calcul carrément standards.

J'ai deux questions:
Comment le nombre de threads est ici passé? C'est TBB qui fait en fonction du rapport nbSimulations /blocked_range_size_?

Ca compile et ça tourne, mais, manque de pot pour moi je trouve des résultats délirants pour mon calcul de "mean" alors que ça devrait être tout simple.

Est-ce que j'aurais justement pas fauté avec ces histoires de priorité/attente de threads et les mutex du coup?
Est-ce que quelqu'un a une piste ?
Merci

Bonjour, je ne suis pas arrivé à faire tourner le source posté par Arzar (je comprends pas tout de ce qu'il y a dans les paramètres), et mon essai à moi de faire tourner TBB n'a pas trop donné (mais en ce qui me concerne je pense que c'est quelque chose de complè_complètement basique qui m'échappe, bref....), est-ce que vous auriez la possilbité de donner des indications sur ce qui vous paraîtrait pas OK? Ca serait juste pas mal de pouvoir tester ce qui peut être fait avec l'approche autre que Boost. A+ et merci.

Tu n'as pas eu mon MP, simong ?
Je le recopie au cas ou

Citation:

---

Envoyé par Arzar

Salut simong.
Bon, j'ai quelques remords d'avoir parler de TBB sur le thread. Je n''ai malheureusement pas été assez clair mais TBB n'est *pas* l'approche que je conseillerais dans ton cas. C'était plus une petite gourmandise de ma part, pour s'amuser un peu avec TBB et le C++0x (la syntaxe en [] c'est pour les lambda de la prochaine norme)

Non, pour ton cas, il est beaucoup plus indiqué d'utiliser openMP. C'est la solution standard pour le multi-threading et le calcul scientifique en C/C++ et fortran. Il est dispo sur presque tous les compilateurs de la planète (par exemple il suffit d'un include et d'un switch pour l'activer sur Visual C++) et surtout il est beaucoup, beaucoup plus simple à appréhender que TBB. OpenMP ne s'intéresse principalement qu'à la parallélisation de boucle for et ainsi qu'aux types basiques (int, float, double). Au final, il n'y a donc qu'une poignée de concept à comprendre et souvent peu de code à modifier. Découvrir et maitriser openMP, c'est l'affaire d'une demi-journée.

Avec openMP, on obtient :

Randgen.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

#include <boost/random.hpp> typedef boost::mt19937 ref_generator_type;   class RandGen { private: ref_generator_type generator; boost::uniform_real<> uni_dist; boost::variate_generator<ref_generator_type&, boost::uniform_real<> > uni; public: // nouveau constructeur qui prend la graine en paramètre RandGen(boost::uint32_t seed): generator(seed),uni_dist(0,1),uni(generator,uni_dist) { }   RandGen():generator(42u),uni_dist(0,1),uni(generator,uni_dist) { }   double Next() { return uni(); } };

---

main.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80

#include "RandGen.h" #include <omp.h> #include <ctime> #include <boost/timer.hpp>   struct Result { Result():mean(0.0),var(0.0) {} Result(double mean, double var):mean(mean), var(var){} double mean; double var; };   double Pythagor(double _u) { return _u; }   Result SingleThread_Sim(size_t nbSimulations) { RandGen gen; Result res;   for(size_t i=0; i <nbSimulations; i++) { double tmp=Pythagor(gen.Next()); res.mean+=tmp; res.var+=tmp*tmp; }   res.mean /= nbSimulations; res.var = res.var / nbSimulations - (res.mean * res.mean); return res; }   Result MultiThread_Sim(size_t nbSimulations) { double mean = 0.0; double var = 0.0;   #pragma omp parallel { RandGen gen(int(time(NULL)) ^ omp_get_thread_num());   #pragma omp for reduction(+:mean), reduction(+:var) for(int i=0; i <nbSimulations; i++) { double tmp = Pythagor(gen.Next());   mean += tmp; var += tmp*tmp; } }   mean /= nbSimulations; var = var / nbSimulations - (mean * mean); return Result(mean, var); }   int main() { size_t N = 100000000;   { boost::timer t; Result result = SingleThread_Sim(N); std::cout << "runtime monothread: " << t.elapsed() << " s" << "\n"; std::cout << result.mean << '\t' << result.var << '\n'; }   { boost::timer t; Result result = MultiThread_Sim(N); std::cout << "runtime multithread: "<< t.elapsed() << " s" << "\n"; std::cout << result.mean << '\t' << result.var << '\n'; }   std::cout << "\n"; }

---

Détail du code openMP :

Code:

---

1 2	double mean = 0.0; double var = 0.0;

---

la directive reduction utilisée un peu plus loin n'est applicable que sur des types basiques, donc il faut temporairement laisser tomber la structure Resut et travailler directement sur les double mean et var.

Code:

---

#pragma omp parallel

---

Ce pragma indique le début d'une section parallèle, c'est à dire une section qui sera exécutée en parallèle sur plusieurs thread

Code:

---

1 2	{ RandGen gen(int(time(NULL)) ^ omp_get_thread_num());

---

A l'intérieur du pragma parallel, une variable déclarée est locale à chaque thread. Donc, par exemple ici, sur un quad-core, on construirait quatre Randgen avec quatre graines légèrement différentes à chaque fois (en utilisant le numéro du thread pour faire varier la graine)

Code:

---

#pragma omp for...

---

La directive indiquant que la boucle qui suit doit être paralléllisée.

Code:

---

reduction(+:mean), reduction(+:var)

---

C'est la seule difficulté. La directive réduction (op : var) indique que dans la boucle for la variable "var" est locale à chaque thread, *mais*, tout à la fin, on appliquera automatiquement l'opération de réduction op sur la variable partagée de même nom. Par exemple sur un quad-core reduction (+:mean) signifie que quatre variables mean vont être créée, une pour chaque thread, et qu'à la fin de la boucle for, la variable mean partagée, cad déclarée avant la section #pragma parrallel va être mis à jour quatre fois, en faisant mean = mean + mean_thread1; mean = mean + mean_thread2 etc.

Code:

---

1 2 3 4 5 6 7

for(int i=0; i <nbSimulations; i++) { double tmp = Pythagor(gen.Next());   mean += tmp; var += tmp*tmp; }

---

le reste est identique à la version monothread.

---

Si tu veux vraiment rester avec la version TBB (qui est moins performante que le code OpenMP donné plus haut, car la version TBB précalcule un énorme vecteur de nombre aléatoire alors que le code OpenMP utilise N générateur aléatoire en parallèle, N étant le nombre de thread), j'avais jeté un coup d'oeil à ton code et il me semble qu'il était quasiment bon.
Si je me souviens bien, la seule modif était de remplacer :

Code:

---

1 2	res_.mean=(*pRes).mean/(_nbSimulations/blocked_range_size_);

---

par

Code:

---

1 2	res_.mean=(*pRes).mean/(_nbSimulations);

---

Je ne comprends d'ailleurs pas du tout ce que viendrait faire le blocked_range_size dans le calcul final... blocked_range_size est utilisé par le parrallel_for pour découper l'intervalle [0; nbSimulation] en sous-intervalle de taille approximative blocked_range_size (car blocked_range_size n'est qu'une suggestion pour TBB, qui au final choisi la taille qui l'arrange). L'idée c'est que des threads peuvent ensuite parcourir les sous-intervalles en parallèle sans se marcher dessus. Mais une fois sortit du parrallel_for, blocked_range_size n'est plus d'aucune utilité, non ? :koi:

Citation:

---

Envoyé par Arzar

Je le recopie au cas ou

---

Ca aurait été dommage qu'il soit le seul à en profiter ;)
Ceci dit, il me semble qu'OpenMP n'est pas disponible avec les versions Express de Visual, non ?

Citation:

---

Envoyé par 3DArchi

Ceci dit, il me semble qu'OpenMP n'est pas disponible avec les versions Express de Visual, non ?

---

Euuu oui bon point. :aie:
OpenMP n'est effectivement malheureusement pas disponible pour les versions express. :?

Salut, merci beaucoup pour les détails. Sur ton MP je ne te cache pas que j'avais pas tout saisi et que partir sur open MP, j'avais regardé mais outch, ça me paraissait bien compliqué. Là avec tes explications c'est déjà bien plus accessible. Oui en effet pour mon code, j'avais pas nettoyé une ligne qui m'avait servi à tracer un résultat raison pour laquelle tu t'étonnes à juste titre de la présence de "blocked_range_size" en fin de mon traitement. Merci pour ta remarque en tout cas et en effet, pour l'erreur "basique" que je cherchais c'est juste que je ne lisais pas correctement ma structure de résultats, maintenant c'est tout bon. J'essaie de regarder pour le OpenMP. A+