Stratégie de développement sous Fortran

- Débutant totalement en Fortran, j'ai recours au forum car je n'ai pas trouver d'article FAQ ni de cours traitant le sujet.

- Il m'a été demandé de porte un programme scientifique Fortan 90 pour usage monoposte en une version Fortan pour usage sur cluster HPC.

- L'examen des sources du programme monoposte monte qu'il y a beaucoup de fichiers .f contenant des fonctions utilisées dans le main.

- Serait-il judicieux de remplacer ces fichiers .f par des dll, ne serait-ce qu'en termes de maintenance ultérireues ? Faut-il attendre un gain de performances significatifs de l'appel à des dll ou au contraire une dégradation ?

- Merci de votre aide et de votre patience.

le passage en dll pose d'autre soucis que le simple gain ou perte de performance....
cela dit, il faut que ce ce qui se trouve dans la dll se suffise à lui-même, c'est à dire que la dll doit utiliser des infos contenue dans d'autre dll et/ou des données passé en paramètres... pas de variables globale...
ensuite je te conseil si c'est bien du fortran 90 de changer l'extension du fichier en f90 car certains compilateur vont faire la différence...

maintenant tu as parler d'utiliser le prog sur un cluser c'est à dire faire de la parallelisation en mémoire distribuée... il faut donc bien réfléchir à la structure des données utilisées... afin de les répartir sur les différents processus...

quel genre d'application il s'agit?

- Merci de la réponse.

- Le programme en question est une application de calcul scientifique sur les atomes.

- Une première mouture tourne déja à l'aide d'une fausse MPI sur des machines monoprocesseur monocoeur.

- La limitation actuelle porte sur le rayon de l'atome : sur une machine lambda, il ne faut pas dépasser un rayon de 6 ou 7. Ce qui provoque un calcul sur plusieurs jours. Alors avec un rayon de 10, c'est carrément impossible...

- Or les besoins d'augmenter le rayon de calcul évoluent..... D'ou l'idée de la parallélisation d'une part, et d'autre part ne charger que le strict nécessaire..

Salut!

Citation:

---

sur une machine lambda, il ne faut pas dépasser un rayon de 6 ou 7. Ce qui provoque un calcul sur plusieurs jours. Alors avec un rayon de 10, c'est carrément impossible...

---

Il vaut souvent la peine de remettre en question les algorithmes utilisés.
Jean-Marc Blanc

en complément de jean marc, je dirai que bien souvent les vieux algos ont été développer pour fonctionner sur des machines bien précise et que l'évolution du matériel informatique fait qu'il peuvent aujourd'hui être traiter d'une autre manière:
utilisation mémoire et processeurs...
bien souvent (j'en voit presque tous les jours :p ) l'utilisation de la mémoire peut être largement optimisé! et cela a une influence directe sur le temps de calcul....
de plus il faut voir la complexité de l'algo (typiquement tps de calcul en fonction du rayon atomique: t=f(N) )
bien souvent (il semble à vue de nez) que ton algo soit en N² voir au cube... idéalement il faut visé une complexité linéaire!!! ce qui n'est pas toujours possible...
mais sans forcément tout changer dans ce qui existe tu peux limiter les accès disque-dur, garder certaines données importantes en mémoire etc... ce qui va grandement accélérer le traitement!

Bonjour,

- Les problèmes sous-jacents à la question posée sont :

a) Le programme original a été développé par des personnes qui n'ont aucune notion de stratégie de développement, en l'occurence des scientifiques qui se sont mis à la programmation par raccroc.

b) Par exemple, les mêmes sources sont utilisées pour pour la version séquentielle et la version parallèle. La différence est faite au moment de la compilation par suppression de la fausse MPI et remplacée par un appel à la vraie ! Mais la version parallèle est faite ailleurs sous Linux et je dois travailler sous Windonws.

c) Je suis essentiellement Administrateur Système et Réseaux - Sécurité ! J'ai des notions de programmation certes mais pas aussi pointues que celles nécessaires pour de la programmation parralèle saine et bien construite. Quant à Fortran, à part le nom et les principaux domaines d'application........

d)J'ai déja dimensionné et bâti quatre clusters de baculement sous windows : je sais bien les configurer et les faire fonctionner. J'ai également dimensionner et bâti une maquette de cluster HPC windows 2008. Maintenant, il m'est demandé de la charger avec des applications ("Tu es informaticien, quel est le problème ?....").

e) En testant d'autres applications, j'ai très vite compris que les temps de calcul et les données générées par les applications scientifiques sont toujours des fonctions exponentielles de la complexité. Il suffit de faire des relevés et de tracer des courbes de regréssion...

f) Les essais de fonctionnemet sur cluster HPC de l'application en question montrent que ce n'est pas à priori un problème d'occupation de mémoire : à peine 2 Go sur sur les 8 Go de la machine. Je suppose donc que c'est le séquentiellement des calculs qui pose problème.

- Tout ceci pour expliquer que je cherche des conseils pour essayer de faire le meilleur portage possible sans me fourvoyer dans des impasses.

- Merci pour les réponses.

Citation:

---

("Tu es informaticien, quel est le problème ?....")

---

je vois parfaitement la situations :p malheureusement on se rend vite compte qu'il y a plusieurs métier derrière ce nom...

bon... 2Go c'est minuscule (pour une appli scientifique) à lo'heurte actuelle dans ma boite (on fait des soft de calcul, et je suis là pour faire les algos) on me les jette à la figure s'il sont en N^3, on grimace un peu s'ils sont en N², on me dit que c'est acceptable quand il sont en N .... cependant, un algo en complexité N est plus facilement parallelisable car le plus compliqué c'est de répartir à peu près également la charge de travail sur chacun des processus... ce qui est facilité quand la complexité est linéaire!!!

c'est classique d'utiliser les mêmes sources... notament: lors de paralelisation par sous-domaine le code est tellement peu modifié que c'est idiot de séparer les deux cas...

cela dit dans la notice de MPI y a pas mal de chose pour les répartition de calcul et tout... attention cela dit aux temps de communication... les process doivent communiquer le moins possible car cette communication est super lente et c'est ce qui peut plomber complètement un calcul parallèle. en faisant attention à cela, moi j'ai, réussit à avoir de très gros gain de performance... cela dit c'était sous linux.... j'ai jamais reussit à faire fonctionner avec windows (une histoire d'acces exclusif à je sais plus quel fichier ou périphérique....)