Discussion :

[dhoorens]

Bonjour

Tout est presque dans le titre, cependant je vais un peu etayer ma demande.
J'aimerais lancer un projet au boulot qui consisterais en le calcul de certaines choses à travers pas mal de simulations.
J'aurais qqch du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
for (uint i = 1; i< simulationMAX; i++){
//... très long code fct (i) avec indépendance entre fct(i) et fct (j) pour tout //i<>j
}

A priori simulationMAX vaut minimum 1.000 et pourrait aller jusque 10.000
Pour le moment si je fais tourner ce genre de boucle sur un CPU j'en ai pour 15000 minutes ( ce qui est quand meme un peu long :-)

J'ai à ma disposition ma propre machine (2 CPU) et les machines de mes collègues sur lesquels j'ai droit d'admin => je pourrais avoir en terme de droit d'administration accès à 7 machines (=>14 CPU), mais je pourrais tenter d'avoir accès à 25 machines supplémentaires (=> 50 CPU) mais sur lesquels je n'ai pas de droit d'admin.
Ce que j'entends par droit d'admin est défini par la sécurité de la boite et me donne accès à tous les répertoires et je peux installer ce que je veux.
Si je n'ai pas de droit d'admin, j'ai accès à certain s folders mais pas aux reperoires système par exemple. Cependant si le projet fonctionne il serait envisageable d'ouvrir un peu plus les PC..

J'ai vu comment utiliser OpenMP. Ca fonctionne (heuruesement :-) ) sur ma machine, mais je ne sais pas s'il est possible d'utiliser cela au dela de ma machine mais sur d'autres machines aussi.
Si oui, comment? Faut il installer qqch sur els autres machines? Faut il modifier le code? Comment accède-t-on aux autres CPU?

Quels sont les problèmes au niveau de la sécurité reseau (Si la sécurité ouvre l'accès entre ma machine et les 25 mahcines..)?
D'autres expériences?

Merci
D

[3DArchi]

Salut,
A priori, OpenMP c'est sur la même machine. Pour massivement paralléliser tes simulations tu as plusieurs options :
-> CUDA ou tout autre environnement de GPGPU, mais ça reste sur la même machine.
-> Sur différentes machines, il faudrait peut être regardé ce qui est grille et des framework pour construire des applis distribuées.

[dhoorens]

A propos (pour moi et peut -être pour d'autres), voici un lien sympa sur openMP
http://msdn.microsoft.com/en-us/magazine/cc163717.aspx

[3DArchi]

Il y aussi des tutoriels OpenMP proposés sur DVP.

[epsilon68]

il faut faire du client server...

donc les machines de tes collegues sont les clients,
et tu es le server...
bon coucou les sockets etc

mais ce que je pense c'est qu'il serait peut-etre bien d'explorer la voie "database" comme centralisateur

toi tu mets les taches dans une DB (les 1000 simulations)
les clients verifient la db si il y a des taches puis les executent.

les clients devront appeler une stored procedure pour leur attribuer le numero d'une simulation non encore faite, attention a l'acces concurentiel...

ca sera peut-etre moins rapide que les sockets, mais tu pourras verifier les calculs apres coup. mais par contre ce qui est pas top, c'est la pompe a message....

remarque maintenant que j'y pense, il y a aussi l'option DCOM avec windows... en .NET pour eviter les longues parties de code pour rien...
avec DCOM, tu peux instancier un objet sur une certaine machine, et il fera le marshalling des argument pour toi... c'est pas mal.

donc pour resumer:

1. client server classique avec sockets
2. DCOM mais que sur Windows avec .NET
3. database + client pompe a message...

vos avis?


EDIT
c'est interessant comme probleme ... ca me donne envie de coder :-D

[Mac LAK]

Le problème de la parallélisation au niveau machine (= utiliser tous les CPU/coeurs disponibles) et celui de la distribution (= utiliser plusieurs machines) sont relativement différents.

Pour le premier, tu as le choix entre des frameworks tout prêts type OpenMP, ou du parallélisme "manuel". Dans les deux cas, cela n'a pas beaucoup d'importance car ce n'est pas excessivement complexe dans ton cas : en effet, tu as besoin de threads de travail autonomes, et non pas d'interactions complexes entre threads tournant continuellement. Tu es dans le cas le plus simple.

Dans le cas de la distribution, il faut voir des paramètres cruciaux :

• Taille des données source,
• Taille des résultats,
• Temps de calcul UNITAIRE sur ces données.

Typiquement, et pour volontairement exagérer, plus la taille totale des données (source + résultat) est "volumineuse" et le temps de calcul "petit", moins la distribution est intéressante / rentable. Inversement, de très petites données pour un temps CPU important est très intéressant pour la distribution.

Si c'est bien le cas, alors la distribution est rentable. Sinon, elle ne l'est pas, et seule l'utilisation de plusieurs CPU (ayant déjà un accès direct aux données) sera rentable pour accélérer ton traitement.

Une erreur courante en parallélisme est de penser que paralléliser un traitement fait gagner du temps machine. C'est faux : cela fait gagner du temps physique (=celui de ta montre), mais cela augmente toujours la charge CPU (=le temps CPU passé à réaliser l'action, inclus chaque coeur et la charge de transfert réseau des données).

Donc, si le temps supplémentaire nécessaire au lancement d'une deuxième unité d'exécution est supérieur au temps de calcul, la parallélisation n'est pas rentable.


Pour les solutions envisageable afin de distribuer ton calcul, la première chose à connaître sont les trois paramètres précités : taille des données source, des données résultat et temps de traitement pour cette unité "atomique" de calcul.
Mais il est tout à fait possible de rendre le processus complètement transparent pour le processus maître, qui se contentera de lancer 10.000 threads qui feront soit le calcul en local, soit en le distribuant en fonction de la charge de la machine, c'est même relativement simple d'ailleurs.

[dhoorens]

Dans le cas de la distribution, il faut voir des paramètres cruciaux :

• Taille des données source,
• Taille des résultats,
• Temps de calcul UNITAIRE sur ces données.

*En ce qui concerne les données source: je donne la taille en octets. Il s'agit d'un ensemble de tables qui peuvent être communes à toutes les simulations ou alors de paramètres spécifiques par simulation. Dans le premier cas, ca tourne aux aloentours de ~15 Mb, par contre les tables relatives aux simulations sont de l'ordre de 120 Mb => 120k par simulation

En ce qui concerne la taille des résultats, j'ai envie de dire que ca dépend...
Ca dépend pcq l'utilisateur peut avoir envie d'afficher beaucoup de résultats ou peu de résultats. Comme il s'agit d'un modèle avec pas mal de variables intermédiaires, il est possible de vouloir avoir en output par simulation je dirais de 50 à 1000 variables => ca depend...
Généralement on va plutot utiliser 50 variables . Je dois juste rajouter pour corser le tout qu'il s'agit d'un modèle dynamique => fct du temps => quand je dis 50 variables par simulation, ca désigne l'output de 50 variables par simulation ET par pas de temps =>50 var * 1000 * 500 pas de temps (héhé) => 25 Moutputs (vive les nouvelles unités :-)

En ce qui concerne le temps de calcul unitaire, que veux tu exactement dire?

Tks
D