Multit�che vs threads vs OpenMP : que choisir [Conception, Optimisation]
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:
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 :question:
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 :calim2: ) 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. :aie:
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 :D
