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!