Discussion :

[developpeurP00]

Bonjour.
j'ai programmé un code parallèle avec la librairie MPI.

quand j'ai exécuté le code sur 2 processeurs ;j'ai remarqué que le temps de calcul a augmenté au lieu de diminuer par rapport à 1 seul processeur.

pour comprendre le problème ;j'ai enlevé toutes les communications et les synchronisations et Donc chaque processus va s'exécuter indépendamment de l'autre

et la surprise est que le temps de calcul est toujours + grand sur 2 processeurs

ça ne vient pas de l'initialisation ou la finalisation de MPI. c'est le coeur de calcul qui prend + de temps quand on travaille sur deux processeurs

On dirait que les deux processus s'exécuteront chacun son tour sur un seul processeur !!!

j'ai : Intel(R) Core(TM) i3 CPU -> double cœur (PC portable personnel )
commande d'exécution : mpirun -np 2 ./programme

Je ne sais pas vraiment ou ça vient le problème .quelqu'un pourrait m'aider?

Merci

[salseropom]

Salut, peux-tu s'il te plait nous envoyer ton code (enfin juste la partie nécessaire) ?

Merci

[developpeurP00]

salut ;merci pour ta proposition d'aide

en fait le code est très lent

mais mon programme a cette forme

Code :

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

1
2
3
4
5
6
7
8
9
---> initialisation MPI,constantes physiques ,.....
 
     DO time=1, n_time_step
         time      =   time + dt
         call calcul()
         ! call communication()
    ENDDO
 
---> fin MPI,

le reste est que de l'initialisation et autre choses. c'est la fonction calcul() qui prends du temps ( qui a comme outputs des grandeurs physiques calculés par des schémas de différence finis )

entre 1 et 2 processus la fonction calcul() ne change pas et j'ai mis l'appel de la fonction communication() en commentaire pour tester

Je peux mettre des autres résumés des parties mon code selon vos demandes.
puis je savoir si mon programme utilise vraiment deux processeurs ? ( c'est une piste seulement ;je doute que ça vient de ça ).j'ai l'impression que le problème n'est pas numérique. c'est bizarre !! peut être qu'il faut mettre une option à mpirun (ou mpiexec)
Je ne sais pas .ce sont que idées

Merci

[plumedesiles]

Salut,

peux tu nous donner des précisions comme quelle version de MPI tu utilises ?

peux tu également relancer ton code sur ta machine et faire un top (si tu es sous linux) et nous dire si ton processeur est à 100%.

De combien est la différence entre une exécution sur un coeur et deux ?
Quand tu exécutes sur deux coeurs, ton problème est-il diviser en deux ou c'est deux fois le même code de calcul qui est exécuté ?

[developpeurP00]

bonjour ;merci pour ta proposition d'aide parce que j'ai toujours ce problème

pour répondre à tes question alors :

-j'utilise la librairie OpenMPI version 1.4.1
- ci joint une capture d'écran pour le top : l'exécutable s'appelle 'programme'

effectivement la plupart du temps j'ai des valeurs élevés 98 , 99 , 100 pour la consommation CPU

mais cela n'explique pas le problème parce que chaque processeur exécute son code à lui indépendamment de l'autre ;non? peut être que c'est là le problème
d'ailleurs quand j'exécute le code sur un seul processeur j'ai aussi presque 100 %

- Je n'ai pas un calcul exacte du temps mais il y a une grande différence remarquable

Pour estimer ; j'ai fait un test et donc le code sur un seul processeur prend 60 seconde et sur deux processeur il prend 180 secondes

- pour ta dernière question ; quand je lance le code sur deux processeur alors le problème se divise en deux ;c'est le même code mais on divise en deux les domaine de calcul; c'est le principe du calcul parallèle

[salseropom]

Salut,

1) ton code est en fortran (et non en C++)
2) le principe de MPI est de faire du calcul sur plusieurs ordinateurs donc rien ne garantira que ton CPU soit à 100 %
3) j'ai moi aussi fait du MPI et la très très grande lenteur de mon programme venait des envois et réceptions des données qui étaient partagées entre les différents processus. Je m'explique, j'avais un paramètre N et je créais donc N processus (N = 200 environ). C'était de la folie car je passais 99.9 % du temps à créer les processus, et à attendre de toute envoyer / tout recevoir. J'ai donc créer que M processus (M == nombre de noeuds de ma grappe) mais j'envoyer bcp de données à la fois). Et là, l'exécution de mon programme était très très très rapide.

[developpeurP00]

salut ;

J'ai dit que j'ai enlevé toute communication entre les deux processus
oui le code est en fortran mais le problème ne concerne pas le langage mais MPI

c'est normal que avec N=200 ça devient lent ;

tu as dépassé les capacités matérielles de ta machine et donc tu gagneras rien en augmentant le nombre de processus

mais moi je le fais tourner sur 2 processeurs seulement et ma machine est un double coeur

cela peut venir de 100% de CPU que j'ai ? il présente quoi exactement ce pourcentage

Merci

[yan]

c'est pas plutôt open MP que tu voulais utiliser??

MPI c'est du traitement distribué sur plusieurs machine. pas pour du multiprocess.

[developpeurP00]

salut

non c'est OpenMPI (librairie pour MPI comme MPICH) et non OpenMP ; il y a une différence . on peut utiliser MPI sur plusieurs processeurs de la même machine

[yan]

on peut utiliser MPI sur plusieurs processeurs de la même machine

Oui mais c'est pas prévue pour. Contrairement à OpenMP...
Donc que ce soit plus long, ça ne m'étonne pas plus que cela.

[developpeurP00]

Je n'ai pas bien compris Yan ce que tu veux dire

J'ai une machine multi-processeurs .chaque processeur va utiliser sa mémoire locale pour exécuter le code .

peut tu m'expliquer encore + ton point de vue ?

penses tu que si je tourne mon code sur un cluster (grappe de machines) je gagnerai du temps ? pourquoi ça ne marche pas sur ma machine alors qu'elle multi-processeurs
Merci
ci dessous les caractéristiques de mon CPU:


azer@azer-laptop:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz
stepping : 2
cpu MHz : 933.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 4255.85
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz
stepping : 2
cpu MHz : 933.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 4
initial apicid : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 4256.07
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz
stepping : 2
cpu MHz : 933.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 4255.83
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz
stepping : 2
cpu MHz : 933.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 5
initial apicid : 5
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 4255.90
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

[yan]

Paralléliser un code ne veut pas forcement dire + rapide. En très simplifié :

• Sans parallélisation, ton calcul va prendre une temps T.
• Avec parallélisation, ton code va prendre un temps T/N +delta.

Delta étant le temps nécéssaire pour la parallélisation. Si le delta est grand T/N +delta peut être plus grand que T

MPI est pour de la Parallélisation multi machine.
OpenMP (ou tbb & co) est pour de la Parallélisation mono machine.

Pour du calcule brut, le delta est certainement + grand avec MPI que OpenMP car ce n'est pas le même mode de communications entre les acteurs.

Après ça va dépendre de beaucoup de chose et là c'est plus difficile de te répondre.


Si tu passe de 60 seconde à 180 secondes ça fait quand même beaucoup.. Donc y as surement un autre problème.
Tu as bien compilé en release? (on ne sait jamais).


Comme tu es sous linux, y as des outils (un truc comme Callgrind) qui permettent de faire des stat sur l'exécution et de voir où ton programme passe le plus de temps. Ça pourrai te permettre de voir ou cela cloche.

[edit]
Normalement chaque serveur MPI lance un process qui fera le calcul. Peut être que :

• il lance un process par pas de l'itération
• c'est le temps d'initialisation qui est très longue (lecture de fichier ,...)
• les deux

[plumedesiles]

@Yan

c'est pas plutôt open MP que tu voulais utiliser??

MPI c'est du traitement distribué sur plusieurs machine. pas pour du multiprocess.

MPI fonctionne très bien sur les machines à mémoire partagée et pour cause les librairies comme MVAPICH et OpenMPI sont prévues pour. En effet, la librairie détecte autmatiquement que la communication doit se faire une sur machine à mémoire partagée et fait une copie mémoire de la donnée à envoyer et ne fait pas une communication à travers le réseau.
Il est vrai qu'OpenMP est concu pour les machines à mémoire partagée mais dans la littérature il est démontré que dans la pluspart des cas, et je dis bien la pluspart car cela dépend des algorithmes, MPI est plus performant que OpenMP. Car MPI permet de clouer les processus (setter l'affinité du process) et permet donc de mieux exploiter la localité des données. Avec OpenMP c'est aussi possible mais ce n'est pas très simple.

De toute manière ce n'est pas la question puisque son programme n'a plus de communication et rame

@utilisateur 38

Merci pour le screenshot. Je voulais vérifier si les deux process étaient lancés et s'exécutait bien à 100%.
Personnellement je n'aime pas OpenMPI, bien que beaucoup trouve qu'aujourdui la librairie est au point. Bref passons.
En l'état, je ne vois pas très bien ce qui peut poser problème. Je te propose de m'envoyer le code par mail si tu veux et si tu peux bien entendu. Comme ca je pourrais le vérifier sur ma plateforme. Je connais le problème des differences finies donc je pense pouvoir t'aider.

[yan]

Il est vrai qu'OpenMP est concu pour les machines à mémoire partagée mais dans la littérature il est démontré que dans la pluspart des cas, et je dis bien la pluspart car cela dépend des algorithmes, MPI est plus performant que OpenMP. Car MPI permet de clouer les processus (setter l'affinité du process) et permet donc de mieux exploiter la localité des données. Avec OpenMP c'est aussi possible mais ce n'est pas très simple.

ça m'étonne
Mais je ne te contredirais pas, je ne connait pas tant que cela mpi et openMP.