Discussion :

[afrancisco]

Bonjour à tous,

Je me remets à mes recherches d'il y a quelques mois, c'est-à-dire trouver le (meilleur) moyen de développer un soft : en fortran pour les routines scientifiques et éventuellement C pour la GUI indépendante (GTK par ex pour un multi-plateformes). Les routines fortran lisent des infos de fréquence d'écriture de résultats (déterminée par l'utilisateur via la GUI) dans un fichier "in.dat" en entrée et les affichent dans un "out.dat" que la GUI lit (pour des barres de progression par exemple)

La question que je me pose est :
peut-on lancer des routines simultanément en fortran ? (multi-thread, sans passer par des .exe)
Si c'était possible (mais ça ne me dit rien), on pourrait envisager d'utiliser une interface fortran-GTK (pilib en l'occurence) pour tout programmer en fortran ...

Merci !

[genteur slayer]

Il y a une version de MPI pour G95 le seul hic (j'en tremble aussi) c'est que tu ne peux parrallèlisé que tes boucles.... je crois qu'il est possible de lancer plusieur subroutines en parallèle de cette manière mais j'ai pas testé....

autre hic, MPI est à mémoire divisée, donc il faut bien savoir quelle zonne mémoire tu envoie sur quel procésseur....

[FR119492]

Salut!

Je ne vois pas, comment, en Fortran standard, on pourrait lancer des routines simultanément; en revanche, en utilisant des .dll, il devrait être possible de lancer la même routine depuis des .exe distincts. Je n'ai jamais essayé moi-même (ça figure sur la très longue liste des choses que je voudrais faire quand j'aurai le temps...) mais il n'est pas exclu que ça soit la solution de ton problème. Si ça marche, je serais très curieux de le savoir.

Bonne chance.
Jean-Marc Blanc

[DaZumba]

Le multi-thread en fortran 77, on oublie : le code n'est pas ré-entrant. Pour les Fortran plus récents, le compilateur Intel supporte le multi-threading via OpenMP. Sinon, il y a High Performance Fortran.

Mais il faut voir si le jeu en vaut la chandelle. Dans ton cas, je verrais bien deux executables, un purement calculatoire, et l'autre qui analyse les résultats du premier à la volée (eventuellement, il peut même lancer le premier exec).

[afrancisco]

Salut,

merci à tous pour vos contributions.
Je vais, a priori, rester sur la solution suivante : (vu aussi la contrib qui suit)

Il est hautement recommandé d'éviter de faire des accès sur un fichier avec 2 langages distincts en même temps

Une interface fortran à GTK (*****) appelle des exe fortran en rendant la main, et les échanges se font par fichier interposé (car je souhaite faire du multi-processus mais pas multi-processeurs)
.... en espérant que le développement de ***** perdure.

[genteur slayer]

tu peux aussi via une utilisation judicieuse des pointeurs, utiliser uniquement la RAM et faire des pipes d'un processus à l'autre affin de ne pas utiliser de fichiers de transfers....

sinon tu peux essayer une synchronisation de tes processus (via les fonction time de fortran95) et les faire ouvrir/fermer le fichier tampon de manière asynchrone pour pas qu'il y ait de problèmes de lectures simultanée

[FR119492]

les faire ouvrir/fermer le fichier tampon de manière asynchrone pour pas qu'il y ait de problèmes de lectures simultanée

Je pense que c'est la bonne solution. On peut peut-être l'améliorer encore en définissant un fichier sur une unité virtuelle logée non pas sur le disque dur, mais dans la RAM. Je crois me souvenir que ça existe.

Jean-Marc Blanc

[Mat.M]

en fortran pour les routines scientifiques et éventuellement C pour la GUI indépendante (GTK par ex pour un multi-plateformes). Les routines fortran lisent des infos de fréquence d'écriture de résultats (déterminée par l'utilisateur via la GUI) dans un fichier "in.dat" en entrée et les affichent dans un "out.dat" que la GUI lit (pour des barres de progression par exemple)

est-ce que c'est possible de faire des fichier objets obj avec Fortran ?
Ainsi on peut les lier avec un programme développé en C/C++.
Pour les I/O je conseillerais de les développer en C/C++

[FR119492]

En principe, il n'y a aucun problème à appeler un sous-programme en Fortran depuis un programme en C ou inversement. Il faut seulement se rappeler que le Fortran stocke les tableaux colonne par colonne et le C ligne par ligne.

Jean-Marc Blanc

[afrancisco]

Salut,

Je pense que c'est la bonne solution. On peut peut-être l'améliorer encore en définissant un fichier sur une unité virtuelle logée non pas sur le disque dur, mais dans la RAM. Je crois me souvenir que ça existe.

Merci pour cette info, j'avoue humblement que je ne connaissais pas, je vais chercher de ce côté ; même pour autre chose ça peut servir (vitesse de communication)
Pour les pointeurs et les pipes, hummm... là, c'est un niveau au-dessus du mien. Mais, je vais chercher aussi ; genteur slayer a piqué ma curiosité