Paralleliser un algorithme

**Jeane** · 27/04/2007, 21h09

En fait ce qui prend vraiment du temps c'est le calcul des trajectoires.
Donc je pense que le mieux est de calculer les trajectoire dans chaque sous-cube et pour le transport effectif des molecules on n a pas besoin de paralleliser.

cad
1- envoit des donnee des sous-cub a chaque processeur
2- calcul des trajectoire par chaque proc
3- Transport des molecule par rapport au tajectoire calculer et actualisation des concentration de tous les noeud sur un seul proc
ainsi de suite...

**Jeane** · 27/04/2007, 21h21

D'ailleurs,

Mon code est en c++. MPI c l'un des mieux fait pour parralelliser ou il en existe des plus performant?

**mchk0123** · 01/05/2007, 20h52

Jeane dans ton premier message tout nous donnais un estimation du temps de traitement demandé par ton programme :

Envoyé par Jeane

Pour chaque pas de temps:
-> Calcul quel sont les noeuds qui vont etre modifier pour l'iteration presente ( 7% du temps)
-> Transport de Molecules pour les noeud actif (68% du temps) : - pour chaque noeud actif et chaque type de molecule on calcul la probabilite que n molecules se deplace vers l'un des voisisns puis on effectue les modifictaions.

Est-ce tu penses pouvoir affiner un peu et nous dire, parmis les 68% , quelle est la proportion de temps passée à faire :
- le calcul des nouvelles trajectoires
- le déplacement effectif et le calcul des nouvelles concentrations
?

Ca aiderais à voir les goulots d'étranglement ...

**Jeane** · 01/05/2007, 22h05

Est-ce tu penses pouvoir affiner un peu et nous dire, parmis les 68% , quelle est la proportion de temps passée à faire :
- le calcul des nouvelles trajectoires
?

cela varie entre 70% et 80% du temps utiliser dans la fonction Transport
soit environ 50-60% du temps totale

- le déplacement effectif et le calcul des nouvelles concentrations

cela varie entre 15% et 20% du temps utilise dans la fonction Transport
soit environ 10-15% du temps totale

**mchk0123** · 01/05/2007, 22h21

Oui donc les 80% du calcul de trajectoires (répartis sur n procs) sont théoriquement divisables infiniment pour peu que le nombre de procs n est grand. Sur ce sous-calcul (enfin peut-être que je fait erreur) mais tu ne devrais pas avoir de soucis de noeuds frontières.

Par contre, les 20% de l'application des mouvements & calculs de nouvelles concentrations seront surement irréductibles. Mais vu que cela ne représente "que" 10% du temps total, ton idée de faire le calcul simplement dans un seul proc me parait adéquat.