Discussion :

[ToTo13]

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

[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

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

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

Pourrais tu m'en dire un peu plus.

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

[professeur shadoko]

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

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

[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++

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

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

[professeur shadoko]

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?

[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!

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

[tchize_]

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

[ToTo13]

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.

[unknow0]

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

[ToTo13]

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 java :

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

[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 -> deux fichiers traités à la fois

[ToTo13]

Mmm... merci pour le conseil... mais je vais être plus bourin que ça
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.

[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() ?

[Pill_S]

Hello,

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

- 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