temps d'exécution long - C++ - Programmation
Marsh Posté le 09-05-2008 à 08:01:10
La parallelisation est toujours accompagnee d'un surcout (synchro, communication entre les threads). C'est pour ca que doubler le nombre de processeurs ne va pas diviser par deux le temps d'execution.
Peut etre que dans ton cas, tes processeurs passent plus de temps a communiquer entre eux qu'a effectuer le reel calcul, ce qui peut arriver si tu decoupes le calcul en morceaux "trop petits".
Marsh Posté le 09-05-2008 à 08:19:40
+1 avec Ace17.
La Loi d'Amdahl (http://fr.wikipedia.org/wiki/Loi_d'Amdahl) nous renseigne d'ailleurs sur ça.
Aprés, combien de noeud MPI utilises tu et combien de processeur physique as tu à disposition ?
Marsh Posté le 09-05-2008 à 19:44:51
si vous avez bien lit ce que j'ai écrit,
vous aurez remarquer que j'ai écrit, PAS DE COMMUNICATION,
donc pas de syncronisation,
en plus j'ai utilisé 2 processus et plus
Marsh Posté le 09-05-2008 à 22:23:12
2 et 3 et 4 et 5 mais toujours
si j'augmente les processeurs, le temps augmente
Marsh Posté le 10-05-2008 à 00:19:28
bonjour,
ayant utilisé assez significativement MPI (V1) dans le passé, j'ai un peu de mal à comprendre l'interet de l'utiliser si ce n'est pour ne pas utiliser de synchros de process
Donc cette tache prenant X, tu espère qu'elle dure combien en multi-process X ou X/N?
Si c'est X (en gros chacun doit l'executer complètement) es tu sur qu'il n'existe pas de synchro avant et/ou après qui se passent mal et donc qui pourrait faire qu'ils s'attendent les uns les autres avant d'executer la tache X?
Pourrais-tu nous décrire l'algorithme dans les grandes lignes, pour que l'on puisse "deviner"?
Marsh Posté le 10-05-2008 à 02:18:24
en fait j'ai fait ça pour tester mon application
car le temps total d'exécution à augmenter au lieu de diminuer
ça me rends fou ça, alors j'ai tout tester mais je sais pas comment je peux trouver un fil ou une piste pour trouver le problème,
je sais pas comment trouver la source de fuite
et en plus j'ai pas beaucoup de comunication
j'ai juste 2 envoi et 2 recv sur 2 processus(le slave envoie 2 messages vers le master)
sinon sur 3 processus deviennt 4 envois en 4 recv, etc
merci
Marsh Posté le 10-05-2008 à 08:57:30
y a forcement quelquechose qui cloche. Poste un bout de code ainsi que :
* la ligne de lancement mpirun/mpiexec
* les specs de la machine de tests
Marsh Posté le 10-05-2008 à 12:13:39
oui je sais qu'il ya une fuite mais je sais pas comment la détecter
pour l'exécution c'est MPIRUN -np 3 mon_programme parametre
pour le code ça commence pas les includes
des différents headers
puis des fonctions qui correspondants au déclarations de ces fonctions de mes classes
puis
void main(int argc, char *argv[])
{
vector<int> tab;
int myid, numprocs;
MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&numprocs);
MPI_Comm_rank(MPI_COMM_WORLD,&myid);
if(myid==0){....}
if(myid!=0)={
actuel=1;
...//traitement
for(int i=0;i<100;i++)//chaque i s'exécute sur un prosesseur
{
if(myid=actuel)
{....
}
actuel++;
if(actuel==numprocs)
actuel=1;
}//fin for
}
}
Marsh Posté le 10-05-2008 à 14:25:29
c'est moche
tu ferais mieux de faire une seule boucle for et de calculer ses bornes inf et sup en fonction de myid et de numprocs. la ton actuel++ à part donner envie de vomir, il sert pas à grand chose.
Et t'as pas répondu à la question : specs de la machine sur laquelle ca tourne
Marsh Posté le 10-05-2008 à 15:57:48
core duo, 2 Go de RAM et 120 Go le DD, Windows
pour la boucle, ok c'est moche mais c'est pas d'ici que vienne la fuite.
Marsh Posté le 10-05-2008 à 16:09:28
core duo = 2 proc. Donc pour np>2 t'attends pas à des miracles.
Ensuite, t'as vraiment que 100 elements à triturer ou bien ?
si oui, bah ton temps d'execution est pris par le demarrage de MPI plus qu'autre chose.
Ensuite, quelle MPI sous windows ? MPICH 2 ?
Marsh Posté le 10-05-2008 à 16:30:48
j'ai essayé avec plus que 2 proc
j'ai meme essayé avec un réseau local meme le temps augmente au lieu de diminuer
en j'ai pas vraiment 100 elements, dans des cas oui mais dans d'aute cas
plus que 300 mais toujours le temps augmente
j'ai essayé avec 1 seul proc j'ai trouvé que le temps augmente ,
normalemet je doit trouvé le meme temps que le séquentiel
donc il ya une fuite, mais j'ai pas pu la détecter.
enfin j'utilise MPI 1 et non pas 2
Marsh Posté le 10-05-2008 à 16:36:56
MPI 1 = the crap aussi.
mets à jour ton MPICH deja.
et tes calcul en sequentiel, ils prennent quoi comme temps ?
Marsh Posté le 10-05-2008 à 16:47:36
c'est quoi the crap.!!!
je peux pas utiliser mpi2 car je doit changer mon code, il parait que c'est pas les mêmes routines pour programmer en MPI 1 et 2.
le temps prends 18 secondes en séquentiel et avec MPI (1 seul proc)
devient 23secondes. et c'est pas un problème de communication, comme j'ai déja dis dans mon premier message posté
Marsh Posté le 10-05-2008 à 17:00:42
euh sauf que MPI 1 c'ets genre ante-diluvien.
Et de tete, les primitives restent les memes
Marsh Posté le 10-05-2008 à 19:04:26
pouvez vous m'expliquer plus?
vous pensez que le problème vient de l'ancienté de la version?
Marsh Posté le 10-05-2008 à 21:57:04
Au fait, c'est voulu le "if(myid=actuel) " (avec un seul 'egale' ) ?
Marsh Posté le 11-05-2008 à 13:57:59
Ouais ben utilise les balises code et indente tout ca, parce que la c'est illisible...
Marsh Posté le 11-05-2008 à 14:56:35
Joel F a écrit : c'est moche |
ou alors faire un truc genre :
Code :
|
Spoiler : |
Marsh Posté le 11-05-2008 à 15:32:56
mais je crois pas que c'est la source de la lenteur!!!!
en plus j'avais ça à la fin du boucle:
actuel++;
if(actuel>=numprocs)
{ actuel=1;
}
c'est à dire si le processus>nombre total des processesus alors on revient à 1.
mais comme je venais de dire je crois pas que c'est cette boucle qui provoque la lenteur!!!!
Marsh Posté le 11-05-2008 à 15:36:33
ca sert à rien de croire il faut savoir.
Donc essaye deja d'ecrire du code propre , de le poster proprement et on y verra deja mieux.
Marsh Posté le 11-05-2008 à 15:56:18
je l'ai fait comme ça:
int actuel=1
for(int f=0;f<nbf && myid==actuel && actuel<=numprocs;f++)
{
....
actuel++;
if(actuel>=numprocs)
{ actuel=1;
}
}
le temps est devenu le double !!!!!!!!!!!!!!!!!!!!!!!!!!
au lieu de s'améliorer
Marsh Posté le 11-05-2008 à 17:35:21
je t'ai dit de calculer des bornes min/max en fonction de rank/size puis de faire UNE seule boucle ou tu decoupes tes calculs ...
Marsh Posté le 11-05-2008 à 17:53:29
je l'ai fait avant mais la même chose le temps augmente
c'est ce qui me rends fou
Marsh Posté le 11-05-2008 à 19:53:28
j'ai remarqué que le temps double avec l'augmentation des process
exemple:
si avec 2 process=2sec
alors avec 3=4sec
avec 4=6sec
avec 5=8sec
j'ai fait un petit bout de code de mon application et je l'ai testé, ce code ne comporte pas d'envoi ni de recv, sans communication
mais je sais pas comment ça se fait
en dirait le processus 1 affecte le 2 et le 2 affecte le 3 etc
je veux dire les process ont des effet sur leurs capacités
Marsh Posté le 11-05-2008 à 19:57:14
comment veut tu avoir du gain avec np >2 sur un dual core avec 2 proc physique ?
tu comprends ce que tu fais ou pas ?
Marsh Posté le 11-05-2008 à 20:47:06
1- mais ça n'a rien à voir avec duo core
2-j'ai essayé avec 3, 4 et 5, 6processus et je t'ai dis le temps augmente
3- j'ai pas de communication donc , ce que vous dites s'applique quand il ya de la communication, et non pas que du calcul uniquement
4- j'ai essayé sur un réseau local 3 pcs(nouveaux), et j'ai eu le même résultat
alors qu'est ce que je doit comprendre???????
Marsh Posté le 12-05-2008 à 00:25:36
Re bonjour,
en général, en mp, s'il y a un pb de temps de traitement qui ne se divise pas par le nombre de processus effectif (en supposant que tu fais ce qu'il faut) c'est qu'il y a un pb de synchro...
Si tu dis qu'il n'y a aucun synchro (message) dans la boucle, alors c'est probablement que le problème vient d'avant et/ou d'après.
Dans un de tes premiers posts, tu mets "//traitement" avant le début de la boucle :
Code :
|
qu'y fais-tu?
Autre moyen : monitore l'execution de ton programme. Mets des logs (fprintf par exemple) à des points clefs (debut, debut de boucle, fin de boucle) avec le numéro de processus + date/heure/sec(si possible millisec) pour voir là où ça coince : ça peut aider...
Sinon je suis d'accord avec les autres : faire pour tout le monde une boucle de 100 itérations alors que chaque processeur va travailler 1/NbProcess % du temps, c'est inutile, il FAUT précalculer les bornes (quitte a faire que chacun travaille de 1 à N/NbProcess)
Bon courage
Marsh Posté le 12-05-2008 à 01:24:47
oui c vrai, mais ya des choses qui me rends fous,
la boucle par exmple je le fait comme vous dite,
j'ai fait avant la boucle donc un traitement, ce traitement m'as couté un temps de plus au lieu de se minimiser.
2- pour l'idée de calcul de chauque traitement en sec, je l'ai fait mais
je trouve par exemple une petite boucle for() prends 0,45 sec et je sais qu'elle ne doit pas passé 0,15sec mais c vraiment enbêtant, je sais pas pourquoi elle prends ce temps là, ya pas raison, et si j'augmente le nombre de processeur , ce temps augmente aussi,
j'ai vraiment tout fais , je manque d'idées
Marsh Posté le 12-05-2008 à 23:36:14
Bon alors, pour aller plus loin, à mon avis, il nous faut l'ensemble des MPI_Send/MPI_Recv/MPI_Barrier/...
Pourrais-tu nous remettre le code (que tu as déjà mis) mais avec en + les different MPI_[xxx]?
Je ne vois pas d'autre manière d'aider...
Marsh Posté le 13-05-2008 à 01:07:39
j'ai pas de communication
c'est juste 2 send et 2 recv, c'est rien, en plus ils sont à la fin du traitement,
c'est le calcul sur chque processus qui prends tout le temps
c'est pas un problème de communication.
Marsh Posté le 09-05-2008 à 01:58:19
bonjour,
j'ai une application parallèle en c++ et MPI,
j'ai une partie qui ne nécessite pas de communication avec mpi entre les processeurs.
En séquentiel cette partie prends un temps X et si je l'exécute avec mpi, sur plusieurs processus, elle prends plus de temps, presque le double.
avez une idée de ce problème?
grand merci pour vous