Discussion :

[salseropom]

Bonjour, dans mon prgm je dois ouvrir N fichiers. A votre avis (et pourquoi) que vaut-il mieux que je fasse ?

1e méthode : j'ouvre tous les fichiers dès le début et ensuite j'écris dedans puis je les ferme

2e méthode : je fais une boucle, j'ouvre le 1e, j'écris dedans, je le ferme et je passe au suivant.

Bien sûr à chaque fois je test si fopen==NULL

Mon nombre de fichiers varie entre 2 et 1000. Est-ce que je perds plus de temps avec la 2e méthode qu'avec la 1e ?

Merci.

[Franck.H]

Mon nombre de fichiers varie entre 2 et 1000. Est-ce que je perds plus de temps avec la 2e méthode qu'avec la 1e ?

Je ne pense pas que tu perds plus de temps avec l'une ou l'autre car dans tous les cas tu ouvrira le même nombre de fichiers donc je pencherais plutot pour une ouverture de fichier à chaque tour de boucle !

[Ti-R]

La 2eme méthode est mieux !

Bien sûr à chaque fois je test si fopen==NULL

Bien entendu !

Mon nombre de fichiers varie entre 2 et 1000. Est-ce que je perds plus de temps avec la 2e méthode qu'avec la 1e ?

Non, logiquement tu devrais en gagner (pas beaucoup) avec la méthode 2, car il faut penser au niveau du matériel et logiciel, dans la méthode 1 tu ouvres un flux vers 1000 fichiers, donc concrètement ton programme commence à buffériser tous les début de fichiers, et ton disque dur doit déplacer ta tête de lecture partout, donc il y a beaucoup de donnée stocké en mémoire au départ et ton disque dur travaille beaucoup, si tu lis et écrits au même endroit, la tête de lecture du disque dur devrait logiquement moins bouger et donc être plus efficace.

[DaZumba]

Les deux methodes sont assez equivalentes en terme de rapidite, puisque le nombre de fopen()/ecriture/fclose() est le meme dans les deux. L'utilisation memoire sera legerement plus importante avec la methode 1 (besoin d'un tableau de pointeurs sur FILE), mais de nos jours, c'est sans importance.
Le seul probleme avec la premiere methode est que le nombre de flux qu'un processus peut ouvrir est limite par le systeme, un probleme que tu as rencontre dans ton post "Trop de fopen". La seconde methode coutourne se probleme en n'ouvrant qu'un seul a la fois. La premiere methode, par contre, est peut-etre plus facilement parallelisable, meme si les operations d'I/O sont toujours problematiques sur ce point.

ton disque dur travaille beaucoup, si tu lis et écrits au même endroit, la tête de lecture du disque dur devrait logiquement moins bouger et donc être plus efficace.

C'est difficile d'etre formel. Les disques durs actuels ont des caches importants et l'ecriture elle-meme est optimisee.

[Ti-R]

C'est difficile d'etre formel. Les disques durs actuels ont des caches importants et l'ecriture elle-meme est optimisee.

C'est vrai que sur 2 fichiers on ne verra pas la différence, et sur 1000 fichiers la différence sera faible mais je pense perceptible.

Mais même si le cache est important sur les disques dur (bien que la taille soit assez faible 16mo maxi), sur 1000 fichiers qu'on à pas encore accédé, ils ne peuvent être mis en cache. L'écriture est optimisé il est vrai, mais autant essayer de palier les problèmes avant qu’ils n’arrivent, et ne pas se reposer entièrement sur le côté technique du matériel en espèrent que le côté logiciel n’influera pas les performances matériels.

C'est juste le point que je voulais souligner

[D[r]eadLock]

Perso, je préfèrais la 2ième méthode (1 fichier par boucle):
- si tu plante au milieu, tu as déja tes i fichiers
- moins de FileHandles a avoir (plus facile)
- je ne vois pourquoi la première méthode serais plus rapide, si tu dois ouvrir N fichiers une fois, c'est pareil non ? (ok, juste le temps de latence entre l'ouverture et l'écriture, mais c'est au scheduler de s'occuper de ça).

Si t'as le courrage, essaie les deux, et donne-nous les stats

ton disque dur travaille beaucoup, si tu lis et écrits au même endroit, la tête de lecture du disque dur devrait logiquement moins bouger et donc être plus efficace.

Je ne vois pas pourquoi il écrirait au même endroit, vu que les fichiers sont différents

Rq: pour les perfs, y'a aussi le scheduler d'IO, et pas uniquement le cache du disque...

[salseropom]

OK, merci de vos remarques. Je vais donc opter pour la 2e méthode. D[r]eadLock, je lance les deux versions et j'afficherai ensuite mes temps de calcul.

[salseropom]

Re,
voilà qui est fait, avec la 1e méthode le temps de calcul est de 485 s et avec la seconde il est de 490 s (test effectué sur 5 simulations)

Merci de vos remarques.

[Ti-R]

Combien de fichiers ?
Comment cela a été mesuré ?

[salseropom]

Salut, j'ouvre 7 fichiers (car N = 5). J'ai lancé 5 fois mon prgm (pour les deux versions) et j'ai fait la moyenne du temps écoulé (à l'aide de difftime)
Mais je voulais juste avoir une idée de la différence de temps, meme si 5 simulations n'est pas très représentatif.

[Franck.H]

meme si 5 simulations n'est pas très représentatif.

Surtout sur seulement 5 fichiers Il faudrais au moins le faire à assez grande échelle genre une centaine de fichiers Mais là encore le temps peut varier suivant ce qu'il y'a à écrire dans chaque fichiers !

[salseropom]

chaque fichier possède le même nombre de ligne et de colonnes.
Le temps de calcul devient vite grand lorsque j'augmente N (nombre de domaines). Il faut ensuite que j'aille sur un cluster et utiliser MPI. Le hic : je ne suis pas tout seul sur le cluster.
Donc j'ai préféré utiliser peu de domaines (N = 5) et le faire sur ma machine en parallèle sur mes 4 processeurs avec les pthreads.

[Ti-R]

Oui 5 c'est trop peu, et surtout, il faudrait faire des mesures sans calculs en parallèle !