Questions de perfomance avec boost::thread

**Médinoc** · 03/10/2006, 22h52

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.

**David Fleury** · 03/10/2006, 23h15

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!

**Médinoc** · 03/10/2006, 23h26

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

**David Fleury** · 03/10/2006, 23h36

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.

**Médinoc** · 03/10/2006, 23h44

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.

**loufoque** · 04/10/2006, 00h12

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.

**David Fleury** · 04/10/2006, 00h53

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 :

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

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();
		}
	}
}

**Aurelien.Regat-Barrel** · 04/10/2006, 09h58

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

**Ti-R** · 04/10/2006, 10h36

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

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 :

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

1
2
--------
    t

découpé en 2

Code :

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

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

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

Code :

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

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 :

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

1
2
--------
    t

Découpé en 2

Code :

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

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

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

Code :

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

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

**David Fleury** · 04/10/2006, 16h07

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.

**Médinoc** · 04/10/2006, 17h59

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

**David Fleury** · 04/10/2006, 18h08

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 :

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

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);
}

**Matthieu Brucher** · 04/10/2006, 18h52

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.

**Médinoc** · 04/10/2006, 18h56

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?

**loufoque** · 04/10/2006, 20h02

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.

**David Fleury** · 04/10/2006, 20h20

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

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/

**Rafy** · 05/10/2006, 15h21

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.

Questions de perfomance avec boost::thread

Boost C++

Discussions similaires

Partager

Partager