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