Discussion :

[Jester]

Bonjour,

J'ai actuellement un algorithme génétique qui en lance un thread par individu (en clair une opération de quelques minutes). En parallèle il utilise 20 threads, puis il attend la fin des threads, puis il en relance 20, ...

J'ai à ma disposition un cluster de bi-processeurs. Pour l'instant les 20 threads tournent sur un ordinateur et le facteur de parallélisation est donc de 2. J'aimerai pouvoir envoyer des threads sur d'autres machines du clusters et donc savoir s'il existe des API qui font ça.

Je me dit qu'il suffirait juste de sérialiser les Threads puis les rouvrir sur une autre machine, l'exécuter le sérialiser le renvoyer à la machine maitre et le désérialiser. Le coût du transfert n'est pas un problème dans mon cas, tout compris chaque thread a besoin de moins de 10Mo de données. Je n'ai pas forcément besoin de reprise sur erreur ou de choses complexes, je cherche plutôt un truc simple.

J'imagine bien sur que ce n'est pas aussi simple à faire, mais j'espère qu'une telle API existe me permettant littéralement de lui donner un thread et qu'elle l'envoie ailleurs.

Si jamais vous la connaissez ou avez des API qui ressemblent, n'hésitez pas à poster.

Merci d'avoir lu et de votre réponse.

[fabszn]

Hello,

Idée 1
Tu pourrais peut être voir du coté du RMI..
Tu pourrais invoquer à distance (depuis un serveur central) des traitements reparti sur toutes tes machines.

Idée 2
Aussi tu pourrais installer sur chaque machine un petit prog en Java qui écoute et réceptionne tes données pour les traiter et renvoyer le resultat...

Ca doit être interessant à mettre en place!

je serai interessé par la solution que tu envisageras, même si ce n'est pas une évoquée ci dessus!

[®om]

Ca n'est pas les threads qu'il faudrait sérialiser (les Threads n'étant pas sérialisables).

Sinon, une question, pourquoi 20 threads sur ta machine, et non 1 seul (c'est juste pour savoir si c'est volontaire, ou si c'est bien parce qu'il faut 20 threads)?

Car lancer trop de threads ralenti la vitesse globale (par processeur)...

[Jester]

Ok je ne savais pas qu'un Thread n'étais pas sérialisable, il suffit alors d'hériter de Runnable (me semble pas sur du nom).

En fait les 20 threads c'est par facilité de code (1 par individus). Mais aussi parce que sur le cluster, l'unité de base pour l'allocation des ressources et le thread. Donc avec 20 threads quand les autres en font 2, j'ai 95% de la puissance , ce n'est pas éthiquement grave, je suis sensé être prioritaire sur ce noeud.

fabszn: je ne dis pas que c'est forcément dur, juste que j'aimerai une API toute faite que de l'écrire et de perdre 2 jours.

[®om]

Ok je ne savais pas qu'un Thread n'étais pas sérialisable, il suffit alors d'hériter de Runnable (me semble pas sur du nom).

Je ne sais pas dans quel but, mais les "actions" (le corps des méthodes) n'est pas sérialisé, c'est juste l'état qui est sérialisé, le corps des méthodes (plus généralement la classe) doit être présente sur la machine qui désérialise.

En fait les 20 threads c'est par facilité de code (1 par individus). Mais aussi parce que sur le cluster, l'unité de base pour l'allocation des ressources et le thread. Donc avec 20 threads quand les autres en font 2, j'ai 95% de la puissance , ce n'est pas éthiquement grave, je suis sensé être prioritaire sur ce noeud.

Il n'est pas dit que parce que tu lances plus de threads tu aies plus de processeur...

L'ordonnanceur du processeur essaye de distribuer les ressources entre chaque processus LOURD, et si un processus lourd possède des threads (processus LEGER), ils sont gérés entre eux... Et il y a aussi des priorités sur les processus...[/QUOTE]
Bref, il vaut mieux éviter, pour les performances, de lancer plein de threads lorsque c'est inutile (le but des threads/processus, c'est de donner l'illusion d'être en multiprocesseur en partageant un seul processeur, c'est pas pour les perfs).

[Jester]

En fait sur cette machine si, c'est une ubuntu 64bits, je ne sais pas si le noyau a été recompilé ou pas et donc si c'est l'ordonnanceur par défaut de Linux. En tout cas sur ce linux c'est ainsi.

D'autant que si le noyau est bien fait, le quantum de temps entre chaque context switch a du être augmenté vu que c'est un serveur. mais effectivement dans un monde parfait je ne devrait faire que 2 threads actifs.

Pour la parallélisation, j'avais un peu oublié qu'il faut aussi que le code soit sur le serveur, mais ce n'est pas une contrainte trop forte dans mon cas.

[bouye]

Peut-etre pas directement la reponse appropriee mais il existe des logiciel/API/framework qui peuvent s'occuper de la distribution de taches sur des machines libres/non-occupee du reseau. Nottament Condor que l'on utilise ici depuis peu en univers Vanilla (c'est a dire sans linker nos programmes C/C++ avec Condor) et ca marche bien. Il existe egalement un mode Java dans Condor (non-teste pour le moment et donc j'ignore si on peut linker ses progs Java avec - le fait le linker avec Condor permet la creation de points de sauvegarde et leur transfert sur d'autres machines lors que celle ou le prog tourne est a nouveau utilisee. Tandis que dans l'univers Vanilla, celon la configuration, l'execution est juste stoppee et le programme reste en memoire jusqu'a ce que la machine soit a nouveau disponible ou alors il est vide de la memoire et reprend a zero sur une autre machine).

Tout ca pour dire qu'on peut utiliser Condor pour dispatcher des clients d'executions sur les machines libres du reseau qui peuvent ensuite contacter le serveur Java et recuperer les donnees/threads a lancer localement, etc...

[Jester]

Merci je regarderais si j'ai le temps.

[alexismp]

http://www.terracotta.org/ ?
OpenSource depuis hier...