Discussion :

[transgohan]

Salutatations � toutes et � tous,

je cherchais depuis un moment un souci de performance qu'on decouvrait sur une application qui utilise plusieurs pthreads.
On avait des temps de cr�ation de contexte incompr�hensible.

Je viens d'en trouver la raison mais sans pour autant pouvoir l'expliquer.
Je m'explique...

La cr�ation de 10 000 pthreads depuis un process met 570ms sur ma machine (x86, linux ubuntu 12.04).
Maintenant cr�ons un pthread et lan�ons les 10 000 pthreads � partir de ce thread !
Et c'est l� que cela devient int�ressant... On saute � 3300ms environ de temps de cr�ation !

Quelqu'un aurait-il une piste � explorer pour expliquer ce ph�nom�ne ?

[transgohan]

M�me bench lanc� sur une architecture ARM et une POWERPC pour obtenir des r�sultats allant dans l'autre sens...
Les deux cas lanc� avec un linux non patch� temps r�el (pour rester comparable avec ubuntu).

Du coup mes r�sultats x86 sont fortement remis en question...
Le tout est d'arriver � les expliquer maintenant.
Il y aurait une librarie pthread par architecture on pourrait mettre �a en devant mais l�...

Va falloir que je mette en place des tests sur syst�me RT pour �tre s�r d'avoir des valeurs qui restent fixes.

[Emmanuel Deloget]

M�me bench lanc� sur une architecture ARM et une POWERPC pour obtenir des r�sultats allant dans l'autre sens...
Les deux cas lanc� avec un linux non patch� temps r�el (pour rester comparable avec ubuntu).

Du coup mes r�sultats x86 sont fortement remis en question...
Le tout est d'arriver � les expliquer maintenant.
Il y aurait une librarie pthread par architecture on pourrait mettre �a en devant mais l�...

Va falloir que je mette en place des tests sur syst�me RT pour �tre s�r d'avoir des valeurs qui restent fixes.

Ce n'est pas d�pendant de la librairie, mais de l'appel syst�me sous-jacent, et du travail que doit faire l'OS pour s'y retrouver. Selon la configuration du kernel, du scheduler utilis�, et de plein d'autres param�tres, �a peut �tre long ou moins long.

Si tu veux mieux comprendre ce qui se passe, c'est dans les sources du kernel qu'il faut aller voir, du cot� de kernel/fork.c si ma m�morie est bonne (clone(), qui est l'appel syst�me qui est utilis� pour cr�er un thread, appelle la fonction do_fork() avec les flags qui vont bien pour ne pas cr�er un nouveau processus). Le code est en apparence simple � suivre, mais il y a quelques subtilit�s ici et l�.

Ensuite, si tu veux vraiment comprendre ce qui ralentit la cr�ation des thread, il ne faut surtout pas h�siter � utiliser l'outil perf livr� avec le kernel - il te permettra entre autre de faire un profiling en live du kernel.

[transgohan]

Bon r�sultat de l'affaire... J'ai fini par tout faire tourner sur un OS temps r�el.
Et l� les temps sont �gaux.
Note : cependant que si on d�sactive le swap on fait exploser les r�sultats.

Comme je n'ai que des cibles finales temps r�el je vais pas me casser la t�te sur mon pauvre ubuntu... D'autant plus que c'est pas optimal pour les tests j'en conviens vu que j'ai plein de trucs qui tournent en parall�le.

Mais c'est quand m�me marrant de voir ce genre de r�sultats...
Car c'est pas un r�sultat de charge temporaire, j'ai tourn� le script dans tous les sens et lanc� le bench une petite vingtaine de fois et j'obtiens toujours les m�mes �carts.