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.

[Pyramidev]

Bonjour,

Dans la boucle, je vois qu'il y a des acc�s � un objet commun std::default_random_engine.
Pour �viter de synchroniser les acc�s � un g�n�rateur commun (qui serait construit hors de la boucle) et pour �viter aussi de cr�er 1 000 000 g�n�rateurs (qui seraient chacun construit dans la boucle), je pense que chaque thread devrait travailler avec des g�n�rateurs s�par�s.
Idem pour les autres objets qui sont communs dans le code d'origine.

On pourrait partir d'une double boucle for de la forme :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
acceptations.resize(1000000);
for(k = 0; k < 4; ++k) {
    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);
    for(i = k*250000; i < (k+1)*250000; ++i) {
        // affecter une valeur à acceptations[i]
    }
}

Ensuite, on pourrait parall�liser les it�rations de la boucle for englobante.
En C++17, la mani�re standard de le faire serait d'utiliser std::for_each avec en premier param�tre un std::execution::par pour parall�liser.
En attendant C++17, je pense que le mieux est d'utiliser OpenMP. Je ne l'ai jamais utilis� et je ne l'ai pas encore �tudi�, mais il semble que, dans le code, il suffit juste d'ajouter #pragma omp parallel for au dessus de la boucle for englobante.

[ternel]

Notons que si tu acc�des � une grille de calcul, il doit y avoir une documentation de la mani�re de r�partir le calcul sur plusieurs machines.
A moins qu'elle n'apparaisse magiquement comme un super processeur � beaucoup de c�urs, ce qui m'�tonnerait quand m�me beaucoup.

Si tes it�rations sont r�ellement ind�pendantes, tu ne devrais pas avoir de diff�rence significative entre

• ex�cuter une fois ton programme pour produire un million de r�sultats, dans un fichier de sortie
• ex�cuter mille fois ton programme pour produire mille r�sultats � chaque fois, et concatener les mille fichiers produits.

Partant de l�, rends configurable le nombre d'it�rations (argument en ligne de commande, au besoin, boost::program_options).
Ainsi, tu pourras ex�cuter le programme, pour un nombre limit� d'it�rations, sur chaque noeud de la grille de calcul.

�ventuellement, tu n'auras m�me pas � parall�liser le programme en lui-m�me. Tu pourrais imaginer le lancer plusieurs fois sur chaque noeud (par exemple, nombre de c�ur -1).

[Seabirds]

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

Je note l'information, merci . C'est accessible � quel point � un d�butant ?

Si le probl�me s'y pr�te, et que le compilateur ne le fait pas d�j�, tu peux vectoriser le calcul [...] 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.

Ok je garde �a dans un coin de ma t�te ! Ton allusion au sens de la m�moire a trait au sens de d�claration des variables membres, � l'alignement des donn�es ? (sorry, noob again ).

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 ou avec Boost.SIMD).

"Si les donn�es s'y pr�tent bien" ... j'imagine que �a veut dire que matrices et tableaux abonderaient dans le code ... Hum. Soit que j'ai choisi les mauvaises structures de donn�es (toujours possible ) soit que mon probl�me ne s'y pr�te � la base pas tr�s bien (y'a plein de stochasticit� partout), mais je n'ai aucun tableau et aucune matrice (mais beaucoup de std::vector, std::unordered_map, std::unordered_set ...).

En C++17, la mani�re standard de le faire serait d'utiliser std::for_each avec en premier param�tre un std::execution::par pour parall�liser.

Sacr� C++17, que n'es-tu pas sorti avant ma th�se ...

A moins qu'elle n'apparaisse magiquement comme un super processeur � beaucoup de c�urs, ce qui m'�tonnerait quand m�me beaucoup.

Je suis en train de me renseigner. Je crois que c'est pas forc�ment une grappe de calcul, mais un serveur multiprocesseur. Pas s�r, � voir, je note l'id�e !

Merci � tous pour vos r�ponses et ces nombreuses pistes, j'imagine que j'en ai pour des ann�es � explorer tout �a ! Ecrire un programme qui tourne est une chose, �crire un programme lisible qui tourne en est une autre, �crire un programme lisible, �volutif, qui tourne est une aventure que je veux bien tenter, mais quant � �crire un programme lisible, �volutif, fonctionnel ET EFFICACE ...

[ternel]

Il y a aussi le concept de thread pool qui peut t'int�resser.

Rappelle-toi, cependant, qu'un programme fait quelque chose.
Il doit le faire bien. Il doit �tre compr�hensible que c'est ca qu'il fait. Le code doit �tre assez clair pouvoir comprendre comment il le fait.

Maintenant, chaque fois que tu changes ne serait-ce qu'un d�tail du "quelque chose", ton programme peut devenir totalement inadapt�.

En l'occurence, tu as cod� pour un processeur simple. C'�tait ton objectif.
Si tu veux maintenant viser plusieurs syst�me s�par�s ou des c�urs d'un processeur, certaines parties de ton programme peuvent avoir � �tre modifi�e.

Changer l'objectif, c'est aussi changer la solution.
C'est la partie tr�s d�licate de la sp�cification d'un programme.

[Seabirds]

En l'occurence, tu as cod� pour un processeur simple. C'�tait ton objectif.
Maintenant, chaque fois que tu changes ne serait-ce qu'un d�tail du "quelque chose", ton programme peut devenir totalement inadapt�.

Aie, petite pointe de stress. J'avais dans l'id�e que on pouvait progresser incr�mentalement de sous-objectif en sous-objectif. Typiquement, je codais pour l'instant pour mon petit ordi, si �a marchait d�j� sur un processeur c'�tait cool, le multi-processeur je verrais apr�s. Autrement dit, je n'avais pas vraiment id�e que le nombre de processeurs pouvait beaucoup influer sur la solution !

Je serais bien tent� de demander la recette magique pour pr�voir si un sous-objectif est critique ou pas, mais j'imagine que la r�ponse serait quelque chose du genre "beaucoup d'exp�rience, de la pratique, de la veille technique, de l'intelligence et du travail".

[foetus]

Je serais bien tent� de demander la recette magique pour pr�voir si un sous-objectif est critique ou pas

Si tu es gourmand , tu pense � une application comme � un mille-feuille

Plus tu modifies les couches basses, plus tu dois refaire les couches au-dessus.

Exemple

• couches hautes: suppression d'une fonctionnalit�, suppression d'une entr�e dans un menu
• couches interm�diaires: faire un syst�me de droits
• couches basses: le "multi-threading", un "logger", l'internationalisation

[ternel]

J'ai plus l'impression que c'est "Toujours. Surtout si tu ne t'y attends pas."

En fait, � chaque fois que tu prends une d�cision dans ton code (le moindre if, par exemple), tu le fais par rapport � ton objectif.

Par exemple, si tu dois fabriquer une voiture pour aller faire tes courses, 3m� de coffre, c'est pas mal.
Si tu rajoute "pour 300 personnes", ce n'est plus vrai.

Mais ca ne change pas que le probl�me du coffre, il faudra aussi choisir un moteur plus puissant, et un autre profil a�rodynamique.
Et si tu ajoutes encore "pour un mois", passer � un camion est peut-�tre une bonne id�e.

D'une mani�re g�n�rale, les changements de quantit� sont une cause assez fr�quente de grosse restructuration du projet. (tant dans la repr�sentation de donn�es que dans la forme des algorithmes).

[Seabirds]

Ok, donc l� si �a se trouve j'ai fait un mille-feuille de 3cm³ � Paris pour alimenter les 3000 clients d'un restaurant Tokyo, et le mille-feuille fait Paris-Tokyo dans la poche arri�re d'un livreur en trotinette, c'est �a ?
Cela dit, � ma d�charge et pour mon orgueil, les clients du resto ont le choix du dessert, et peuvent aussi commander un �clair au chocolat g�ant manufactur� en Patagonie et livr� en patin � glace, comme quoi ma solution est quand m�me �volutive.

D'une mani�re g�n�rale, les changements de quantit� sont une cause assez fr�quente de grosse restructuration du projet. (tant dans la repr�sentation de donn�es que dans la forme des algorithmes).

Ok, �a laisse un peu de mou quand m�me. Donc l� j'imagine qu'on remercie l'OCP, l'encapsulation, l'abstraction etc...

Plus tu modifies les couches basses, plus tu dois refaire les couches au-dessus.

Dans mon inertie de d�butant, et c'est peut-�tre le point positif de l'affaire, je n'ai pas vraiment eu le loisir d'accumuler les couches ^^

[ternel]

Je ne suis pas pleinement d'accord avec cette histoire de couches.

plus tu as des couches distinctes, moins les changements dans l'une d'elle implique de changements cons�quents dans celles d'au dessus.

Id�alement, sauf changement de nature, une couche devrait �tre totalement invisible d'une autre qui ne serait pas directement bas�e dessus.

[Bousk]

En th�orie, tant que l'interface public ne bouge pas tu ne devrais pas avoir besoin de modifier quoi que ce soit externe au code que tu touches.

[Seabirds]

Merci pour tous ces bons rappels

Question na�ve sur laquelle j'aimerais avoir votre ressenti et votre exp�rience :

Comme je vous disais, sur une version tr�s all�g�e du mod�le bien en de�� des ambitions, je commence � avoir quelques r�sultats de mes simulations (ce qui est bienvenu pour la th�se en cours). Cela dit, je me sens d�j� restreint dans les possibilit�s d'analyse (avec le co�t calculatoire, �a va �tre dur d'explorer les conditions de simulation aussi facilement et rapidement que la statistique le voudrait... ). Et si j'ai bien suivi, ce n'est pas l'ordre de grandeur en moins apport� par le parall�lisme sur 64 processeurs qui va faire voler le rocher.

Quand un r�sultat simplistique prend plus d'une semaine � sortir, et qu'on a que quelques mois pour accumuler le plus de r�sultats possibles, comment s'y prendre ?

• les techniques d'optimisation cit�es plus haut sont-elles � ma port�e en si peu de temps ?
• quel gain d'efficacit� peut-on esp�rer ? �a d�pend peut-�tre beaucoup trop des cas d'utilisation pour pouvoir r�pondre aussi facilement... d�sol� de la question pi�ge
• est-ce que �a vaut le coup d'investir du temps pour aller traquer les goulot d'�tranglement dans les algos ?
• ou bien de toute fa�on tout ce que je pourrai faire � mon niveau serait totalement insuffisant et il serait pr�f�rable de foncer sur "quelques" r�sultats quitte � faire fondre les processeurs ?

Merci de vos r�ponses

[JolyLoic]

• quel gain d'efficacit� peut-on esp�rer ? �a d�pend peut-�tre beaucoup trop des cas d'utilisation pour pouvoir r�pondre aussi facilement... d�sol� de la question pi�ge
• est-ce que �a vaut le coup d'investir du temps pour aller traquer les goulot d'�tranglement dans les algos ?
• ou bien de toute fa�on tout ce que je pourrai faire � mon niveau serait totalement insuffisant et il serait pr�f�rable de foncer sur "quelques" r�sultats quitte � faire fondre les processeurs ?

Merci de vos r�ponses

Il m'est d�j� arriv� en 2j de travail de passer un algo de quelques heures � quelques secondes (genre en rempla�ant du O(n5) par du O(n log n)). Mais tout d�pend du niveau de codage de la solution actuelle. Mais je pense que �a vaut le coup d'essayer d'optimiser un minimum la solution de base avant de partir vers de la parall�lisation. Est-ce que les algorithmes ont la bonne complexit�, est-ce que les bonnes structures de donn�es sont utilis�es, est-ce qu'il serait possible de mettre en cache des donn�es interm�diaires (attention, peut �tre contraire � la parall�lisation, donc ne le faire que si le gain est r�el)., mes algos se pr�tent-ils � la vectorisation ? O� mon algo passe-t-il son temps (utiliser un profiler) ?

Et n'oublie pas qu'une mani�re de parall�liser consiste � lancer ton programme plusieurs fois sur plusieurs jeux de donn�es. Ce qui a l'avantage de pouvoir lancer plusieurs versions du programme sur le m�me jeu de donn�es, ce qui peut �tre pratique aussi.

Apr�s il faut trouver le bon �quilibre, et savoir s'arr�ter au bout d'un moment si on sent que les gains ne vont plus �tre significatifs.

[ternel]

Dans ton cas, tu effectues plein de simulations autonome, chacune �tant ainsi construite:

initialisation de donn�es strictement locale, dans un espace de taille N
initialisation d'une matrice N� de "fonction de transition", en gros des probabilit� de transfert (partiel ou non) de contenu entre deux cases de l'espace.

� chaque it�ration:

1. il y a d'abord �volution locale de chaque case selon une fonction d�termin�e (un foncteur cr�� plus ou moins dynamiquement pendant l'initialisation)
2. puis application de la matrice de transition.

Fonctionnellement, ta simulation totale devrait avoir une complexit� temporelle de l'ordre de T * N * Dur�e(�volution locale) + T * N * Dur�e(une transition) * N
Ton facteur limitant est le plus grand entre la dur�e d'une �volution locale et celle de l'application des transitions d'une case pr�cise vers toutes les autres.
Ce sont les deux grandeurs que tu devrais essayer de minimiser.
Une piste: essaie de voir si tu peux limiter les transitions � "vers quelques cases" seulement.

Par contre, comme ton besoin est sur des calculs num�riques, essaye d'optimiser le temps d'ex�cution des parties "atomique": l'�volution locale et la transition.
Et l�, il n'y a qu'une seule mani�re correcte de le faire: utiliser un profiller pour savoir quelle partie du code est vraiment co�teuse.