Discussion :

[moktar_bouain]

Bonsoir à tous,

J'ai une question concernant la programmation pthread.
J'ai réalisé une programme qui contient un seul thread dans la fonction main().
J'ai mesuré le temps d'exécution j'ai constaté que ce temps est augmenté de 60 % par rapport au programme original(séquentiel).
Mais c'est pas logique ce résultat ??

Merci.

[djuju]

Salut Moktar,

Si je comprend bien, tu as pris les code qui était exécuté depuis ton main, tu l'as mis dans un thread et c'est tout. Dans ce cas, il est tout à fait logique que ton code s'exécute plus lentement. Il faut être conscient que l'utilisation d'un thread a un cout. Lorsque tu le démarre d'abord. Mais surtout, la machine va régulièrement passer de l'exécution d'un thread a un autre, ce qui implique plusieurs accès mémoire, avec empilement/dépilement sur la stack du contexte de chaque thread et branchement du pointeur ordinal.
Les threads deviennent intéressants lorsque plusieurs opérations peuvent ou doivent se faire en parallèle. Dans ce cas, et notamment dans un contexte multiprocesseurs, tu auras des gains performances.
Par exemple, les algorithmes diviser pour régner s'adaptent très bien aux threads. Les problèmes producer/consumer aussi.
Note que le cout d'exécution de tes threads ne doit pas être supérieur au gain de la parallélisation. Tes problèmes doivent donc avoir une certaine taille.

Un exo simple et rapide pour voir le gain apporté par un thread est de créer un tableau de booléens aléatoire et de compter les "true". D'un coté, tu fais un algo itératif bête et méchant. D'un autre coté tu fais un algo avec autant de threads que ton CPU a de cores.
Compare les performances sur un tableau de 2 millions d'éléments et sur un de seulement 4 éléments. Sur le tableau de 2 millions l'algo threadé devrait gagner et sur celui de 4 il devrait perdre.

A+

[Bktero]

djuju a raison : les threads coûtent car il faut passer d'un thread à l'autre, il y a le coût de démarrage des threads, etc.

Il faut aussi être conscient que mesurer le temps d'un petit programme puis le temps d'un autre petit programme n'est pas évident, surtout si petit signifie "faible temps d'exécution". Il y a plein d'autres programmes sans doute plus prioritaire sur ton PC au même moment, qui te dit que ce n'est pas ton OS qui a laissé ton programme threadé sur le carreau pour donner la main à un autre programme qui en avait plus besoin ? Il ne faut pas se baser sur un temps de mesure mais sur un ensemble de mesures et il faut que le temps d'exécution soit suffisamment long pour que les aléas du scheduling de l'OS soit gommé.

D'un autre coté tu fais un algo avec autant de threads que ton CPU a de cores

En supposant que ton OS gère correctement le multicoeur, ce qui d'après une discussion au boulot l'autre jour serait rarement le cas. Ce qui disait les collègues en substance est que tu gagneras mais pas forcément autant qu'on pourrait le souhaiter / l'espérer...

[matafan]

Ca n'a rien à voir avec le fait que le système a à passer d'un thread à l'autre. Tu n'as qu'un thread, il n'y a donc pas de scheduling en plus.

Par contre, le fait de te linker avec la libpthreads va compiler ton code en mode thread-safe, et de nombreuses fonctions de la librairies standard auront en plus à prendre des locks qu'elles ne prennent pas en mode threadé. La différence de perfs vient de là.

[Bktero]

Si tu crées, un thread cela en fait 2 avec le thread du main(), non ?

Sinon, une application si simple n'est pas franchement impactée par le scheduling, ma phrase se plaçait dans un contexte plus général de multi-threading.

[djuju]

En supposant que ton OS gère correctement le multicoeur, ce qui d'après une discussion au boulot l'autre jour serait rarement le cas. Ce qui disait les collègues en substance est que tu gagneras mais pas forcément autant qu'on pourrait le souhaiter / l'espérer...

Tout à fait. Ce n'est pas parce que tu lance 4 threads sur un quad-core qu'il y en aura 1 par core. Tout d'abord, parce que tu as d'autre process qui tourne sur ta machine, ensuite parce que c'est ton OS qui décide du scheduling de chaque thread pour chaque core. Il y a des mécanismes d'affinité pour affecter un thread à un core précis, il vaut donc mieux le laisser faire.
Anyway, le but ici n'est que de donner un exemple simple de gain de perf avec les threads. Quand on débute avec les threads, je pense qu'il vaut mieux ne pas trop entrer ces détails.

Ca n'a rien à voir avec le fait que le système a à passer d'un thread à l'autre. Tu n'as qu'un thread, il n'y a donc pas de scheduling en plus.

Comme l'a dit Bktero, tu as un main qui lance un thread, puis l'attend, tu as donc 2 threads. Il faudra bien scheduler entre les 2 pour vérifier si la condition d'attente du main (un mutex ou autre objet de synchro) est remplie et donc s'il faut réveiller le main thread.

Par contre, le fait de te linker avec la libpthreads va compiler ton code en mode thread-safe, et de nombreuses fonctions de la librairies standard auront en plus à prendre des locks qu'elles ne prennent pas en mode threadé. La différence de perfs vient de là.

Effectivement, c'est tout à fait possible ça vienne de là. Mais, vu qu'on a pas le code, on fait tous des plans sur la comète depuis le début. Je sais bien que ces mesures ne sont pas précises, mais Moktar à 60% de différence entre ces versions de code. Pour avoir 60%, cela me donne l'impression que le temps d'exécution de son thread est très petit et que donc l'overhead vient de l'utilisation des threads. J'ai l'impression que si c'était la synchro du mode htread-safe qui ralentissait le code, l'overhead serait moins important.
Anyway, que l'overhead vienne du cout des threads, du mode thread-safe ou des 2, tu fais bien de soulever cet aspect, car c'est un point important => Compiler thread-safe a un cout.

[transgohan]

Comme l'a dit Bktero, tu as un main qui lance un thread, puis l'attend, tu as donc 2 threads. Il faudra bien scheduler entre les 2 pour vérifier si la condition d'attente du main (un mutex ou autre objet de synchro) est remplie et donc s'il faut réveiller le main thread.

Non tu n'as pas de scheduling entre le main et le thread tant que le thread ne rend pas la main (pthread_exit) si le thread a été créé en mode attaché (en mode détaché on aura par contre le thread qui s'exécute en parallèle du main qui poursuit son traitement).
Le premier changement de contexte se ferra donc uniquement lors du pthread_exit.
C'est le principe de l'utilisation des signaux dans un OS. Sinon on n'utiliserai pas de signaux mais un simple flag qu'on vérifierai à chaque ordonnancement.

Pour moi ce temps vient de l'aspect thread-safe. Cela rajoute un bon nombre de delta non négligeables sur un bon nombre de fonctions. Et donc ce 60% ne me paraît pas bizarre.

[matafan]

Ah non ça c'est totalement faux par contre. Que le deuxième thread soit créé en mode attaché ou détaché ne change rien au scheduling ; dans tous les cas les deux threads s’exécutent en parallèle. La différence concerne seulement la terminaison du threads.

[Obsidian]

Par contre, le fait de te linker avec la libpthreads va compiler ton code en mode thread-safe, et de nombreuses fonctions de la librairies standard auront en plus à prendre des locks qu'elles ne prennent pas en mode threadé. La différence de perfs vient de là.

C'est vrai mais de là à faire 60 % de différence, il y a quand même une certaine distance à franchir. Donc soit l'ensemble analysé est trop restreint pour que les mesures soient pertinentes (s'il fait une boucle sur trois éléments, c'est assurément le coût de création du thread qui sera de loin le plus élevé :-) ), soit il y a des effets de bord comme des barrières de synchro mal placées et/ou injustifiées.

Donc, sans voir le code, on ne pourra pas tirer de conclusions pertinentes…

[transgohan]

Ah non ça c'est totalement faux par contre. Que le deuxième thread soit créé en mode attaché ou détaché ne change rien au scheduling ; dans tous les cas les deux threads s’exécutent en parallèle. La différence concerne seulement la terminaison du threads.

Si le thread est en mode attaché le main est donc en état d'endormissement.
Il n'est réveillé que sur réception de certains signaux en provenance de son thread lancé ou d'un process extérieur (chose assez rare sauf si vous l'avez explicitement programmé).
On peut donc simplifier en disant que le main ne sera absolument pas ordonnancé (il restera endormi) jusqu'à l'envoi du signal par le thread lors du pthread_exit.

A contrario avec un thread lancé en mode détaché, le main n'est pas endormi et donc poursuit son exécution. On a donc un ordonnancement de cette tâche.

Et si on veut être pointilleux je devrai vous reprocher le fait d'appeler un main un thread car ce n'est absolument pas la même chose suivant l'OS.
Sur certains OS le main sera identifié par l'id de process, tandis que sur d'autres OS il sera aussi identifié par un id de thread. Et on retrouve aussi d'autres OS qui fonctionnent par tâche et non par process/thread à l'ordonnancement.

[moktar_bouain]

Bonsoir à tous,

Merci pour vos réponse.
Je travaille sur le code d'un codeur H.264, il est très long, ce pourquoi je l'ai pas postulé. Ci-joint une figure qui explique le programme séquentiel et parallèle. Donc c'est que j'ai fait ce de créer un thread "Encode_chroma_MB" qui sera traité en parallèle avec la fonction main(), alors j'ai un processus qui est la fonction main() et un thread.
Le problème est que le temps d'exécution augmente avec plus de 60%.
Donc j'ai essayé de faire un teste,calculer seulement le temps d'exécution de thread. J'ai trouvé que le temps augmente même si le corps de thread est vide, c'est dire aucune instructions exécutés dans le thread. C'est bizarre ,non ??
C'est à dire lorsque je mets pthread_create () dans mon programme cela me coute presque 78 ms !!!!!

Merci,
Moktar.

[djuju]

Si le thread est en mode attaché le main est donc en état d'endormissement.
Il n'est réveillé que sur réception de certains signaux en provenance de son thread lancé ou d'un process extérieur (chose assez rare sauf si vous l'avez explicitement programmé).
On peut donc simplifier en disant que le main ne sera absolument pas ordonnancé (il restera endormi) jusqu'à l'envoi du signal par le thread lors du pthread_exit.

A contrario avec un thread lancé en mode détaché, le main n'est pas endormi et donc poursuit son exécution. On a donc un ordonnancement de cette tâche.

Et si on veut être pointilleux je devrai vous reprocher le fait d'appeler un main un thread car ce n'est absolument pas la même chose suivant l'OS.
Sur certains OS le main sera identifié par l'id de process, tandis que sur d'autres OS il sera aussi identifié par un id de thread. Et on retrouve aussi d'autres OS qui fonctionnent par tâche et non par process/thread à l'ordonnancement.

Ca fait un moment que je n'ai plus fait de pthread, mais si mes souvenirs sont bons, il y a le mode dettached et joinable. J’imagine que c'est ce que tu veux dire par mode attaché/détaché. Encore une fois, si mes souvenirs sont bons, la seule différence est qu'en mode joinable, lorsque le thread termine, le contexte du thread n'est pas libéré pour que tu puisse faire ton pthread_join(). Si tu es en mode dettached, le contexte est libéré tout seul, puisqu'il n'y aura pas d'appel à pthread_join().

Par ailleurs, un thread endormi, que ce soit sur un wait, un lock, un join, un sleep ou autre sera quand même schedulé. Lorsqu'un thread "s’endort", il est sortie de sa queue de priorité sur du scheduler pour être mis dans la queue des threads endormis. Régulièrement, le schéduler va parcourir cette queue pour vérifier si certain ne sont pas signalés ou tombés en timeout. Si c'est le cas, le thread est sorti de la queue "dormante" pour être remis dans sa queue de priorité. Donc, même si l'overhead d'une telle attente est foncièrement inférieur qu'une attente active, il y a quand même scheduling.

[Bktero]

Non tu n'as pas de scheduling entre le main et le thread tant que le thread ne rend pas la main (pthread_exit) si le thread a été créé en mode attaché (en mode détaché on aura par contre le thread qui s'exécute en parallèle du main qui poursuit son traitement).
Le premier changement de contexte se ferra donc uniquement lors du pthread_exit.

Je ne suis pas un spécialiste des pthreads en particulier mais en raisonnant d'un point de vue général, il y a quelque chose de faux dans ton raisonnement. Si dans la fonction main(), tu crées un thread, que le main() s'endort puis que le thread s'exécute, il y a une changement de contexte pour entrer dans ce thread. Avec le changement de contexte pour terminer le thread, tu as donc 2 changements de contexte.

Ensuite, pas de changement de contexte ne signifie pas forcément pas de temps utilisé par le scheduler pour voir s'il y a un changement de contexte à faire et ne pas le faire parce que le thread courant est toujours celui à exécuter.

Et tout cela en ne raisonnant que sur les 2 threads du programme comme s'ils étaient seuls.

[moktar_bouain]

Je ne suis pas un spécialiste des pthreads en particulier mais en raisonnant d'un point de vue général, il y a quelque chose de faux dans ton raisonnement. Si dans la fonction main(), tu crées un thread, que le main() s'endort puis que le thread s'exécute, il y a une changement de contexte pour entrer dans ce thread. Avec le changement de contexte pour terminer le thread, tu as donc 2 changements de contexte.

Quand même, 2 changements de contexte ne dépasse pas l'ordre de µs.
Comme je vous dis, la création d'un thread (sans aucune instruction dedans) coute 78 ms !!

[Joker-eph]

La création d'un thread ça implique un appel système et du temps pour créer les structures pour l'OS, c'est pas "gratuit".

[Bktero]

Quand même, 2 changements de contexte ne dépasse pas l'ordre de µs.
Comme je vous dis, la création d'un thread (sans aucune instruction dedans) coute 78 ms !!

Certes, la surcharge parait importante pour juste deux changements de contexte. Je ne répondais qu'à ce que disait transgohan sur le "un seul changement de contexte"

Dans un contexte multi-threadé sur PC, il faut quand même être conscient que des 2 threads ne sont pas tous seuls à se battre pour un coeur de CPU. Tu as d'autres threads, c'est au final assez compliqué de suivre le flow d'exécution. Prenons un cas simple : ton programme et 3 autres threads (T1, T2, T3). Je ne vois pas ce qui empêcherait les 2 scénarios suivants (certes schématiques), d'autres intervenants diront ce qu'ils en pensent :

1. Ton programme possède uniquement un main()
   - T1 s'exécute
   - Ton programme s'exécute et a assez de temps pour terminer son traitement
   - T2 puis T3 s'exécutent
   
2. Ton programme possède un main() (Tm) et un autre thread (Ta)
   - Tm s'exécute et lance Ta
   - T1 s'exécute
   - T2 s'exécute
   - Ta s'exécute et fait tout le traitement
   - T3 s'exécute
   - Tm s'exécute et se termine

Dans ton cas 2, tu n'as pas que le temps de changement entre tes 2 threads mais aussi le temps des éventuels threads qui s'intercalent entre les 2.

Au passage, comment as-tu fait pour arriver à cette valeur ? C'est une moyenne ? C'est une mesure unique ?

[moktar_bouain]

La création d'un thread ça implique un appel système et du temps pour créer les structures pour l'OS, c'est pas "gratuit".

Oui absolument Joker, j'ai dit pas que ce gratuit mais ça reste de l’ordre de µs

Dans ton cas 2, tu n'as pas que le temps de changement entre tes 2 threads mais aussi le temps des éventuels threads qui s'intercalent entre les 2.

J'ai protéger toute la fonction main() par un mutex, pour éviter qu'elle soit interrompu par des autres threads, mais toujours c'est le même résultat.

Au passage, comment as-tu fait pour arriver à cette valeur ? C'est une moyenne ? C'est une mesure unique ?

Oui Bktero, c'est une moyenne.
Merci,
Moktar.

[Bktero]

J'ai protéger toute la fonction main() par un mutex, pour éviter qu'elle soit interrompu par des autres threads, mais toujours c'est le même résultat.

Cela n'empêche pas ton programme d'être préempté par d'autres programmes

[moktar_bouain]

Cela n'empêche pas ton programme d'être préempté par d'autres programmes

T'as une méthode pour faire ça?

[Joker-eph]

Oui absolument Joker, j'ai dit pas que ce gratuit mais ça reste de l’ordre de µs

Tu as parlé de changement de contexte, j'ai mentionné "création de thread".

As-tu un exemple minimal qu'on puisse exécuter pour reproduire les 78ms qui paraissent très longues ?