Bonjour � toutes et � tous !

J'ai fini une premi�re version d'un bout de code. En gros, on fait tourner l'algo suivant (avec un mod�le plus complexe que std::poisson, et le code ci-dessous n'a que vocation d'illustration ).

Code : S�lectionner tout - Visualiser dans une fen�tre � part
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
 
using data_type = int;
using model_type = std::poisson_distribution<data_type>;
using param_type = model_type::param_type;
 
std::default_random_engine g;
 
model_type model(20);
data_type observed = model(g);
 
std::uniform_distribution<param_type> search_domain(0,100);
param_type threshold(2);
std::vector<param_type> acceptations;
 
current_accepted = 0;
while(nb_accepted < 1000000){
  param_type try = search_domain(g);
  model.param(try);
  data_type simulation = model(g);
  if( data.distance_to(simulation) <= threshold) {
     acceptations.push_back(try); // oui, bon on pourrait faire un reserve, mais c'est pour l'exemple ^^
     ++current_accepted;
  }
}
// on print acceptations dans un fichier
// on calcule la moyenne de acceptations et on espère que c'est pas trop loin de 20.
Le nombre de simulations � accumuler est assez gros (millions/milliards), et �videmment on ne fait pas �a avec la loi de poisson : le mod�le de simulation est un poil long � calculer �galement.
Pour une version tr�s all�g�e du mod�le et un nb_accepted tr�s restreint, �a met d�j� plusieurs heures � tourner. Du coup l� j'atteins le moment o� la question de l'optimisation devient l�gitime n'est-ce-pas

Pour note, mon ordi est multi-coeur et j'ai acc�s � la grappe de calcul du labo.

Comme chaque it�ration est ind�pendante, on pourrait parall�liser la boucle for et faire un gain de performance d'un ordre de grandeur �quivalent au nombre de coeurs (d�sol� pour les �carts de langage, je sais � peine ce qu'est un coeur ) n'est ce pas ?

  • Quand je lis le chapitre Programmation Concurrente du bouquin de Scott Meyers (Programmer efficacement en C++11/14), le mot cl� est multit�che, � coup de std::async, std::future ... J'ai sans doute mal interpr�t� le cadre dans lequel �merge ce besoin, mais j'ai cru comprendre que c'�tait une bonne direction � prendre (mais j'ai pas tout compris ).
  • Quand je lis diff�rentes ressources, il y a des std::threads un peu partout, �a je comprends � peu pr�s.
  • Quand je lis les messages du forum Threads&Processus, ce qui semble correspondre � mon besoin serait OpenMP, mais j'ai peur d'y aller tous azimuts en me plantant all�grement de direction.


Pourriez-vous me faire part de vos conseils quant � la direction � prendre ? Si j'ai une premi�re direction je pourrai focaliser mes efforts de documentation dessus
En vous remerciant