Gestion des Threads en fonction des CPUs.

Version imprimable

30/03/2010, 17h41
ToTo13

Gestion des Threads en fonction des CPUs.

Bonjour,

j'ai quelques question concernant le multi-threading et les CPUs. En faisant un recherche, j'ai trouvé cette discussion et c'est presque ce que je voulais savoir.

Avec l'instruction 'Runtime.getRuntime().availableProcessors()', on peut savoir combien de processeurs sont disponibles dans la JVM. Mais :
- est ce que par défaut tous les processeurs de la machine sont affectés à la JVM ?
- si j'ai tous les processeurs, est ce que je peux spécifier que j'en refuse 1 (ou N) ? Par exemple sur un QuadCore (ou plus), je souhaite imposer de toujours laisser un processeur de libre pour des opérations annexes de l'utilisateur. Si cela peut se faire, le gère t-on depuis les arguments de la JVM ou peut on le faire directement dans le code source ?

Question annexe... est ce que la l'instanciation d'un thread est couteuse ?
Par exemple, disons que j'ai N calculs à réaliser en parallèle et que je ne dispose que de deux processeurs. Est ce qu'il y a une GROSSE différence à créer deux threads et à leur affecter à tour de rôle les calculs ou puis simplement dire que je crée N threads avec un calcul par thread ?
Par ce que je fais du traitement d'images et j'ai beaucoup de calculs à réaliser, donc potentiellement beaucoup de threads à ouvrir OU

Merci par avance
30/03/2010, 17h47
Pill_S

Hello,

pour les premières questions je ne sais pas trop... Par contre, ce que je sais, c'est qu'un Thread est une ressource super couteuse (parmis les plus couteuses d'ailleurs). Et aussi, le changement de contexte d'un thread (quand la jvm donne la main à un autre thread) et également très couteux. Donc plus on a de threads, et plus la jvm passe son temps a passer d'un thread à l'autre. Avec 5'000 threads lancés en parallèle, une appli ne fait presque plus rien d'autre que ça ;)

D'ailleurs, il existe des api de "Thread pooling" pour palier à ces problèmes

;)
30/03/2010, 17h54
ToTo13

Merci pour la réponse.

Donc si on a N CPUs à notre disposition, l'idéal serait de créer N threads, puis de les passer en argument aux différentes classes afin d'éviter de les recréer dans chaque classe.
Es t-on d'accord ?

D'ailleurs puisque la JVM perd du temps dans la gestion des threads, il vient alors une autre question : peut on imposer que la JVM ne jongle pas avec les threads ? Je m'explique : peut on imposer à la JVM, qu'une fois qu'elle a attribué un thread à un processeur, qu'elle ne retire pas le processeur tant que le thread fait des calculs ou n'a pas été mis en pause ?

Autre question dans la même suite : les méthodes Start()/Stop()/Pause()/Resume() sont elles coûteuses ?

Citation:

Envoyé par Pill_S

D'ailleurs, il existe des api de "Thread pooling" pour palier à ces problèmes

Pourrais tu m'en dire un peu plus.
30/03/2010, 18h31
Pill_S

Hum le problème avec les threads, c'est qu'on n'est jamais vraiment sûr qu'ils s'exécuteront sur un core particulier. On ne peut guère essayer de forcer quoi que ce soit à ce niveau là. Les OS sont d'ailleurs encore assez mauvais dans le dispatching des threads sur les core (windows de réputation, dans les anciennes versions genre XP, exécuterait d'ailleurs tout les thread d'un process sur un seul core. unix/linux semblent un peu meilleurs, mais c'est pas encore le top).

Pour forcer la jvm à ne pas switcher de thread tout pendant qu'une condition n'est pas remplie, je ne connais rien. On peut par contre, à coups de "wait"/"notify", un peu canaliser l'effort mais ça ne risque pas d'empecher les changements de context (mettre un wait fait que le thread va se réveiller, constater qu'il est encore en attente d'un verrou, puis se rendormir)

Concernant le cout des différentes méthodes, je dirais que c'est pas trop grave dans la mesure où elles sont toutes "deprecated" ou presque, et ne devraient donc jamais être utilisées ;) cf la :faq: http://java.developpez.com/faq/java/...EAD_deprecated

Pour le thread pooling, il y a commons-pooling qui est sans doute la plus connue http://jakarta.apache.org/commons/pool/index.html , sinon une petite recherche m'a trouvé ceci: http://java.sun.com/docs/books/tutor...ncy/pools.html (du thread pooling natif via le package concurrent)

bon courage ;)
30/03/2010, 18h44
professeur shadoko

Citation:

Envoyé par Pill_S

. Et aussi, le changement de contexte d'un thread (quand la jvm donne la main à un autre thread) et également très couteux.

là je suis un peu surpris: c'est un thread pas un processus à l'ancienne mode. qu'entends tu par très couteux?
30/03/2010, 19h46
tchize_

professeur: c'est le context switching, qui nécessite de récupérer tous les registres du processeur, les stocker ailleurs, amener ceux du thread qui reprend la main. En java, a doubler, pour ce qui n'est pas compilé par la hotspot, par le besoin de dupliquer aussi les registres de la jvm ;)

Pour ce qui est de forcer un thread sur un CPU pendant un temps donné, laisse tomber, tu n'y arrivera pas avec les OS sur le marché pour plusieurs raison:

1) monopoliser un cpu ou core, c'est faire du multitache collaboratif, genre à celui qu'un faisait dans windows 3.11, une catastrophe point de vue performance (un process qui déconne, plus rien ne marche)

2) on parle d'un JVM qui tourne sur des processeurs virtuels en java :/

3) les seul OS que je connaisse capable de faire ça, ce sont les OS dédiés au batch processing. Tu dis "j'ai besoin de N processeurs pendant 2 heures" et l'OS te trouve un créneau pour t'exécuter.

Je rejouterais qu'il y a peu de chance que tu y gagne en performances, sauf pour certains besoins très précis (number crushing, etc), mais dans ce cas on choisi des OS dédiés à ça :)

3)
30/03/2010, 20h03
adiGuba
Salut,

Ce n'est pas la création ou l'exécution du thread en lui même qui est couteux, mais les changements de contexte que cela peut impliquer.
Surtout en multi-core où chaque processeur à sa propre mémoire cache qu'il faut mettre à jour...

Maintenant ce coût peut être limité en restreignant le partage des données ;)

Quand à savoir si cela va améliorer les performances c'est très difficile à dire sans plus d'information sur ton code.
- Si tu peux bien séparer tes traitements afin qu'ils soit le plus indépendant possible tu pourra bien sûr gagner en performances.
- Par contre si tu dois partager des ressources entre ces différents threads, il y a des chances que cela implique un coût supplémentaire qui compensera le gain obtenu par le multithreading...
a++
30/03/2010, 20h10
ToTo13

Bonsoir,

merci pour ces réponses...
Alors :
- je fais du traitement d'images.
- le plus courant sera que je vais découper l'image en N block séparés.
- les threads feront exactement la même chose, mais sur des parties différentes.
- donc accès au même tableau qui code l'image, mais pas besoin de synchronized pour l'affectation, car ce sera des blocs totalement différents.

Donc je devrai normalement gagner du temps.
30/03/2010, 20h20
tchize_

d'accord sur le gain, maintenant, si y a N processeur, tu démarre N-1 thread et c'est tout. Tu laissera toujours un proco libre comme ça. Pour le gain de performance, en pratique le mieux est encore de procéder par essais erreurs.
31/03/2010, 10h14
professeur shadoko

Citation:

Envoyé par adiGuba

Maintenant ce coût peut être limité en restreignant le partage des données ;)

c'était la remarque sous-jacente à ma naïve question: vu le modèle mémoire de Java ou bien on se tient totalement à carreau et je ne crois pas que la commutation de thread coute cher (mais je n'ai aucune preuve de ce sentiment -de plus ça dépend de l'OS-) , ou bien on se met en situation de synchronisation avec la mémoire principale et là on en paye le prix.
non?
31/03/2010, 10h21
tchize_

comme java tourne sur plusieurs OS différents, sur des tas d'architectures différentes, le mieux est, si c'es critique, d'avoir un code qui s'adapte en fonction de ce qu'il mesure des performance (quitte à lancer un calcul de 2 minutes avant le "gros" calcul afin de savoir qu'est-ce qui est le plus performant)

Je vais prendre un exemple. Sur une architecture x86 avec un bon gros processeur, pour un lourd calcul en pic, il vaut mieux le faire d'un coup sur un seul Thread. Avec les nouvelles techno d'intel (désactivation automatique des cores non utilisée et overcloking des cores utilisé), c'est d'autant plus vrai.
A coté de ca, la même application tournant sur HP-UX avec du PA-RISC comme processeur, il vaut mieux avoir 50 thread en parallèle qui gèrent le travail, ces processeur étant très bon en gestion du parallélisme, mais une catastrophe en travail de pointe. Il vaut donc mieux éviter d'avoir un pic et répartir la charge sur un gros paquet de Threads!
31/03/2010, 11h46
Rei Ichido

D'un autre côté, quand on en arrive à devoir optimiser sur des traitements lourds en fonction de la machine, c'est a priori qu'on a pas choisi le bon langage ...
31/03/2010, 12h21
tchize_

Citation:

Envoyé par Rei Ichido

D'un autre côté, quand on en arrive à devoir optimiser sur des traitements lourds en fonction de la machine, c'est a priori qu'on a pas choisi le bon langage ...

Quelque soit le language, les traitements lours, et je parle par expérience, s'optimisent en fonction de la machine. Je travail en météo et on a carrément des consultant qui viennent nous expliquer comment coder pour leur architecture en fonction de la manière dont travaillent les pipeline sur ce processeur, pourquoi une boucle doit etre post incrémenté plutot que préincrémentée dans un calcul critique, pourquoi il vaut mieux faire un appel de methode à certain endroit plutot que faire du inline :mrgreen:. Et c'est du C, pasdu java dont on parle là :)

De manière plsu général, tu fais pas un calcul multithread avec synchronisation des donnée sur une machine monocore, de la même manire tu travaillera plus vite sur une machine multicore sit t'as splitté ton programme en plusieurs morceaux. Et le nombre de Thread optimal, quel que soit le language choisi, dépendra de la machine.
31/03/2010, 13h16
ToTo13

Citation:

Envoyé par Rei Ichido

quand on en arrive à devoir optimiser sur des traitements lourds en fonction de la machine, c'est a priori qu'on a pas choisi le bon langage ...

Euh... NON.
31/03/2010, 13h21
unknow0

Citation:

Envoyé par Rei Ichido

D'un autre côté, quand on en arrive à devoir optimiser sur des traitements lourds en fonction de la machine, c'est a priori qu'on a pas choisi le bon langage ...

c'est qu'a priori les traitement son vraiment lourd*

hihihi

Quelques résultats...

Bonjour tous le monde,

alors j'ai effectué des tests de multithreading sur du traitement d'images. Pour ce qui connaisse, j'ai testé sur des dilatations (morphologie mathématique), pour les autres imaginez une convolution.

Voilà une petite ébauche de ce que j'ai utilisé :
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 public Image Dilatation(Image ImageATraiter) { ... Thread T1 = new Thread() { public void run() { //Traitement de la moitié de l'image... } } Thread T2 = new Thread() { public void run() { //Traitement de l'autre moitié de l'image... } } T1.join() ; T2.join() ; ... return ImageResultat ; }
J'ai donc utilisé ce type de fonction pour découper le traitement dans deux threads différents de mon image.

Alors voilà les résultats :
- sur des petites image (< 512x512) cela ne sert pas de multithreader. Plus l'image est petite, moins cela sert. Sur des toutes petites images (128x128), cela me prenait deux à trois fois plus de temps de multithreader.
- Sur des images (512x512) on tend vers des résultats comparables.
- en revanche sur des images plus grande, on commence à gagner. Sur mon DualCore, on va donc deux fois plus vite.

Voilà pour les quelques tests réalisés.
Qu'en pensez vous ?

31/03/2010, 17h49
tchize_

cohérent avec la pratique :)

T'as plus qu'à trouver une petite règle sur le moment ou tu multithread et comment en fonction du nombre de CPUs :)

a noter que pour "des petites images", je suppose que le traitement est rapide et que tu fait pleins de traitements pour avoir une mesure fiable. Dans ce dernier cas, une option de multithreading, si tu dois travailler en batch, pour les petites images, c'est que deux threads traitent chacun leur propre image :D -> deux fichiers traités à la fois :mrgreen:
31/03/2010, 17h53
ToTo13

Mmm... merci pour le conseil... mais je vais être plus bourin que ça :aie:
Je pense que je vais passer un argument 'int nbCPU' et qu'en fonction je fais du multithread ou non.
Cela va me faire dupliquer du code, mais au moins je peux gérer les deux cas dans la même fonction/classe.
01/04/2010, 12h46
ToTo13

Re...

Petites questions supplémentaires :
- que se passe t-il exactement si on appelle la méthode MonThread.run au lieu de faire MonThread.Start() ?
Est ce que la JVM agit de la même façon ?
Ca semblerait bizarre, sinon la méthode Start ne servirait plus à rien...

- Peut on lancer plusieurs fois un même thread ? Tout simplement faire plusieurs fois MonThread.Start() ?
01/04/2010, 13h06
Pill_S

Hello,

Citation:

Envoyé par ToTo13

- que se passe t-il exactement si on appelle la méthode MonThread.run au lieu de faire MonThread.Start() ?

et bien dans ce cas là, le code s'exécute dans le thread courant au lieu de lancer un nouveau thread.

Citation:

Envoyé par ToTo13

- Peut on lancer plusieurs fois un même thread ? Tout simplement faire plusieurs fois MonThread.Start() ?

non, ça ça ne marche pas. une fois terminé (sortie de la méthode run), le thread est irrémédiablement mort - il faut donc plutôt implémenter des notions de tasking si on veut recycler les thread --> mettre une file d'attente de tâches dans le thread, qui si elle est vide, se mettra simplement en sommeil jusqu'à ce qu'il y ait quelque chose dans la file

;)
01/04/2010, 14h14
ToTo13

Citation:

Envoyé par Pill_S

et bien dans ce cas là, le code s'exécute dans le thread courant au lieu de lancer un nouveau thread.

Donc c'est comme si l'on avait pas fait de Thread ?
01/04/2010, 14h24
Pill_S

Exactement

;)
01/04/2010, 14h28
ToTo13

Citation:

Envoyé par Pill_S

Exactement

Parfait, c'est ce que je voulais :ccool:
Comme ça tous les calculs pour lesquels multi-threader fait perdre du temps (à cause de la complexité de construction des threads) peuvent être appelés de la même façon.

Je fais des tests et je marque les résultats.

Merci
01/04/2010, 14h39
tchize_

oui, tu ne fais qu'appeler une méthode en appelant run. start(), par contre, est une méthode native qui va créer un nouveau thread et ce nouveau thread exécutera la méthode run() ;)

Bonjour,

suite et fin de mon choix d'architecture avec les Threads.
J'ai finalement opté pour l'architecture suivante qui est aussi rapide que ce que j'avais marqué en première page, mais qui évite la redondance de code :

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
class Dilatation
{
...
public Image Execution(ImageATraiter, ImageResultat, int nbCPU)
	{
	...
	switch ( nbCPU )
		{
		case 1 : DilatationThread DT = new DilatationThread(ImageATraiter, ImageResultat, Toute l image) ;
			DT.run() ;
			DT = null ;
			break ;
		case 2 : DilatationThread DT1 = new DilatationThread(ImageATraiter, ImageResultat, Moitié inférieure de l image) ;
			DT1.Start() ;
			DilatationThread DT2 = new DilatationThread(ImageATraiter, ImageResultat, Moitié supérieure de l image) ;
			DT2.Start() ;
			try	{
				DT1.join() ;
				DT2.join() ;
				}
			catch (...) {...}
			DT1 = null ;
			DT2 = null ;
			break ;
		default : // Non géré...
		}
	...
	}
 
 
 
private DilatationThread extends Thread
{
...
public DilatationThread(ImageATraiter, ImageResultat, Bornes)
	{
	this....
	}
 
public void run()
	{
	// Mon traitement d'image en fonction des bornes.
	}
}
 
}

Ben ça marche super bien et c'est pratique à utiliser.

01/04/2010, 16h13
tchize_

les assignation de null sont inutiles ;)
01/04/2010, 16h15
ToTo13

Je pensais que ça aidait un peu le ramasse-miettes :aie:
01/04/2010, 16h25
Pill_S

Citation:

Envoyé par ToTo13

Je pensais que ça aidait un peu le ramasse-miettes :aie:

en effet ça peut, mais en l'occurence ce sont des variables internes, et dès qu'on sort du bloc dans lequel elles sont utilisées, les références sont perdues et le GC fera son boulot

ça aide surtout lorsque ce sont des champs de classe. c'est presque jamais utile pour des variables locales

;)
01/04/2010, 16h32
ToTo13

Ok merci...
Bon on dira alors que : c'est une bonne habitude qui ne coûte rien et peut aider :D
01/04/2010, 20h26
tchize_

en fait si, ca coute: une affectation :D

Fuseau horaire GMT +2. Il est actuellement 08h59.