Questions de perfomance avec boost::thread

Je suis en train de developpez un pojet assez gros, et décide maintenant d'essayer de parallèliser certains traitements indépendants. Pour cela j'ai envie d'utiliser la libraire Thread de boost. J'ai donc procèdé à des petits programmes de test pour me mettre en jambe avec cette librairie.

Durant la vérification des performances de ces programmes, certaines valeurs m'amènent ici. Ces questions portent sur la rapidité d'execution de la librairie boost::thread, et en particuliers sur la création des threads.

Comme mes taches sont indépendantes, alors j'ai decidé de tester les boost::thread_group et d'un autre côté les boost::thread associés aux boost::barrier.

Pour charger le processeur j'ai codé une fonction. c'est simplement une boucle for de 0 à 1e6.

Mon programme de test fonctionne comme un jeu : update -> render -> display. Mon projet se situe uniquement dans l'update.
Le comportement est identique que j'utilise des boost::thread_group ou des boost::thread et boost::barrier.
Test 1 : dans l'update j'apelle 10 fois la fonction de charge d'affilé, multithreading désactivé, c'est 10 appels à la suite les uns des autres.
Test 2 : dans l'update je créé 10 thread qui lancent chacun une fois la fonction de charge, j'ai ainsi la fonction qui tourne en parallèle sur 10 thread, je join avant de continuer l'execution du reste de l'update.

Ce qui m'amène ici, sont les résultats. Je regarde le nombre de FPS, pour évaluer la vitesse de parcours de la boucle de simulation du jeu.
Je pocède un AMD Athlon XP 2600+ (donc mono-coeur), les résultats sont étranges, le programme en ST (SingleThread)[Test 1] tourne 3 fois plus vite que l'autre.
Sur l'ordinateur d'une autre personne Athlon XP 3200+ (je ne suis pas sur, mais on s'en fou), les résultats sont encore plus étrange car le programme ST tourne 5 fois plus vite que le MT.
Et sur un IntelCentino tout neuf, (dualcore) alors la rapidité d'execution est identique avec le programme MT et ST.

Mes questions sont donc les suivantes :
Pourquoi un tel écart entre MT et ST ?
Pourquoi sur le dualcore j'ai pas des meilleurs performances en MT qu'en ST ?
Le temps de création des threads semble grand, existe-il une loi empirique du nombre de thread à créer en parallèles, et ou une charge nominale à faire porter sur chaque thread ?

Merci de vos réponses constructives.

Plus t'as de threads, moins ça va vite, forcément...
Les threads te permettent d'augmenter les performances uniquement quand t'as du matériel à exploiter ou que tu peux faire un algorithme exploitant le parallelisme.

Je suis d'accord avec toi que le MT est plus lent. Mais d'un facteur 5 je trouve ça exagéré pour 10 malheureux threads. :aie:
De plus que l'on voit bien que le multicoeur n'apporte rien...:?
Ca doit venir d'autres choses.... Merci quand même.

mais les resultats se comptent en seconds, en minutes ou en heures ?

en fait les dual core ont une frequence plus basse et iront moins vite pour faire une tache que les processors type pentium 4.

cela veut dire que si tes taches sont longues a faire, tu iras plus vite sur les processors standard.

Maintenant si tu arrives a paralleser une tache pour qu'elle s'execute sur deux cores, tu as des chances d'aller plus vite que les processors normaux, mais bon j'ai des doutes sur les betes de course.

le dual core apporte surtout beaucoup de souplesse dans l'utilisation normale, cela apporte plus de reactivité du systeme.

A quelle vitesse ils vont tes cores ?

a+

j'ai écris que je regardais le nombre de FPS, comme dans un jeu. Donc les chiffres que je marques sont des fps...
Ce que je ne comprends pas, en particuliers, c'est pourquoi le proc multicoeurs n'arrive pas à allez plus vite en MT qu'en ST.
Je ne compare pas entre proc mais chaque proc avec le programme MT et celui en ST.
Sinon pour info le dualcore tourne à 1.66GHz.

Citation:

---

Envoyé par epsilon68

en fait les dual core ont une frequence plus basse et iront moins vite pour faire une tache que les processors type pentium 4.

---

8O
Stop, là !
Les dual core actuels sont largement plus performant que les P4 ! Oui, les pentium dual core sont des P4 sous cadencés, mais les nouveauc, c'est une nouvelle architecture, faut pas se faire bouffer par le marketing que je ne qualifierai pas d'Intel !

Rafy > as-tu mesuré la vitesse après la création des threads ?

Qu'est-ce qu'il y a comme besoin de synchronisation entre thread?

hum je regarde le temps qui s'est écoulé entre deux frames, donc j'ai le temps de création d'une frame, avec un petit calculs je met ça en FPS...
J'affiche toutes des 0.2 secondes sinon on ne peut pas voir le chiffre correctement car il change à chaque frame.
Donc plus il y a des tour de boucle principale, plus il y a de frame de générées, et plus le nombre de FPS est grand ce qui me permet de dire que le PC le plus puissant, fait tourner la boucle principale plus rapidement que es autres.

Enfin ça je pense que je ne l'apprends pas à tout le monde :aie:
Le besoin de synchronisation des threads vient du fait que dans mon projet j'aurai besoin de faire des tâches en parallèle, donc de synchroniser à un moment ? Je voulais donc m'entrainer avec la librairie avant de la coller partout dans mon projet. Comme j'aurai besoin de synchroniser alors j'utilise la syncro. voila.

Pour être précis voici les algo des boucles principales des deux programmes :
Détection Input -> Update -> Render-> Display
Seul le Update n'est pas le même dans les deux programmes.
C'est à dire
MT :
Je créés 10 thread qui lancent la fonction de charge, je syncronise et effectue l'update normal
ST :
Je fais une boucle for qui boucle 10 fois, et lance donc 10 fois d'affilé la fonction de charge puis effectue l'update normal
En code ça donne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

for (std::size_t i = 0; i < 10; ++i) { #ifdef MT boost::thread Thread(&Crash::Charge); #else Crash::Charge(); #endif } #ifdef MT boost::barrier B(10); #endif

---

Il faut trouver où se situe le goulot d'étranglement. Crée un nouveau projet où tu reprends ton noyau MT et où tu remplaces tes 10 fonctions de calcul par des fonctions qui font des sleep de 1 sec par exemple. Si ça met plus de 10.1 sec, il y a effectivement un problème. Sinon, ça vient d'ailleurs.

J'ai fais ce que tu as dis Aurélien :
Alors voici :
MT : 317 fps
ST : 9 fps
avec comme fonction de charge un sleep de 10ms.
J'ai pas fait une seconde sinon ma boucle met trop de temps à tourner et j'ai plus de fps (mais de spf).

Que le ST ailles plus vite sur un SP c'est normal, sinon il y a le contexte des threads a gerer.
Que le MT n'ailles pas plus vite que le ST sur un dual core, c'est vraiment etrange. Je vais faire des tests chez moi a la maison.

je vous tiendrais informé.

a+

10ms c'est le quantum alloué à un thread sur un mono processeur (Windows), 15 ms sur un dual core.
Autrement dit, c'est beaucoup trop court, ton thread se termine avant même d'être pré-empté.

8O Ok vu pour les 10ms, je vais donc mettre plus :aie:

Alors voila, j'ai changé pas mal de trucs :
J'ai ajouté de quoi regarder le temps pris pour l'éxecution des fonctions de charges. Pour cela je déclenche le chrono avant la boucle for que j'ai décrie au dessus. Et arrete le chrono après.
J'utilise les boost::group_thread au lieu des boost::thread avec boost::barrier. De toutes façon j'utiliseai pas correctement la barrier car je n'apellais pas wait.... Ca ne synchronisait rien du tout (j'avais un temps d'éxécution de 0.001 seconde environ)....
Je suis passé aux groupes car c'est surement ce que je vais utiliser dans mon projet.
Je calcul le temp écoulé et l'affiche avec une message box.
Résultats :
ST 10 (varie entre 9.99999 et 10.000002) secondes
MT 1.001 (varie entre 1.0012 et 1.00255) secondes
J'ai mis comme fonction de charge un sleep de 1 seconde et toujours 10 fois exécutée (soit avec 10 thread soit 10 fois d'affilée)
résultats cohérents je pense. non ?

Pour moi le problème est plus d'ordre architectural, un double core peut gérer logiquement 2 threads qui font des calculs intensifs en parallèle, mais au-delà de 2 threads en parallèle c’est inutile et forcément décrois les performances. Un thread n’est pas la pour décupler les performances, mais découper les tâches, c’est sur que si il y a plein de threads, un processeur cell serait bien efficace, mais sur un mono core les performances vont chuter, spécialement si les calculs effectué dans les threads sont petits, car plus c’est petit à calculer plus le temps de création de thread allonge le temps de calcul global donc décroit fortement les performances.

Ce que je mettrai dans les thread sera assez lours je pense. Car il y a pas mal de calculs (matriciel, vecteurs, etc). C'est pour un moteur physique.

les derniers temps que tu as donné, c'est sur un dual core ?
et dans le cas de processor type pentium 4 ?

vraiment interessant comme discussion...

?on tous ces temps c'est sur mon PC (Athlon XP 2600+).
Mais c'est normal, car les threads sont lancés et leur job à tous c'est attendre 1 secondes. C'est ce qu'ils font.

Citation:

---

Ti-R a écrit :
Pour moi le problème est plus d'ordre architectural, un double core peut gérer logiquement 2 threads qui font des calculs intensifs en parallèle, mais au-delà de 2 threads en parallèle c’est inutile et forcément décrois les performances...

---

A ma connaissance, c'est faux (pour un OS multi-tâches).En programme MT lancé sur une machine mono-proc tournera légèrement plus rapidement.
Je ne vais pas trop insister parce que je n'ai pas de Linux sous la main pour faire la démo.

Pour moi, le programme MT sur une machine monoproc serait plutôt du genre à tourner plus lentement, du moins s'il fait des calculs intensifs.

Par contre, si les threads passent le plus clair de leur temps à attendre, (donc que le proc n'est pas utilisé à 100%), là oui le programme multithreadé peut être plus rapide.

Normalement non, le résultat est indépendant de la tâche même du processus.

Je ne suis pas spécialiste de l'ordonnanceur des processus sous Windows, mais le temps disponible pour chaque tâche est indépendant de la tâche elle-même (il y a peut être les niveaux de priorité sous Windows).

Le temps perdu vient plutôt des problèmes internes aux tâches (synchronisation ou concurence d'accès par exemple)

Je crois me souvenir qu'il y avait un article sur ce sujet dans le regretté Login!

Je sais bien que Win32 gère tout au niveau thread et ne partage pas le temps d'un processus entre ses threads, mais ça ne fait aucune différence une fois le processeur utilisé à 100%.

Et donc, sur un monoprocesseur avec le proc utilisé à 100% par un programme multithread, le programme sera plus lent qu'en monothread du fait des problèmes de synchronisation etc...

Pour un programme qui utilise le proc à 100%, le multithread n'est plus rapide que s'il y a plus d'un processeur (ou un processeur avec plus d'un coeur)...

Hum... dommage j'suis pas spécialiste mais je suis toujours pas d'accord.

D'abord, il me semble quasiment impossible d'avoir 100% de CPU pour un seul thread (l'unité de travail de Windows), en général (selon mes souvenirs), les OS (multi-tâches) se gardent prudement un peu de temps CPU pour réagir un cas de problème grave ou faire tourner tout simple les autres tâches liés à l'OS.
il suffit de faire un Winrar sur un gros fichier, le CPU sera à 100% mais tu auras la main sur ton PC.

Il serait simple de faire une mesure de perf sur deux compressions en parallèle sur 2 fichiers volumineux (sur 2 disques différents) et comparer les temps d'un lancement en série et en parallèle.

Ben si, à tous les niveaux de priorité, tu peux avoir 100% CPU sur un seul thread si tu ne fais absolument rien d'autre (comme bouger la souris).

Ensuite, ce qui réagit à la souris a une priorité très haute. Les tâches supposées être lentes ont (quand le programme est bien fait) une priorité réduite (comme WinRAR).

Deux threads de même priorité, s'ils sont en calcul continu, seront servis équitablement par le proc, mais cela réclamera un saut de contexte supplémentaire (mais minime si les deux threads appartiennent au même processus) et surtout, il y aura l'overhead logiciel du au multithreading (mécanismes d'exlusion mutuelle sur variables partagées, allocation dynamique, etc) qui n'est pas mis dans un programme monothreadé pur.

Citation:

---

D'abord, il me semble quasiment impossible d'avoir 100% de CPU pour un seul thread (l'unité de travail de Windows)

---

Ça dépend de ton processeur.
Avec de l'Hyper-Threading et du Multi-Core, c'est difficile.

J'ai essayé de faire un petit essai mais bon j'avais que du C# sous la main.
J'ai fait un programme qui fait des cosinus.
J'ai fait 3 mesures en HT, avec 1 thread, 2 threads et 4 threads
(10 lancements et un temps moyen)

1 thread : 76s
2 threads : 73s
4 threads : 72s

j'obtiens bien un gain alors que je n'ai que 2 CPU virtuels.
voici le code pour ce que ça vaut (mon premier source C# ça se fête ;) .

Code:

---

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

using System; using System.Threading;   namespace ConsoleApplication1 { class Writer { public void WriteMessage() { for ( int i = 0; i < iMax; ++i ) for ( int j = 0; j < 1000000; ++j ) System.Math.Cos( i*j ); } public int iMax; }   class Class1 { [STAThread] static void Main(string[] args) { Writer w = new Writer(); //w.iMax = 100000; //w.iMax = 50000; w.iMax = 25000;   Thread t1 = new Thread( new ThreadStart( w.WriteMessage ) ); t1.Start(); Thread t2 = new Thread( new ThreadStart( w.WriteMessage ) ); t2.Start(); Thread t3 = new Thread( new ThreadStart( w.WriteMessage ) ); t3.Start(); Thread t4 = new Thread( new ThreadStart( w.WriteMessage ) ); t4.Start(); } } }

---

Je suis sceptique. S'il y a plus de threads que de processeur, je vois pas comment ça peut aller plus vite. Les threads ont un coût.
C'est pour ça que Windows propose les fibres, l'unité encore en dessous des threads. C'est des threads dans les threads en quelque sorte.
Même en HT, il s'agit de processeur logique, et y'a des cas où le HT ralentit le process car apparement les 2 processeurs logiques peuvent être moins "puissants" que le processeur physique seul (HT désactivé), s'il s'agit de calculs lourds.
Ainsi, y'a une boite qui a développé un système de build réparti pour Visual Studio qui déconseillait d'activer le HT car ils avaient constaté que c'était plus rapide sans.
Pour .Net, je ne suis pas spécialiste, mais de ce que j'en sais il est libre d'implémenter ses threads comme il veut. Il n'a pas obligation d'utiliser les threads système (même si à priori c'est ce qu'il fait). Faudrait vérifier s'il y a bien 4 threads Win32 de créé.

Citation:

---

Envoyé par Hylvenir

A ma connaissance, c'est faux (pour un OS multi-tâches).En programme MT lancé sur une machine mono-proc tournera légèrement plus rapidement.
Je ne vais pas trop insister parce que je n'ai pas de Linux sous la main pour faire la démo.

---

Déjà tu te contredis partiellement...

Citation:

---

j'obtiens bien un gain alors que je n'ai que 2 CPU virtuels.

---

Donc déjà c'est pas un mono core pur (physique et logique) mais un HT...

Ensuite je vais prendre un exemple.

1 calcul de temps t.

Code:

---

1 2	-------- t

---

découpé en 2

Code:

---

1 2	---- + ---- t1 t2

---

Plus le coup des 2 threads symbolisé par c1 et c2!

Code:

---

1 2 3

---- + ---- + --- + --- t1 t2 c1 c2

---

Ne peut être égale à t sur un mono core pur (physique et logique)...
Ensuite cela montrerai que le processeur HT est à jeter par la fenêtre car il y a un gros problème dans ton expérience...

1 calcul de temps t.

Code:

---

1 2	-------- t

---

Découpé en 2

Code:

---

1 2	---- + ---- t1 t2

---

Plus le coup des 2 threads symbolisé par c1 et c2!

Code:

---

1 2 3

---- + ---- + --- + --- t1 t2 c1 c2

---

Le tout divisé par 2 car pris en charge par 2 processeurs, on devrait arriver et tendre vers (t/2)+c... ce qui est loin d'être le cas.

Il faut explorer la piste mais la technologie HT première génération semble douteuse pour faire des tests :roll:

Citation:

---

Aurélien :
Je suis sceptique.

---

bah fait un test ;) J'ai pris la peine de faire un source, il suffit de le tester.

Mais j'ai aussi entendu que dans certains cas, le HT n'était pas conseillé. Je n'ai pas personnellement essayé de quantifier ces on-dits.

J'en refais un sur un Unix bi-proc en C++ puis en mode MT en C#
(là, je bosse un peu donc pas trop le temps)

Ti-R :
En fait, je crois qu'il faut considérer l'ensemble des traitements lancés par l'OS.
et avoir le thread comme unité de travail.
Si j'ai 9 threads en cours, j'ajoute 1 thread, j'ai (1/10*100) = 10% du temps alloué pour mon process de calcul.
Si au lieur d'un thread, j'ajoute 2 threads, j'ai (2/11*100) = 18% du temps qui me sont alloués par l'ordonnanceur système.
pour 3, j'aurai (3/12*100) = 25%, ...
c'est un peu simplifié peut être mais c'est l'idée à mon sens.
Sur le temps théorique gagné, on perd le temps de création, de bascule entre les contextes, ... d'ou un gain moindre en pratique.

Mais en pratique, c'est pas courant d'avoir déjà 9 threads en cours, surtout au même niveau de priorité...

À moins peut-être de compresser 5 fichiers pendant que tu compiles trois projets en parallèle et que tu fais un scan antivirus sur le neuvième...
(et encore, certains des threads passeront plus de temps à attendre les entrées/sorties qu'à calculer...

Enfin, si tu arrives à réunir ces conditions, oui un programme avec 4 threads actifs (portant le total à 13) aura plus de temps processeur qu'un programme avec 2 threads...


Mais si tu as un seul programme qui fait une opération longue, ses threads seront les seuls actifs et en rajouter n'apportera rien...

Honnêtement, je ne sais pas du tout comment sont gérés les niveaux de priorité Windows XP.
Mais si tout le monde a le même niveau de priorité, il est courant d'avoir beaucoup de thread "en parallèle" (par exemple mon OS fait tourner 48 processus).

Et en mesurant, je constate que ça apporte un peu un tout cas.

J'ai fait le test en C++ sous Unix avec un bi-proc, j'obtiens aussi un gain quand je lance plus de threads que je n'ai de processeurs.
Voici le code utiliser pour faire un test ailleurs pour voir.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <iostream> #include <cmath> #include <pthread.h>   void* Compute(void *tn) { for ( int i = 0; i < 1000000/(int)tn; ++i ) for ( int j = 0; j < 10000; ++j ) std::cos( i * j * 1.0 );   pthread_exit(NULL); return 0; }   int main (int argc, char *argv[]) { pthread_t threads[100]; int tn = std::atoi( argv[1]?argv[1]:"1"); for(int t=0; t< tn ; t++) { pthread_create(&threads[t], NULL, Compute, (void *)tn); } pthread_exit(NULL); }

---

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Je suis sceptique. S'il y a plus de threads que de processeur, je vois pas comment ça peut aller plus vite. Les threads ont un coût.
C'est pour ça que Windows propose les fibres, l'unité encore en dessous des threads. C'est des threads dans les threads en quelque sorte.
Même en HT, il s'agit de processeur logique, et y'a des cas où le HT ralentit le process car apparement les 2 processeurs logiques peuvent être moins "puissants" que le processeur physique seul (HT désactivé), s'il s'agit de calculs lourds.

---

Tout à fait. Si l'application est bien optimisée et que toutes les unités de calcul du processeur sont utilisées avec un seul thread, l'autre n'aura rien, et donc aucun gain. Pire, avec le P4, le système calcule de manière "préemptive" quand il cherche dans le cache, en admettant qu'il n'y ait pas de défaut. S'il y en a un, les instructions dépendantes sont réinjectées dans le pipeline, d'où perte de temps CPU.

Citation:

---

Envoyé par Hylvenir

Honnêtement, je ne sais pas du tout comment sont gérés les niveaux de priorité Windows XP.
Mais si tout le monde a le même niveau de priorité, il est courant d'avoir beaucoup de thread "en parallèle" (par exemple mon OS fait tourner 48 processus).

---

48 processus actifs ?
Ou bien 48 processus qui attendent tous quelque chose?

Si tu as besoin de plus de priorité, tu changes la priorité.
Utiliser plus de threads pour avoir une meilleure priorité, c'est un hack.

Citation:

---

Médinoc :
48 processus actifs ?
Ou bien 48 processus qui attendent tous quelque chose?

---

La plupart ne doivent rien faire j'imagine.
Mais ça m'intrigue toujours d'avoir à lancer des process qui ne font rien.
A ma connaissance, sous *nix, les process même en attente consomme du temps sur l'ordonnanceur même s'ils ne font rien.
Peut être que sous Windows, les processus ne consomme aucun temps sur l'ordonnanceur... ?

Citation:

---

Si tu as besoin de plus de priorité, tu changes la priorité.
Utiliser plus de threads pour avoir une meilleure priorité, c'est un hack.

---

Il n'y a aucun rapport avec le propos.


Indépendement des considérations théologiques, j'ai fourni deux exemples afin que tout le monde puisse au moins mesurer des temps. Je ne peux pas faire beaucoup mieux.

De mon côté, j'ai observé un gain (petit mais un gain) dans le cas d'un traitement découper un plus de thread que ne dispose physiquement la machine (et c'est uniquement le propos), et ce, sur plusieurs configurations différentes.

Je ne pourrais pas vous contredire dans vos théories, puisque, je le répète, je ne suis pas un spécialiste de Windows et de sa stratégie d'ordonnancement.
Je me contente de constater l'effet sur des exemples.

J'ajoute quelques temps obtenu (des ordres de grandeur)
en MT 1thread : 6.9sec et les durées obtenues varient beaucoup
en MT 2threads : pratiquement identique mais les temps varient beacoup moins (pas facile de voir une amélioration mais en moyenne ça se sent)

en HT 1thread : 7.2sec et les durées obtenues varient beaucoup
en HT 2 threads: 6.0sec et quelques variations de durée
en HT 4 threads: 5.9sec et peu de variation autour de cette valeur.

J'ai mis un binaire et une DLL (pour les pthreads en Win32) ici :
http://hylvenir.free.fr/data/

Je voudrai seulement recentrer un peu le sujet car je pense que l'on dérive légèrement.
Tout d'abord je parlais de la librairie boost::thread, pas d'une autre.
Et je parlais des temps d'execution d'un même travail, soit en ST, soit en MT.
l'hyperthreading je m'en fou un peu.
Je veux juste savoir pourquoi quand je file un travail à faire à un proc monocore alors il va plus vite en ST qu'en MT(entre 3 et 5 fois) et qu'un dual core met le même temps en ST et en MT (alors que ça devrait être meilleur en MT).
Merci d'avance.