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.

[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…

[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.

[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.