Discussion :

[Gotch4]

Plop, voilà mon petit problème :

J'écris un programme en distribué ou chaque pc à certain nombre de calculs à effectués selon un intervalle fixé par le serveur, cependant je voudrais fixer cet intervalle selon la puissance de calcul du pc client.
En gros plus le pc est puissant plus le nombre de calculs qu'il devra effectuer sera grand.

J'ai pensé à écrire un bout de code assez costaud ( genre calcul de décimales de pi) pour en récupérer le temps d'exécution mais je me demande si il n'y a pas plus simple.

Les machines sont sous Linux.

Je vous remercie d'avance pour vos réponse

[Jean-Marc.Bourguet]

Pourquoi ne pas répartir plus dynamiquement? Découper ton problème en plus de parties que de machine et en fournir une à chaque machine et une nouvelle à celles qui finissent en premier. D'après mon expérience, ça marche mieux dans des environnements hétérogènes que d'essayer d'affubler chaque machine d'un facteur de performance unique (qui ne peut être qu'une moyenne des quatre facteurs importants -- calcul, mémoire, disque, réseau -- pondérée par une estimation de leur importance). En particulier si les machines ont d'autres taches qui peuvent venir foutre le boxon.

[Gotch4]

Merci pour ta réponse, en fait je vais expliquer un peu sans rentrer dans trop de détails :
Je calcule le meilleur chemin entre deux points séparés par des obstacles.

Un client va se fixer un intervalle ( après réflexion le serveur n'a aucunement besoin de le faire lui), donc par exemple 50,il lance ensuite 50 threads pour noté chaque chemins et renvoi le meilleur au serveur.
Ensuite il mixe un peu les chemins entre eux et repart sur 50 tests.
Comme je dois gardé les meilleurs à chaque fois j'attends que tout les tests soit fini avant de faire un mix global.
Pour schématisé (vraiment vite fais xd) :
50 tests -> Mix des chemins -> 50 tests -> Mix des chemins ->....

Du coup je veux pouvoirs utiliser toutes les ressources disponibles à chaque vagues de threads.

[therwald]

Je ne vois pas pourquoi ça t'empêche de suivre la suggestion de Jean-Marc Bourget.
Tu as l'ensemble initial E1 de n chemin. Tu le découpes en paquet de 50, tu envoies un paquet à chaque PC client. Dès qu'un serveur te renvoie le meilleur des 50, tu insères ce chemin dans l'ensemble E2 des n/50 meilleurs chemins, et tu lui renvoie un paquet de 50 pris dans E1. Tu fais ça jusqu'à avoir vidé E1, puis tu attends (pas sûr que ce soit nécessaire, mais dans un premier temps tu peux essayer comme ça, sans noter à quel stade en est chaque client) que les derniers résultats arrivent dans E2. Ensuite, Tu utilises E2 comme source de paquets, et tu insères les résultats dans E3 qui est l'ensemble des (n/50)/50 meilleurs chemins de E2...et ainsi de suite.
De cette façon, un PC lient rapide reçoit plus de travail puisqu'il redemande plus souvent, et tu respectes bien tes étapes de réduction.
Si tu es trop handicapé par l'attente des derniers résultats, tu peux essayer d'optimiser en notant au niveau du serveur dans quel ensemble (En ou En+1) il faut insérer le résultat renvoyé par chaque client, et ainsi tuiler le début du traitement de En+1 avec la fin du traitement de En (sachant qu'il y aura de la synchro à faire entre la réception des chemins dans En+1 et leur envoi aux clients qui sont "en avance", donc tout dépend si ton calcul est assez lourd pour rendre la contention négligeable...)

[Jean-Marc.Bourguet]

Merci pour ta réponse, en fait je vais expliquer un peu sans rentrer dans trop de détails :
Je calcule le meilleur chemin entre deux points séparés par des obstacles.

Dijsktra, la variante de Dijstra qui part des deux bouts à la fois, A*, si tu as une géométrie sur un graphe de Delaunay/Voronoi (j'oublie toujours lequel est quoi, ce sont des duaux).

Un client va se fixer un intervalle ( après réflexion le serveur n'a aucunement besoin de le faire lui), donc par exemple 50,il lance ensuite 50 threads pour noté chaque chemins et renvoi le meilleur au serveur.

Tu as des machines avec 50 procs? Parce que sur un tel problème a priori avoir plus de threads que de procs n'a pas d'intérêt. Déjà le partitionnement sur plusieurs procs/machine est un problème intéressant dont je ne suis pas sûr qu'il ait une bonne solution (dans les problèmes que je connais, on fait le partitionnement à plus haut niveau et chaque thread fait la recherche pour une occurrence plutôt que de collaborer sur une occurrence; peut-être dans les algo de monte-carlo/las vegas)

[Gotch4]

Merci de répondre si rapidement ,
c'est en fait un projet que j'ai pour les cours je n'ai pas de choix sur l'algorithme.

Non je n'ai pas 50 procos mais je pensais lancer une vague de thread histoire de pouvoir tirer profits des différents cœurs, si il y en a plusieurs ;x.

Le fait est que la solution que vous m'avez tout deux expliqués est bonne et si j'ai bien compris, ce n'est pas la façon dont je dois réaliser mon application.J'ai manqué de clarté dans mes explications et je m'en excuse.

Le test de puissance est une suggestion de mon prof et après relecture du sujet j'avoue que je n'en voie pas personnellement l'utilité je vais plutôt me tourner vers lui pour la suite.

M'enfin bon je vous remercie pour vos réponses j'ai quand même appris des trucs :p. Je passe en résolu

[therwald]

Non je n'ai pas 50 procos mais je pensais lancer une vague de thread histoire de pouvoir tirer profits des différents cœurs, si il y en a plusieurs ;x.

Une dernière chose: envoyer des paquets de calcul assez gros est plutôt une bonne idée pour éviter de consommer trop de temps sur le coût propre de la connection réseau. Par contre, comme le dit Jean-Marc.Bourguet, avoir plus de threads de calcul que de coeurs ne donne pas de bons résultats. Le switch de context quand tu passes d'une thread à l'autre n'est pas gratuit, donc multiplier les thread peut même ralentir le traitement au lieu de l'accélérer!