Version imprimable
Salut,
mon appli java commence a ramer pas mal (traitement d'image), pour accélérer les traitements, je pensais lancer des calculs en parallèle dans des thread mais il me semble que les threads d'une appli java tournent tous sur le même processeur (peut-être les coeurs d'un même proc sont-ils sollicités par une même appli java mais j'en suis pas sur).
Pouvez-vous m'éclairer sur ce point et éventuellement m'indiquer un moyen de faire tourner des thread java sur plusieurs proc (comme mpi)
Merci
c'est géré par le systéme d'exploitation , c'est presque impossible avec le Java Qualifié langage HAUT NIVEAUCitation:
Envoyé par cdtkoenig
T'es sûr de toi ?
Moi j'utiliserai tout simplement les Thread...
Il me semble (je crois) je java n'est pas limité à 1 seul coeur physique (ça serait stupide).
Pour preuve : quand je fais une application Swing assez violente, je peut avoir 100% de mon dual core occupé.
Donc le travail "de fond" et "l'affichage" sont dans 2 threads distincts, et java gère bien la répartition de charge ...
Coté multi coeur, je vois aussi une montée en charge des 2 coeurs en parallèle. Pour le cote muti proc, il faut surement utiliser un framework adhoc (des conseils car il y en a quelques un : Pervasive DataRush, JPPF).
Des conseils ou retour d'expérience ?
merci
Tu as un difference de comportement entre un dual core et un bi processeur avec le meme programme qui lance 2 thread ? C'est ca que tu dis ?
Il me semblait que cela ne devait rien changer...
Je dis que la charge semble se répartir sur l'ensemble des coeurs du proc qui supporte le prog java. Si il y a plusieurs processeur, les autres proc ne font rien.
Je sais que les applications monothread peuvent "répartir" la charge.
Dans le cas d'un dual core :
- soit on utilise 100% de 1 coeur
- soit on utilise 50% de 2 coeurs (on alterne très rapidement)
Mais on reste mono thread !
Dans le cas d'une application multithread, c'est l'OS qui se charge de la répartition !
Je vois pas trop ce que l'on peut y changer :/
Si tu as 7 threads qui tournent à fond sur une dual core, c'est l'OS qui va distribuer tout ça.
Normalement, que les coeurs soient sur le même cpu, ou sur plusieurs cpu, je crois que ça ne change rien.
Personnellement, dans le multithread, j'ai toujours tout fait "à la main".
Mais je ne suis pas un "pro", et je ne peux donc pas te parler des frameworks :)
C'est ce qu'il me semble aussi, tout se repartira tant que le code est "multithreadé" mais je n'ai pas de systeme multiprocesseur dans le coin pour tester s'il y'a un différence avec mon petit dual core ^^.Citation:
Envoyé par PierreD87
D'après vos réponse, il semble acquis que les threads se répartissent tout seuls (OS) sur les différents coeur. Mais quid sur une machine multi-processeurs : si je fais tout plein de treads dans mon appli java, ces dernières vont-elle pouvoir aller s'exécuter sur plusieurs processeur ? En d'autres mots, vais-je voir des process java apparaitre sur les autres processeur ? Telle est la question ?
Justement, c'est ce qu'on dit : normalement oui, ça doit marcher.
Tout dépend de l'OS dans ce cas.
Normalement, tu n'aura que 1 seul processus "java", contenant n threads.
Attention, 1 seul thread ne peut pas exploiter plus de 1 coeur ! (logique et normal quoi)
Je pense (a tester sur un vrai systeme multiprocesseur).Citation:
Envoyé par cdtkoenig
'vais-je voir des process java apparaitre sur les autres processeur' -> tu as lancé 1 "programme java" qui execute differentes thread.
Tu ne verras donc qu'un processus java (dans ta liste des processus) mais qui pourra etre reparti sur different processeurs/coeurs.
Qu'on me corrige si je me trompe.
EDIT : En effet je n'avias pas encore vu ta réponse ;)
j'ai répondu avant :p
Le test le plus simple auquel je pense :
1 thread qui multiplie des nombres aléatoires indéfiniment.
ça doit prendre pas mal de processeur :]
Si tu en lances autant que tu as de coeurs, tu dois normalement atteindre le 100% de charge globale.
Avis à celui qui a une machine multi cpu sous la main...
J'ai finalement testé mon appli sur un bipro sous ubuntu. j'ai installé gkrellm pour visualiser l'activité des proc. J'ai lancé mon appli avec un jeu de donnée qui tourne avec 3 threads et là ........ les 2 proc se sont excités à 100% !!!
C'est cool, je vais pouvoir faire acheter des monstres WorkStations pour mes utilisateur !!
merci à tous pour vos contributions
Attention, c'est pas parceque tu fait tourner des thread et que tes CPU tourne à 100% qu'il te faut acheter des machines plus puissante. Je te conseillerai de revoir tes algo car certaine pratique sont excessivement gourmande, comme par exemple faire tourner un thread à "vide".Citation:
Envoyé par cdtkoenig
Pour exemple:
J'ai conçu un server de socket TCP, j'ai un thread qui vérifie la présence de données dans une fifo et les traites. Hors 99,99%, la fifo est vide et pourtant le thread consommer pas moins de 50% de la CPU. J'avais un autre thread au fonctionnement "similaire" pour au final faire tourner ma CPU à 100%. 8O
En faisant un sleep sur ces thread, je suis passer sur un usage de la CPU <1% sans alterer le fonctionnement... en fait ca marche même beaucoup mieux. :D
Alors avant de partir sur des machines avec plein de proccesseur... vérifie qd même largement ton code car une petite chose anodine pour te flinguer tes perfomances :ccool:
Le "wait" et "notify(All)" c'est un peu la base des programmation en Thread :p
Ne pas oublier de "synchronized" dans ces cas là
En fait mes threads n'attendent pas d'evt, lorsqu'ils sont lancés ils calculent ce que je leur donne et puis meurent, donc je pense que le 100% (pendant le calcul seulement) de cpu est pour de vrai, enfin je crois car j'avoue que je débute dans le multi-threadingCitation:
Envoyé par Torg666
Je ne sais pas si tu peux appliquer ça dans ton cas, mais je connais un "modèle" assez pratique dans le cas du multi thread
Il faut :
- une classe / interface qui DEFINIT un travail à faire (elle doit avoir une methode "execute" par exemple), elle ne contient que des arguments
- une fifo qui va contenir des éléments de la classe ci dessus
- quelque chose qui va alimenter la fifo
- des threads PERSISTANTS qui viennent récupérer les éléments de la fifo, mais qui N'IMPLEMENTENT PAS LE TRAVAIL à faire
Si tu veux plus de précisions... je suis dispo
Quel est l'avantage de ton modèle par rapport au lancement "sauvage" de threads à l'endroit du code ou résident les tâches gourmandes ?
ça evite de créer des threads dans tout les sens.
Tu as des rôles bien distincts aussi : fournisseur de travail, exécutant
ça évite aussi de mélanger l'implémentation du "travail" avec la partie "thread"
bref, meilleure organisation d'après moi
D'un point de vue performance, c'est aussi beaucoup plus facile de contrôler le nombre de threads concurrents : tu as un nombre maximum de threads défini, et tu peux en ajouter/supprimer à la volée.
Quoi qu'il en soit, c'est plutôt orienté "traitement continu", mais ça peut aussi s'appliquer sur un "ponctuel"
Ton modèle m'intéresse bien pas pour tout de suite mais dans une version plus aboutie de mon appli. Peux-tu nous donner des références ou un exemple de code ?
Merci à toi
non désolé, je viens de l'inventer à l'instant
en fait, j'y pensais depuis pas mal de temps, mais je n'ai pas encore eu l'occasion de l'implémenter
Salut,
En standard il y a les executors : http://javasearch.developpez.com/j2s...Executors.html
a++
super !
merci beaucoup !
ça évite de réinventer la roue :p