Discussion :

[Seabirds]

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

[Matt_Houston]

Paralléliser une boucle de calcul scientifique (i.e. : où tous les threads font grosso modo la même chose sur un jeu de données indépendant), c'est typiquement le cas d'utilisation où OpenMP excelle. C'est mis en œuvre en trois, quatre lignes avec un parallel for.

[Seabirds]

Cool ça me rassure merci !!! je fonce relire la doc de OpenMP alors

Par curiosité, quels sont les cas classiques où j'aurais du me dire "mmhhh là je vais plutôt std::async" ou "là c'est un cas typique de std::thread" ? Il y a beaucoup de tutos pour les unes ou les autres méthodes, mais j'ai trouvé peu d'indications sur les cas où mettre en oeuvre telle ou telle approche

Question peut-être liée : admettons que j'utilise OpenMP pour la boucle la plus externe du programme. Est-ce qu'il y a encore moyen (pour le noob que je suis) de gratter des perfs avec le multithreading/multitasking/parrallelisation ? Je pense aux petites régions parallélisables plus internes du code. On peut avoir une intuition sur les performances espérées ou bien en est on réduit à benchmarker chaque implémentation pour voir son gain éventuel ?

[dalfab]

Bonjour,

En fait, les trois moyens que tu as vu, sont différentes facette de la capacité à utiliser le CPU disponible. OpenMP et async sont les plus accessibles pour des calculs, les threads sont toujours la même chose avec plus de possibilités. Il est inutile de les combiner. Attention avec 4 coeurs tu devrais au mieux diviser tes temps par 2.

[Seabirds]

Bonjour,

En fait, les trois moyens que tu as vu, sont différentes facette de la capacité à utiliser le CPU disponible. OpenMP et async sont les plus accessibles pour des calculs, les threads sont toujours la même chose avec plus de possibilités. Il est inutile de les combiner. Attention avec 4 coeurs tu devrais au mieux diviser tes temps par 2.

Ok, donc en gros une fois que j'ai utilisé OpenMp sur la boucle extérieure, inutile d'espérer gratter plus de CPU disponible. Il faudra j'imagine aller gratter côté algorithmes et structures de données
Aie zut, seulement un facteur 2 ? Saperlipopette, mon intuition était donc fausse !

[bacelar]

Si les traitement sont hautement parallèles, on peut voir du coté des GPU à la place de CPU.

[Ehonn]

Ok, donc en gros une fois que j'ai utilisé OpenMp sur la boucle extérieure, inutile d'espérer gratter plus de CPU disponible.

Si le problème s'y prête, et que le compilateur ne le fait pas déjà, tu peux vectoriser le calcul (avec les instructions SIMD.
Par exemple, si tu utilises des float de 32 bits et que ton processeur supporte AVX2 (registre de 256 bits), tu peux (espérer) gagner un facteur 8 (256 / 32).

Tu dois aussi vérifier si tu fais les accès mémoire "dans le bon sens" ; c'est-à-dire, dans le sens de la mémoire.

Mais effectivement, il faut regarder / vérifier l'algorithme avant.