Thread plutôt lent

[Samuel Proulx]

Bonjour à tous et à toutes

J'ai fait un petit code simple qui démarre un thread et je mesure le temps avec un sf::Clock en attendant thread.wait();

Comment se fait-il que pour la même charge de travail (ex. une boucle qui tourne 100 millions de fois et affecte i à une variable) un thread créé prend toujours environ 3 fois plus de temps pour exécuter le même code que le thread "principal" du processus ?

L'intérêt du multithreading est totalement perdu si ces derniers ne s'exécutent pas aussi vite que le processus même... (y a-t-il un problème dans le scheduler de windows face à ça ?)

Merci et bonne journée !

[Samuel Proulx]

Ah voici un truc assez bizarre : si je crée un thread, là ça prend le même temps que si je n'en créais pas. Si j'en crée deux, le temps est triplé et si j'en crée trois, le temps est presque quadruplé.

Est-ce normal ?

[Laurent]

Montre ton code de test, et dis nous quels temps tu obtiens.

[Samuel Proulx]

#include <iostream>
#include <SFML/System.hpp>

using namespace std;
using namespace sf;

int64_t aa = 0;
int64_t bb = 0;
int64_t cc = 0;

int64_t timea = 0;
int64_t timeb = 0;
int64_t timec = 0;

void a()
{
    for (size_t i = 0; i < 100000000; ++i)
        aa = i;
}
void b()
{
    for (size_t i = 0; i < 100000000; ++i)
        bb = i;
}
void c()
{
    for (size_t i = 0; i < 100000000; ++i)
        cc = i;
}

int main()
{
    Thread thread1(a);
    Thread thread2(b);
    Thread thread3(c);

    Clock clock;

    thread1.launch();
    thread2.launch();
    thread3.launch();

    thread1.wait();
    timea = clock.getElapsedTime().asMicroseconds();
    thread2.wait();
    timeb = clock.getElapsedTime().asMicroseconds();
    thread3.wait();
    timec = clock.getElapsedTime().asMicroseconds();

    cout << timea << "\n" << timeb << "\n" << timec << endl;
    return 0;
}
 

Les trois tournent autour de 1.3 millions

int main()
{
    Thread thread1(a);
    Thread thread2(b);
    Thread thread3(c);

    Clock clock;

    for (size_t i = 0; i < 100000000; ++i)
        aa = i;

    cout << clock.getElapsedTime().asMicroseconds() << endl;
    return 0;
}
 

~210 000

Par contre, si tu essaies le premier code en faisant juste un thread1.lauch() et thread1.wait(), là ça arrive à peu près au même temps... (~220 000)

[Samuel Proulx]

Les rapport de temps mentionné était sur des multiplications matricielles, là on constate que sur une simple affectation de variable, c'est terriblement lent (1.3 millions vs. 210 000)

De plus, si je fais le travaille des 3 threads dans le principal, (une boucle de 300 000 000 donc) ça donne 628 000... soit deux fois moins long dans un thread...

[Laurent]

C'est un peu normal non ? Tu compares un truc à ce même truc + des milliards de changements de contexte (du fait des threads). La seconde option sera forcément moins performante. Quand le processeur change de thread courant, ça prend du temps. Un temps négligeable dans une application "normale" des threads, mais qui prend des proportions démesurées dans ce genre de test.

[Samuel Proulx]

ah ok, donc si je comprends bien, l'OS, après avoir fait juste un tour de boucle (donc une opération minable), il en profite pour changer de contexte et c'est là que ça marche pas...


J'ai refait un test en appliquant plus d'opérations et ça a beaucoup plus de sens : 117 000 en multithreading face à 93 000 sans thread.

Mais petite question comme ça, pourrais-tu m'expliquer pourquoi le fait de créer un thread engendre un changement de contexte dans les boucles ?

Je crois que c'est un truc direct dans l'OS, mais... l'OS doit bien ce rendre compte que la boucle est très court et qu'il pourrait l'exécuter plusieurs fois pour atteindre X microsecondes et ensuite effectuer un changement de contexte non ?

[Laurent]

Je n'ai pas dit que c'était à chaque tour de boucle

Si tu veux un peu de doc cherche les mots-clé suivants : "scheduler", "round-robin"