Discussion :

[Rafy]

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.

[loufoque]

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.

[Rafy]

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.
De plus que l'on voit bien que le multicoeur n'apporte rien...
Ca doit venir d'autres choses.... Merci quand même.

[epsilon68]

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+

[Rafy]

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.

[Matthieu Brucher]

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

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 ?

[Jean-Marc.Bourguet]

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

[Rafy]

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

[Rafy]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Aurelien.Regat-Barrel]

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.

[Rafy]

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

[epsilon68]

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+

[Aurelien.Regat-Barrel]

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

[Rafy]

Ok vu pour les 10ms, je vais donc mettre plus

[Rafy]

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 ?

[Ti-R]

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.

[Rafy]

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.

[epsilon68]

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

[Rafy]

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

[David Fleury]

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.