Discussion :

[Malawi]

Bonjour,
Je suis en train de faire des tests en multithread. Sur un petit programme de test, j'ai un fort ralentissement en MT que je ne comprend pas.
Je fais un calcul (qui n'a aucune valeur ici, c'est juste pour le test).
=> j'obtiens un temps en monothread (1)
Puis je fais ce même calcul N fois sur N threads. Les calculs sont indépendants donc je m'attend à obtenir à peu près le même temps que (1) mais ce n'est pas toujours le cas. Je peux obtenir un temps 10 fois plus long.

Le ralentissement est toujours plus ou moins proportionnel au nombre de thread.
Est ce du à l'accès au cache ? Est ce ma facon de c Autre chose ? Y'a-t-il un moyen d’améliorer cela ?

Ci dessous le code (que j'ai laissé volontairement le plus simple possible).

Merci

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
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
#include <iostream>
#include <unistd.h>
#include <thread>
#include <vector>
#include <array>
#include <chrono>
#include <iostream>
#include <utility>
#include <atomic>
#include <mutex>
using namespace std;
 
int TestMT2Id(int id){
    int i,j;
    int nx=5000;
    int ny=100;
    vector<double> vv(nx,0);
    for( j=0; j<nx; j++)vv[j]=j;
    double xx=0;
    for(i=0; i<ny; i++) {
        for( j=0; j<nx; j++) {
            vv[j]+=1.;
            xx+= vv[j];
        }
    }
    for( j=0; j<nx; j++) {
        xx+=vv[j];
    }
    return 0;
}
 
int main(int argc, char **argv)
{
    int num_cores=8;
    cout<<"ncpu "<<num_cores<<endl;
 
    cout<<"Test monothread  : ";
    auto start = std::chrono::system_clock::now();
    TestMT2Id(0);
    auto end = std::chrono::system_clock::now();
    std::chrono::duration<double> elapsed = end - start;
    std::cout << "Elapsed time= " << elapsed.count() << "s"<<endl;
 
    cout<<"Test multithread : ";
    auto start1 = std::chrono::system_clock::now();
    for (int i = 0; i < num_cores; i++) {
        thread t([i]() {
            TestMT2Id(i);
        });
        t.join();
    }
 
    auto end1 = std::chrono::system_clock::now();
    std::chrono::duration<double> elapsed1 = end1 - start1;
    std::cout << "Elapsed time= " << elapsed1.count() << "s"<<endl;
    return 0;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ncpu 8
Test monothread  : Elapsed time= 0.000296322s
Test multithread : Elapsed time= 0.00288444s

[jo_link_noir]

join() attend que le thread se termine, donc ici, aucun thread ne tourne en parallèle. Il faut les mettre dans std::vector ou std::array et faire la boucle sur t.join() après avoir créé tous les threads.

[Malawi]

@jo_link_noir : ok merci, je n'etais pas bien au courant de ce fait. En fait j'avais fait ce que tu preconises dans un 1er temps mais n'ai pas vu de diff sur les perfs:

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
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
#include <iostream>
#include <unistd.h>
#include <thread>
#include <vector>
#include <array>
#include <chrono>
#include <iostream>
#include <utility>
#include <atomic>
#include <mutex>
using namespace std;
 
int TestMT2Id(int id){
    int i,j;
    int nx=500000;
    int ny=10000;
    vector<double> vv(nx,0);
  //  double* vv= new double[nx];
    for( j=0; j<nx; j++)vv[j]=j;
    double xx=0;
    for(i=0; i<ny; i++)
    {
        for( j=0; j<nx; j++)
        {
            vv[j]+=1.;
            xx+= vv[j];
        }
    }
    for( j=0; j<nx; j++)
    {
        xx+=vv[j];
    }
    return 0;
}
 
int main(int argc, char **argv)
{
    int num_cores=8;
    cout<<"ncpu "<<num_cores<<endl;
 
    cout<<"Test monothread  : ";
    auto start = std::chrono::system_clock::now();
    TestMT2Id(0);
    auto end = std::chrono::system_clock::now();
    std::chrono::duration<double> elapsed = end - start;
    std::cout << "Elapsed time= " << elapsed.count() << "s"<<endl;
 
    cout<<"Test multithread : ";
    auto start1 = std::chrono::system_clock::now();
    thread threads[num_cores];
    for (int i = 0; i < num_cores; i++) {
        thread t([i]() {
            TestMT2Id(i);
        });
        threads[i] = std::move(t);
    }
    for (thread & t : threads)
        t.join();
 
    auto end1 = std::chrono::system_clock::now();
    std::chrono::duration<double> elapsed1 = end1 - start1;
    std::cout << "Elapsed time= " << elapsed1.count() << "s"<<endl;
    return 0;
}

Resultats :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ncpu 8
Test monothread  : Elapsed time= 1.89004s
Test multithread : Elapsed time= 7.41875s

[Bktero]

Il ne faut pas oublier que créer et détruire des threads prend du temps.

Si le calcul est très rapide, tu peux dégrader les performances à passer en multithread.

[Malawi]

Hello,
Je mets à jour mon code car je me suis rendu compte qu'à l'avoir trop simplifié pour le fil de discussion, il y ai de forte chance que le compilo en ait supprimé une bonne partie pour l'optim (cad variables non utilisées).
J'ai rajouté des print pour forcer le calcul dans les threads.
Encore une fois le calcul n'a pas de sens spécial, c'est juste pour l'exemple.

J'ai donc encore un facteur 2 de vitesse entre monothread et multithread que je n'explique pas vraiment.
Des avis ??

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
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
#include <iostream>
#include <unistd.h>
#include <thread>
#include <vector>
#include <array>
#include <chrono>
#include <iostream>
#include <utility>
#include <atomic>
#include <mutex>
#include <cmath>
using namespace std;
 
double TestMT2Id(int id){
    int i,j;
    int nx=500000;
    int ny=10000;
    vector<double> vv(nx,0);
    double xx=0;
    for(i=0; i<ny; i++)
    {
        for( j=0; j<nx; j++)
        {
            vv[j]+=1.;
            xx+= vv[j];
        }
    }
    return xx;
}
 
int main(int argc, char **argv)
{
    int num_cores=8;
    cout<<"ncpu "<<num_cores<<endl;
 
    cout<<"Test monothread  : ";
    auto start = std::chrono::system_clock::now();
    double xx = TestMT2Id(0);
    cout<<" xx= "<<xx;
    auto end = std::chrono::system_clock::now();
    std::chrono::duration<double> elapsed = end - start;
    std::cout << " => Elapsed time= " << elapsed.count() << "s"<<endl;
 
    cout<<"Test multithread : ";
    auto start1 = std::chrono::system_clock::now();
    thread threads[num_cores];
    xx = 0;
    for (int i = 0; i < num_cores; i++) {
        thread t([&xx, i]() {
            xx += TestMT2Id(i);
        });
        threads[i] = std::move(t);
    }
    for (thread & t : threads)
        t.join();
 
    cout<<" xx= "<<xx;
 
    auto end1 = std::chrono::system_clock::now();
    std::chrono::duration<double> elapsed1 = end1 - start1;
    std::cout << " => Elapsed time= " << elapsed1.count() << "s"<<endl;
    return 0;
}

Resultats :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ncpu 8
Test monothread  :  xx= 2.50025e+13 => Elapsed time= 6.25111s
Test multithread :  xx= 2.0002e+14 => Elapsed time= 15.977s

[Bousk]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
    int num_cores=8;
    ...
    thread threads[num_cores];

Ton compilo arriver à interpréter ça en constant compile-time pour ne pas faire un VLA qui sont interdits en C++ ?

[Astraya]

C'est normal que cela soit toujours plus lent.
Tu fais 8 fois le même travail en mutli-thread mais sans donner d'affinité entre tes threads et tes cores logiques.
Donc tes 8 threads peuvent très bien tourner uniquement sur le core 0 et dans ce cas, tu compares ta fonction faite 1 fois sur le core 0, contre la même faite 8 fois sur le core 0.

De plus, la mesure aurait un sens si il se lançait tous en même temps au même moment.

[Malawi]

Ton compilo arriver à interpréter ça en constant compile-time pour ne pas faire un VLA qui sont interdits en C++ ?

Pas de pb de compilo non. Le nombre de thread est fixé donc ca le gère à la compil. Enfin je vais faire des tests dans ce sens au cas où.

C'est normal que cela soit toujours plus lent.
Tu fais 8 fois le même travail en mutli-thread mais sans donner d'affinité entre tes threads et tes cores logiques.
Donc tes 8 threads peuvent très bien tourner uniquement sur le core 0 et dans ce cas, tu compares ta fonction faite 1 fois sur le core 0, contre la même faite 8 fois sur le core 0.

De plus, la mesure aurait un sens si il se lançait tous en même temps au même moment.

Ok, mais je ne comprend pas ta notion d'affinité: la distribution des threads n'est pas gérée par le C++ justement? Qu'il arrive que 2 threads passent sur le même core si la machine est chargée, je comprend....mais pas systématiquement, non ?
De plus selon les compil que je fais (sans modifier le code), j'ai des fois le même temps (à quelques % près) entre la version monothread et la version multithread... et ce principe est répétable : soit j'ai TOUJOURS un fort ralentissement, soit je ne l'ai jamais....
Je ne comprend pas ce qui change.
Si tu as le lien vers une doc, je suis preneur...

[jo_link_noir]

Pas de pb de compilo non. Le nombre de thread est fixé donc ca le gère à la compil. Enfin je vais faire des tests dans ce sens au cas où.

Ton nombre de thread n'est pas une constante de compilation puisque ton type n'est pas indiqué comme tel. Si ton compilateur l'accepte, c'est simplement parce que tu autorises l'utilisation d'extension comme les VLA qui n'existe pas dans la norme C++. En supposant que tu utilises gcc (puisque msvc refuse et clang donne un warning) ajouter un -pedantic ou -pedantic-errors au moment de la compilation donnera une erreur ou un avertissement.

Ok, mais je ne comprend pas ta notion d'affinité: la distribution des threads n'est pas gérée par le C++ justement? Qu'il arrive que 2 threads passent sur le même core si la machine est chargée, je comprend....mais pas systématiquement, non ?

Ce n'est pas le langage qui gère cela, mais l'OS. L'implémentation peut ajouter des informations à ce niveau, mais je n'ai pas souvenir d'y avoir vu spécifiquement quelque chose dessus la dernière fois que j'ai regardé les sources. Ce qui serait au passage une assez mauvaise idée puisque le besoin va énormément dépendre du contexte. Du coup, si le développeur veut faire quelque chose à ce niveau, il lui faut taper dans thread::native_handle() qui n'est pas portable.

Chez moi, les temps sont plutôt stables, mais l'écart s’agrandit proportionnellement à la taille nx du vecteur. De plus, passer une certaine taille, chaque thread ajoute un temps significatif au total. Probablement pour une histoire de cache et de switch de context (j'ai 8 cpu):

nx=200000 et num_cores=4:
Test monothread : Elapsed time= 1.96477s
Test multithread : Elapsed time= 2.14332s

nx=200000 et num_cores=8:
Test monothread : Elapsed time= 1.94912s
Test multithread : Elapsed time= 3.87709s

Mais n’oublie pas une chose: ton programme ne confronte pas le temps que met un calcul mono-thread vs un calcul multi-thread, mais un calcul mono-thread vs num_core * calcul en multi-thread, se sera forcément plus lent.

[Astraya]

Ok, mais je ne comprend pas ta notion d'affinité: la distribution des threads n'est pas gérée par le C++ justement? Qu'il arrive que 2 threads passent sur le même core si la machine est chargée, je comprend....mais pas systématiquement, non ?
De plus selon les compil que je fais (sans modifier le code), j'ai des fois le même temps (à quelques % près) entre la version monothread et la version multithread... et ce principe est répétable : soit j'ai TOUJOURS un fort ralentissement, soit je ne l'ai jamais....
Je ne comprend pas ce qui change.
Si tu as le lien vers une doc, je suis preneur...

Les threads sont ordonnancés par le système d'exploitation. L'OS peut très bien dire, je mets tout sur le core 0, je lance un peu le 1er, puis je l'arrête, je lance le second puis je l'arrête et je repart sur le premier.
Tu peux dire à Windows que tu veux que ton thread tourne sur un core spécifique. Mais cela n'est pas possible via la std.
Tu dois utiliser les API systèmes pour ça. Cela se justifie car la std peut tourner sur un OS qui n'offre pas cette possibilité, c'est donc laissé à l'OS.

Mais attention, la procédure n'est pas triviale. Tu peux faire comme beaucoup sur le net en donnant simplement au masque un entier différent, mais ce n'est pas du tout portable et stable.
Pour le faire de façon portable et stable tu dois d'abord récupérer les informations concernant les cores de ton ou tes CPUs.

Exemple pour Windows:
- Récupérer les informations des processeurs dont les masques affecté à chaque cœurs. Voir GetLogicalProcessorInformationEx, et lire récupérer le masque du GROUP_AFFINITY présent dans PROCESSOR_RELATIONSHIP. Une fois ceci récupérer tu aura les informations nécessaires concernant chaque cœur logique. Pour en savoir un peu plus sur la notion de groupe processeur sur Windows c'est ici.
- Faire le lien entre le thread et le masque du cœur que tu veux avec SetThreadAffinity.

La logique est la même pour les autres OS:
Exemple sous Linux tu dois utiliser CPU_SET et pthread_setaffinity_np.

Un article ici pourrait t'aider pour Linux

[Malawi]

Ton nombre de thread n'est pas une constante de compilation puisque ton type n'est pas indiqué comme tel. Si ton compilateur l'accepte, c'est simplement parce que tu autorises l'utilisation d'extension comme les VLA qui n'existe pas dans la norme C++. En supposant que tu utilises gcc (puisque msvc refuse et clang donne un warning) ajouter un -pedantic ou -pedantic-errors au moment de la compilation donnera une erreur ou un avertissement.

gcc oui
j'ai testé avec une constante => j'ai le même comportement

Chez moi, les temps sont plutôt stables, mais l'écart s’agrandit proportionnellement à la taille nx du vecteur. De plus, passer une certaine taille, chaque thread ajoute un temps significatif au total. Probablement pour une histoire de cache et de switch de context (j'ai 8 cpu):

oui exactement, je suis d'accord pour la taille du nx
ce que je ne comprend pas, c'est que je n'arrive pas à reproduire les resultats de facon stable.
- je peux avoir un slowdown de 2 ou de 4 par exemple si je force la recompilation (en sachant que pour un meme binaire j'ai environ toujours le meme slowdown)
- avec le meme binaire sur 2 machines differentes, je peux ou non avoir un slowdown significatif (avec un tableau nx >> taille des caches de cahque machine)
=> ce que j'essaie de faire, c'est de trouver le nombre de thread "optimal" pour executer la version multithreadée le plus rapidement possible, et ce en fonction des datas d'entrée et de la machine
Pour le moment, je n'y arrive pas du tout.

Mais n’oublie pas une chose: ton programme ne confronte pas le temps que met un calcul mono-thread vs un calcul multi-thread, mais un calcul mono-thread vs num_core * calcul en multi-thread, se sera forcément plus lent.

oui ca je le comprend....ce programme est juste un programme de test pour essayer de comprendre comment ca se passe avant d'appliquer le principe à un programme plus complexe
je m'attend donc à un ralentissement, mais normalement assez faible pour un nx pas trop gros et un nombre de threads cohérent

La logique est la même pour les autres OS:
Exemple sous Linux tu dois utiliser CPU_SET et pthread_setaffinity_np.

Un article ici pourrait t'aider pour Linux

J'ai suivi cet exemple, mais je vois très peu de différence en gérant ou non les treads à la main (quelques % de speedup, mais ca ne change pas le slowdown quand j'en ai)


J'ai essayé de voir du coté du cache, mais même là je ne comprend pas:
- programme lancé avec 'perf' sur une machine 72 coeurs vs machine 8 coeurs (caches L1 et L3 identiques), avec 6 threads, et avec ou sans gestion des threads
=> pas de slowdown sur la 1ere et un taux de 'missed cache' d'environ 1%
vs entre 2X et 4X de slowdown sur la 2nde machine (son cache L2 est plus petit, donc ca peut le justifier) mais un taux de 'missed cache' proche de 0 => ???
Donc le slowdown ne vient pas du tout du cache ?
... ni de la gestion des threads au vu de mes tests...donc de quoi peut il venir ?

[LittleWhite]

Bonjour,

Si j'ai bien compris, dans les derniers tests, il y a des prints dans la fonction multithreadé ? Si tel est le cas, il faut savoir que le print risque d’entraîner des synchronisation entre les threads.
Aussi, je ne suis pas surpris que l'affinité n'ait pas un impact significatif dans un tel test. Pour qu'il en ait un, il faut un calcul (plus) long et qui pourrait être déranger par d'autres tâches du système.
Pour les cache-miss, je crois que perf (ou bien un autre outil sous Linux) peut les rapporter et indiquer leur nombre (perf avec les compteurs matériels, je pense).

Mes pistes seraient alors :

• enlever les print, s'il y en a (ceux qui se trouveraient dans la fonction multithreadé, ceux avant et après le bench n'ont pas d'importance )
• en plus de l'affinité, augmenter la priorité du programme de test. Il y a deux possibilités : le nice et le scheduler ( https://access.redhat.com/solutions/2955601 ). Attention, pour ce dernier, y a moyen de freezer la machine.
• placer le bench dans une boucle (minimum 30 itérations). Afficher le min/max/médian et la moyenne des 30 itérations. Cela donnera des résultats plus certains ;
• faire de même, mais en sortant la création des threads de la boucle.

Ah ! J'ai six mois de retard sur cette discussion

[dragonjoker59]

Je ne vois absolument pas l'intérêt de ce test.
Quand on fait du MT, c'est pour répartir le calcul dans les différents threads, ce que tu ne fais pas : tu fais le même calcul dans chaque thread.