Discussion :

[moomba]

Bonjour

Je cherche à faire dialoguer un programme en Fortran, et un programme en JAVA. Pourquoi cela me direz vous ? Et bien le fortran est optimisé pour le calcul, et le java s'occupe de la partie réseau.

Dans ce cadre, une solution simple consisterai à faire dialoguer les 2 programmes par l'intermédiaire d'un fichier texte. Seul pépin, ils doivent tourner en même temps, et le programme Java ne doit pas utiliser du tout de temps CPU (le programme fortran doit tout avoir).

Il y a donc 3 phases :

1. Le programme JAVA récupère les données réseau et les transmet au programme fortran. Il lui donne ensuite l'ordre de démarrer le calcul. (tout se fait par l'intermédiaire d'un fichier texte). Durant cette phase, l'utilisation du CPU importe peu. A la fin de cette étape, le programme java libère toutes les ressources possibles.
   
   
2. Le programme fortran démarre son calcul. Il doit alors bénéficier de toute la puissance possible, cache, ram, HDD et CPU compris. Le programme JAVA doit rester dans son coin et attendre.
   Une fois le calcul finis, le programme fortran indique dans un fichier texte qu'il a finis.
   
   
3. Enfin, le programme java ayant détecté une modification du fichier texte vas aller le lire pour voir si le calcul est finis (il peut aussi lire une erreur qu'il communiquera au serveur). Il lit ensuite le fichier de données contenant les résultats, il les transmets par le réseau, puis il attend le cycle suivant.

Je cherche donc à épier une modification d'un fichier texte sans utiliser la moindre ressource. Est ce possible ?

Si vous avez une meilleur idée pour faire dialoguer les programmes, je suis preneur

[Uther]

Pour ce genre de problème, le plus efficace pour être sur de laisser le max de mémoire au programme fortran serait de découper totalement les 3 phases en 2 application java et une fortan qui se termineraient totalement quand elles ont terminé leur tache.
Un shel script(ne consomme quasiment pas de mémoire) se chargerait de les appeler les uns après les autre.

Après si tu demandes cela c'est surement que ce n'est pas possible. Malheureusement la seule façon que je connaise en java de détercter la modification d'un fichier est de vérifier sa date de modification a intervale régulier et donc de garder un thread en daemon.

[moomba]

Merci beaucoup pour ta réponse . L'idée n'est pas mauvaise, mais malheureusement, dans le cas présent, l'optimisation temporelle est de mise.

Je m'explique:

Le programme Fortran alloue de la mémoire pour conserver les données.
Sur une total de 50 PCs en réseau, plusieurs millions de points vont être répartis (un point = 3 composantes de vitesses, une température, une densité, une pression, etc etc), soit énormément de points par PC. Les écrire sur les HDD puis les relire prendrait beaucoup trop de temps
Le goulet d'étranglement doit se situer au niveau du cache du CPU, on doit optimiser les accès à la ram (stripping, etc), alors les appels au HDD... on doit les considérer comme proscrits
Le temps de démarrage d'un programme JAVA est lui aussi trop long, et comme les HDD sont réseau, cela ferait appel à ce dernier, qui sera déjà saturé.

Le gros pépin sur ce réseau vient du fait que certains PC sont sous linux, et d'autre sous windows. Il me faut donc un moyen totalement portable de les faire dialoguer. Je ne peut pas faire appel aux fonctions intrinsèques tel MPI et compagnie. (MPI n'est pas compatible windows)

Peut être peut-on utiliser une autre méthode pour faire dialoguer les 2 programmes, mais j'avoue que je pèche un peu... Si tu as une idée, n'hésite pas

[titourock]

Bonjour,

C'est un domaine que je ne connais vraiment pas bien mais as tu essayé des recherches du coté de "CORBA"? (pour faire communiquer des langages)
En espérant que ça puisse t'aider,

titourock

[sinok]

Ou sinon via une vieille socket à l'ancienne.

Ou encore un mécanisme à base de deux fichiers:
Un qui contient les données et un qui sert de flag pour dire à java de démarrer.

En tout cas tu peux toujours imaginer un daemon en java qui vérifie une seule fois toutes les 5 secondes (avec un lieux listFiles.length ou un new File("xxx").exists(); ) le contenu d'un répertoire, niveau coût mémoire et CPU c'est minimal un pauvre thread avec un Sleep (5000) fera l'affaire, vu le volume du calcul je suppose que 5 secondes de plus ne couteront rien.

[moomba]

C'est un domaine que je ne connais vraiment pas bien mais as tu essayé des recherches du coté de "CORBA"? (pour faire communiquer des langages)
En espérant que ça puisse t'aider,

Oui, cette idée m'as aidé, merci Même si il s'agit d'une approche trop complexe pour le moment, je garde cette idée sous le coude au cas où j'ai besoin de perfectionner les performances.

Ou sinon via une vieille socket à l'ancienne.

Là, on sort de mon domaine de connaissances
Il s'agit d'utiliser une écoute sur un port, c'est ça ? Le fortran ne possédant pas (à ma connaissance) d'API réseau, comment réaliser une telle chose ?

Ou encore un mécanisme à base de deux fichiers:
Un qui contient les données et un qui sert de flag pour dire à java de démarrer.

C'est ce que j'avais en idée. En fait, je me demandais si le fait de simplement vérifier si le fichier avait été modifié depuis la dernière lecture n'était pas moins gourmand en mémoire que le fait de le lire. En fait, ne possédant pas les droits admins, je ne peut qu'utiliser le disque réseau, et donc il faut aussi optimiser de ce côté : faire le moins de requêtes réseau possible. Là, seul un expérimenté pourra me répondre, en tout cas, j'en sais rien

En tout cas tu peux toujours imaginer un daemon en java qui vérifie une seule fois toutes les 5 secondes (avec un lieux listFiles.length ou un new File("xxx").exists(); ) le contenu d'un répertoire, niveau coût mémoire et CPU c'est minimal un pauvre thread avec un Sleep (5000) fera l'affaire, vu le volume du calcul je suppose que 5 secondes de plus ne couteront rien.

Effectivement, le volume étant énorme, je vais accepter cette concession. Cependant, existe t'il un moyen d'optimiser l'occupation mémoire de Java (sur 2 plans : le charger entièrement dés le départ (plus de demande au HDD réseau), et consommer le moins de ram possible)? J'entend par là qu'un programme Java à, à mon avis, tendance à être un peut gourmand en ressources.

Je vais déjà tester tout ceci, on verra bien. J'espère simplement que la création d'un cluster de calcul est possible sur un réseau si hétérogène (Linux (Ubuntu, Suse), Windows XP/2000, CPU simples ou doubles cœurs, (P4 ou Core 2 Duo), etc... )... Il vas en plus falloir détecter les performances des machines pour bien répartir les points de calcul (c'est possible de connaitre la fréquence du CPU et la ram installé à partir de JAVA ?)

Merci à tous pour votre aide

(PS: si vous avez une idée d'optimisation, ou si vous savez ce qui est le plus demandant en requêtes réseau entre lire un fichier et vérifier sa mise à jours, je suis preneur )

[sinok]

La question est que doit réaliser java par la suite, mais bon en jouant sur les paramètres d'initialisation, ça doit être jouable, sachant qu'un system de polling tel que je le décrit ne coute quasiment rien (une boucle toutes les 5 secondes c'est pas 20Mo de mémoire ni 20% de cpu, c'est presque rien, il n'y a quasiment pas d'objets créés, d'où quasiment pas de garbage collection).

Il te suffit de faire le tests sur une des machines les plus "faibles" de ton parc pour voir le cout réel.

De plus tu peux effectivement jouer sur les valeurs minimales/maximales de mémoire occupée par la JVM avec les paramètre -Xms -Xmx.


Mais sinon t'as pas moyen de lancer des commandes système en Fortran (genre exécuter un

Code :

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

java -jar monJar.jar monFichier.fich

c'est injouable?
Car sinon il te suffit de déclencher ça au moment idoine depuis fortran et l'affaire est close.
Par exemple si tu utilises le compilateur GNU fortran 77 tu as çà: http://www.delorie.com/gnu/docs/gcc/g77_316.html

Qui permet d'appeler une commande système.

[moomba]

Merci pour ces précisions. Je vais essayer sur les vieux P4 et voir ce qu'ils en disent. (c'est que c'est peut être vieux, mais ca gaz pas mal ces trucs là)

Je ne connaissait pas la subroutine call system() J'avoue avoir pourtant cherché longtemps, mais apparemment pas au bon endroit...
Voilà une très bonne nouvelle. Si les programme java, aussi léger soit-il, démarre assez vite, cela peut valoir le coup. (je ne pense pas que cela vas dépasser 5 s) Je vais essayer dés que possible. (mais pour le moment, ce sera sur sur un seul PC, le réseau étant non dispo jusque début janvier. )

Mon problème est donc résolus pour le moment. Ce n'est pas super optimisé, mais ça ira et ça tiendra le temps qu'il faudra. Je vais gagner beaucoup de temps pour faire mes calculs.

Encore merci à tous , et spécials thanks à toi sinok

Attendez vous à me revoir débarquer, avec d'autres demandes dans le genre, le code sera de plus en plus lourd, et il arrivera un moment où il faudra mieux optimiser la partie réseau (CORBA ?)

Bonnes fêtes à tous

[sinok]

Faire du CORBA en fortran va en fait impliquer que tu feras uniquement du C++ pour la couche Corba, en effet CORBA est définitivement orienté Objet (Common Object Request Broker Architecture)...

[sewatech]

Bonjour,

Si tu conserves ta solution de fichier, tu peux essayer de gérer les événements d'écriture de fichiers avec jNotify.

[dingoth]

jNotify n'est qu'une surcouche à un thread tel qu'expliqué plus haut.

[sewatech]

jNotify fonctionne avec un système événementiel fourni par le système d'exploitation. C'est pour cela qu'il ne supporte que Windows et Linux (INotify API). C'est aussi pour cela qu'il faut installer une dll ou un so, en plus des jars.

[moomba]

Bonjour tout le monde

Merci pour vos réponses.

Faire du CORBA en fortran va en fait impliquer que tu feras uniquement du C++ pour la couche Corba, en effet CORBA est définitivement orienté Objet (Common Object Request Broker Architecture)...

Dans une vie antérieur, j'ai fait du C++, mais c'était il y a bien longtemps... J'avoue ne plus du tout connaitre maintenant. Mais comme cela ressemble au JAVA, je pourrais toujours m'y remettre.

jNotify fonctionne avec un système événementiel fourni par le système d'exploitation.

Cela signifie t-il que le threat associé agira comme un listener en interface JFrame ? (i.e. ne pas consommer un parsec de CPU)
Mais encore une fois, il faudra de toute façon utiliser le réseau, puisque les fichiers sont sur un disque réseau distants. En y repensant, quitte à utiliser des fichiers pour faire dialoguer les 2 programmes, autant plutôt faire directement dialoguer tous les PC par fichiers, cela diminuera d'une manière conséquente l'utilisation du réseau. A mon avis, la solution des fichiers n'est acceptable que tant que le réseau supporte le traffic. (lié au nombre de PC)

Je tente actuellement d'utiliser le système LAM MPI, mais pas moyen de le compiler sous windows (Mingw). A moins de trouver comment compiler tout ça, (manque le support des threat, et en supprimant le test, impossible de finir le ./configure sans erreurs ), il faudra mettre de côté les PC sous windows.
Ils sont moins nombreux, donc je pense utiliser le système avec des fichiers (avec JAVA ou sans, je vais tester) pour les machines sous windows, et le LAM MPI pour les linux. Cela désengorge l'accès au disque dur réseau.

Je suis contraint de faire le noyau de calcul en Fotran, d'où la difficulté

J'avais une autre idée : peut t-on "geler" et "dégeler" un processus JAVA avec une commande ? (genre "numero_du_processus -wait=1", "numero_du_processus -wait=0")