Discussion :

[ParkerL31884]

Salut à tous,

J'ai un petit pb de lecture de fichier unformatted. Je m'explique.

J'ai un programme qui doit tourner à la fois sous environnement Windows et environnement Linux. Tous deux travaillent en double précision (réels codés sur 64 bits).

Ce programme fait appel (entre autres) à un fichier de données. Il est inenvisageable de stocker les données de ce fichier au format texte car les fichiers occuperaient alors plusieurs Go pour conserver une précision suffisante (donc problème de taille, de temps d'accès / lecture / mise en mémoire, etc.)

Le souci vient, vous vous en doutiez, du fait que le unformatted de Windows n'est pas le même que le unformatted de Linux. Tous deux supposent bien les données elles-même en 64 bits et en little endian, donc jusque là tout va bien... sauf que les marqueurs de début et fin de ligne font 32 bits sous Windows et 64 sous Linux. C'est la seule différence.

Sous Windows :

(marqueur de début sur 32 bits) données sur 64 bits little endian (marqueur de fin sur 32 bits) puis rebelote (marqueur de début sur 32 bits) données sur 64 bits little endian (marqueur de fin sur 32 bits)... etc

Sous Linux :

(marqueur de début sur 64 bits) données sur 64 bits little endian (marqueur de fin sur 64 bits) puis rebelote (marqueur de début sur 64 bits) données sur 64 bits little endian (marqueur de fin sur 64 bits)... etc

Auriez-vous une idée pour que je puisse lire un de ces formats sur les deux plateformes (bien sûr c'est ok que le code de l'un soit différent de l'autre, en revanche le fichier de données doit bien rester le même fichier physique) ?

Avec mes fichiers pour l'instant en 64 bits little endian avec marqueurs sur 64 bits (format Linux, donc qui se lisent parfaitement sous Linux), il me suffirait par exemple de pouvoir dire dans le code de la section Windows de "sauter" 32 bits supplémentaires en début et fin de chaque ligne (comme ça 32 sautés automatiquement pour cause d'en-tête 32 bits plus 32 bonus = 64 = gagné)

En sachant enfin qu'éventuellement, je peux changer de format de fichier (donc je peux choisir d'utiliser du 64 le avec marqueur sur 32 bits par exemple... du moment que je m'y tiens et que je ne fais pas cohabiter deux versions) mais que ça ne peut pas être du texte pour les raisons déjà décrites.

Merci de votre aide...

[Sylvain Bergeron]

Première piste à explorer : Peux-tu forcer la taille du marqueur, via une switch du compilateur, sur l'un où l'autre des OS ?

Autres pistes :

• Changer l'un des compilateurs
• Utiliser un fichier stream unformatted et non séquentiel

[ParkerL31884]

Première piste à explorer : Peux-tu forcer la taille du marqueur, via une switch du compilateur, sur l'un où l'autre des OS ?

Autres pistes :

• Changer l'un des compilateurs
• Utiliser un fichier stream unformatted et non séquentiel

Salut, merci pour la réponse. Je vais chercher dans les options de compilation.

Sinon pour la dernière suggestion, tu me suggères si je comprends bien d'utiliser un fichier en accès direct ? Y a-t-il un coût sur le temps d'accès, la mise en mémoire, etc. par rapport à un séquentiel ?

Pour info mon OPEN/READ actuel est (du bon vieux F77...)

Code :

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

1
2
3
4
5
6
7
8
9
      i=1
      OPEN(NFTRAJ,FILE='blablabla',FORM='UNFORMATTED')

 12   READ(NFTRAJ,END=11) tableau1(i),tableau2(i),...,tableau25(i)
      i=i+1
      GOTO 12

 11   CONTINUE

[Sylvain Bergeron]

Je ne pensais pas à un fichier à accès direct, mais à un fichier stream (Fortran 2003), généralement implanté comme « binary » en Fortran 90.

Mais si tous les records ont effectivement la même longueur comme le suggère ton extrait de code, j'opterais pour l'accès direct. Pour la performance, ll n'y aura pas de perte (à mon avis) si tu lis quand même séquentiellement le fichier.

[ParkerL31884]

Je ne pensais pas à un fichier à accès direct, mais à un fichier stream (Fortran 2003), généralement implanté comme « binary » en Fortran 90.

Mais si tous les records ont effectivement la même longueur comme le suggère ton extrait de code, j'opterais pour l'accès direct. Pour la performance, ll n'y aura pas de perte (à mon avis) si tu lis quand même séquentiellement le fichier.

D'accord, merci beaucoup pour l'aide. Je retiens ça pour une éventuelle autre fois.

Pour info j'ai résolu le pb grâce aux options de compilation comme tu le suggérais.

En fait ce n'était pas un pb d'architecture machine comme je le pensais mais de compilo. Le standard parmi la plupart (tous ? Intel, gfortran récent, gcc, même f77...) des compilos est de faire des en-têtes de 4 octets (que les enregistrements soient en simple ou double précision). Malheureusement la version de gfortran installée sur nos machines Linux date un peu (moins récente que sous Windows) et visiblement ces vieilles versions ont le mauvais goût de faire des en-têtes sur 8 octets.

Heureusement l'option de compilation -frecord-marker existe et faire -frecord-marker=4 a permis de forcer les entêtes sur 4 octets sur le vieux gfortran.

Merci