2010-08-06 6 views
3

Sur une boîte multicoeur, les décisions de horairistes de transport thread java sont assez arbitraires, il attribue les priorités de fil en fonction lorsque le fil a été créé, à partir de quel fil il a été créé etc.Cette idée de projet java est-elle pratique? (Ordonnanceur et particules Swarm Optimisation)

L'idée est d'exécuter un processus de réglage en utilisant pso qui définirait aléatoirement les priorités de thread et ensuite atteindre des priorités optimales où la fonction de fitness est la durée totale du programme?

Bien sûr, il y aurait plus de paramètres, comme les priorités changeraient pendant la course pour trouver une fonction de priorité optimale.

Comment pratique, intéressant l'idée sonne? et toutes les suggestions. Juste quelques informations, ive été en programmation en java/c/C++ depuis quelques années avec divers projets, une autre alternative serait de faire un planificateur de threads basé sur ceci en c, où le planificateur de thread par défaut est le système d'exploitation.

+0

Faire une exécution complète d'un programme pour chaque particule pour chaque itération semble être relativement lent.L'avantage de la lenteur est que vous pouvez faire des choses plus intelligentes entre les itérations sans que cela ne soit le goulot d'étranglement. Peut-être ASA avec une sorte de mesure de crowding pour explorer l'espace? –

Répondre

0

Meilleure façon de savoir: démarrez un projet open source et observez l'utilisation/la réaction des utilisateurs.

Cela me semble très intéressant - mais je personnellement ne le trouve pas très utile. Nous ne sommes peut-être pas au point où la programmation concurrente est aussi répandue et facile qu'elle pourrait l'être.

Avec la promotion de la programmation fonctionnelle, je suppose que le monde se déplacerait vers éviter la synchronisation des threads autant que possible (ce qui rend la planification fil moins d'impact sur la performance globale)

De mon expérience personnelle subjective, plus la performance les problèmes dans les logiciels peuvent être résolus en améliorant un seul goulot d'étranglement qui représente 90% du ralentissement. Cet optimiseur peut aider à trouver cela. Cependant, je ne suis pas certain de la mesure dans laquelle la stratégie de planification pourrait améliorer la performance globale.

Ne vous découragez pas! Je parle juste de l'air mince. Cela semble amusant, alors pourquoi ne pas simplement jouer avec? :)

2

Votre approche est une approche statique, c'est-à-dire que vous devez exécuter le programme plusieurs fois, puis proposer une solution de planification, puis expédier vos informations de planification avec le programme.

Le problème est que pour la plupart des programmes non triviaux, leurs performances dépendent en partie des données spécifiques avec lesquelles ils travaillent. Même si vous trouvez un moyen optimal de programmer des threads pour un jeu de données, il n'y a absolument aucune garantie qu'il améliorera la vitesse sur un autre. Dans la plupart des cas, exécuter ce qui sera une optimisation longue et laborieuse chaque fois qu'ils veulent faire une nouvelle version ne vaudra pas la peine pour les développeurs, sauf peut-être pour les gros calculs (où les programmes sont susceptibles d'être réglés manuellement Java de toute façon). Je dirais qu'un programmateur de thread auto-apprentissage est une bonne idée, mais vous ne pouvez pas le traiter comme un problème d'optimisation classique ici. Vous devez soit être sûr que votre ordre de programmation restera optimal (peu probable) ou trouver une méthode d'optimisation qui fonctionne à l'exécution. Et le problème ici pourrait être que cela ne prendrait pas beaucoup de temps pour votre ordonnanceur de détruire tout gain de performance que vous pourriez obtenir.

Je pense que c'est une question quelque peu subjective, mais globalement non, ne pense pas que cela fonctionnerait. PSO est bien adapté pour les petites fonctions rapides.