Discussion :

[uriotcea]

Bonjour,

J'ecrit de gros fichiers binaires (qq 10GO) avec les fonctions classique fopen, fwrite...
J'ai remarqué un gros gain en vitesse significatif (30%°, en augmentant la taille du buffer en utilisant la fonction
setvbuf(f,NULL,_IOFBF,262144)

Comment ajuster la taille du buffer, y a t-il une limite, et quel est le risque.

merci de vos suggestions

[Neckara]

Bonjour,

Mes connaissances ne sont pas parfaites sur le sujet, donc il est possible que je me trompe ou que j'ignore certains aspect du problème.

Le principe du buffer est de diminuer les accès au disque en stockant les données à écrire dans le buffer et à les écrire quand le buffer est plein.

Ainsi si on veut écrire 20 octets, au lieu d'accéder 20 fois au disque pour écrire à chaque fois 1 seul octet, on y accède une seule fois pour écrire 20 octets.

Il faut aussi savoir que l'ordinateur ne sait pas écrire (et lire) un seul octet sur le disque (?), il va réécrire tout le secteur qui peut faire 512kio par exemple.

La taille optimale de buffer est donc, je pense, la taille d'un secteur du disque lu (?). Pour la limite, il y en a obligatoirement une, mais je pense qu'elle est suffisamment grande pour qu'on ai pas à s'en soucier. Après, si la taille du buffer est supérieur à la taille d'un secteur (?) on ne gagnera rien.

Le seul risque que je verrais c'est de perdre en performances lors de la lecture ou le gaspillage de mémoire.

[Obsidian]

Le seul risque que je verrais c'est de perdre en performances lors de la lecture ou le gaspillage de mémoire.

Si l'on veut vraiment chipoter, on peut ajouter le fait que plus de données risquent d'être perdues en cas de crash de la machine ou de plantage du programme. 262144 octets, ça fait quand même 256 Kio.

Cela dit, c'est difficile de mesurer cela car il faut les mettre en balance avec les mémoire cache utilisées par le système d'exploitation ainsi que par le disque dur lui-même. Donc, c'est au cas par cas, et en examinant également ce que fait le programme.

[uriotcea]

Merci de vos remarques.
Effectivement ca dépend bien systeme. Aucun effet observé sur Linux à contrario de windows.

[Metalman]

Lors de la lecture de ton fichier avec fread et l'écriture avec fwrite...
Le seul conseil précis et supplémentaire (les précédents sont déjà très bons) :
Evite d'avoir un buffer malloqué/free tout le temps !

Garde bien un "char buf[BUF_LEN]" en variable qui sera du coup alloué en "dur" dans l'exécutable, et t'évitera de faire trop d'appels à malloc... (c'est la méthode qui était utilisée il y a très très très longtemps pour les traitements répétitifs).
Si tu fais un seul malloc au tout début, c'est pas gênant.

[uriotcea]

peux-tu etre plus explicite à propos de ton buffer de char. Pour ma part je lis des doubles

[Metalman]

Outch... lire des doubles est peut être risqué car considérés comme nombres signés (et même flottants)... donc tu "peux" avoir des traitements FPU nécessaires pour rien (et ceux là sont les plus lourds de tous).
Donc pas de traitement de chaînes de caractères possibles (si on respecte strictement le typage)...

Même si tu lis en binaire, ton fichier est constitué de caractères (char sur UNIX/Linux et _tchar sur Windows pour être "indépendant" de l'encodage choisit à la compilation), donc un tableau de char/_tchar est logique !

Il n'y a pas de code, mais cela m'intéresse de voir comment et pourquoi tu lis des "double" quand il s'agit d'écrire des fichiers, de plusieurs Go qui plus est !

[uriotcea]

En fait c'est un peu plus complexe, j'écris des float à partir de donnée d'un énorme tableau de double (quelques GO, voir 10GO). Mais sinon c'est trivial !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
float cor3[7];
// ipt peut valoir plusieur millards
      for (i=0;i<ipt;i++) {
        cor3[0]=(float)cord[i*6];
        cor3[1]=(float)cord[i*6+1];
        cor3[2]=(float)cord[i*6+2];
        cor3[3]=(float)cord[i*6+3];
        cor3[4]=(float)cord[i*6+4];
        cor3[5]=(float)cord[i*6+5];
        cor3[6]=(float)loss[i];
        fwrite(&cor3,sizeof(float),7,f0);
     }

[Obsidian]

En fait c'est un peu plus complexe, j'écris des float à partir de donnée d'un énorme tableau de double (quelques GO, voir 10GO). Mais sinon c'est trivial !

As-tu envisagé mmap() ?

[uriotcea]

Non, mais pour avoir déjà regardé ca, j'avoue que cela m'apparait un peu obscur. Aurais-tu un example simple?

[Metalman]

Hmmmm... et je suppose qu'il y a un read sur le même fichier plus tard pour reconstruire le tableau ?

Cela implique d'énormes problèmes si on ne reste pas sur la même architecture... voire la même machine avec le même OS !
Je m'explique : vous devez connaitre le principe d'endianess (comment représenter les poids forts des poids faibles).
Si jamais vous envoyez un fichier écrit par un système big endian vers un système little endian, vous risquez d'avoir des valeurs totalement différentes...
C'est une des raisons pour le fameux itoa/atoi et plus techniquement en réseau : hton et ntoh.

Tant que cela reste sur les mêmes machines ça va, mais sinon, il faudrait convertir chaque ligne du tableau en ascii, puis écrire l'ascii... et faire l'inverse de l'autre côté.

[uriotcea]

Oui il a un read, mais dans un autre code. Et finallement, l'ecriture et la lecture sont nécessairement sur la même machine.

[Metalman]

Je pencherai pour un :

Code :

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

1
2
3
4
5
6
7
8
 
float *tab = NULL;
int fd;
 
fd = open("myfile.txt");
tab = mmap(NULL, size de votre float, PROT_READ, MAP_PRIVATE, fd, 0);
/* MAP_PRIVATE ne partagera avec aucun fork ou thread si j'ai bien compris */
/* 0 indique que le tableau démarre dès le 1er caractère du fichier */

EDIT : Mais du coup, ma remarque du buffer de char est inutile !

[Obsidian]

Non, mais pour avoir déjà regardé ca, j'avoue que cela m'apparait un peu obscur. Aurais-tu un example simple?

Pas sous le coude (il faudrait en écrire un) mais le principe est assez simple : mmap() projette le contenu d'un fichier en mémoire.

Pour ce faire, le système va utiliser les mécanismes de la mémoire virtuelle : il va te faire croire que le fichier est entièrement chargé en mémoire et va ne charger les pages nécessaires que lorsque tu essaieras d'y accéder. Par contre, pour toi, ce sera complètement transparent. Tu pourras considérer ton fichier comme entièrement chargé en mémoire et te passer complètement d'appels aux I/O. Et l'avantage, c'est que ça fonctionne dans les deux sens (en écriture comme en lecture).

Ce n'est pas spécialement pratique pour les fichiers texte (il faut retrouver soi-même la chaîne et son délimiteur) mais c'est idéal pour les fichiers binaires, puisque tu n'as qu'à les écrire naturellement en mémoire plutôt que faire des write de la taille d'un double ou d'un float.

Ça veut dire également que tu délègues au système la tâche de gérer les transferts entre le disque et la mémoire et que tu le laisses donc choisir la taille optimale de ses buffers, et tu lui permets d'organiser son travail en fonction de la charge des autres processus.

Le seul inconvénient du mapping de fichier est que, par nature, le fichier doit pouvoir être mappé, ce qui lui impose en pratique d'être un fichier régulier sur un disque ou assimilé. Tu ne pourrais pas traiter l'entrée standard de cette façon, par exemple, ni renvoyer la sortie vers un tube nommé ou autres artifices.

[uriotcea]

Merci de l'example mais qui génére systéméatiquement à la compilation "Invalide conversion void* to float*

Cela dit, j'ai fais quelques recherches sur le web et j'ai trouvé des example plus complet mais sur le même format et qui génére aussi la même erreur.

Là je suis sec

[Metalman]

Euuuuh...
Et avec ce compilateur, si vous tapez simplement :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
#include <unistd.h>
#include <stdlib.h>
 
int maint(void)
{
  float *test;
 
  test = malloc(sizeof (float));
  return (0);
}

Ca compile ?.... parce que ça fait très très bizarre X_x

EDIT : avec quel compilo compilez-vous vos programmes ?

[dragonno]

Salut,
Je n'ai jamais utilisé l'assembleur avec le C mais si cela peut t'aider il y a une instruction d'écriture de bloc binaires en assembleur, et idem en lecture, qui permettent d'écrire/lire les données en bloc et non une à une.
Ah pardon je suis à coté de la plaque, je m'en vais dormir

[uriotcea]

gcc, ok j'ai trouvé il faut même (float *) devant mmap

[Metalman]

Bizarre de devoir faire un cast explicite avec du void*...

gcc avec des flags spéciaux ?

Mais si ça fonctionne, c'est déjà positif...

[ram-0000]

gcc, ok j'ai trouvé il faut même (float *) devant mmap

Bizarre de devoir faire un cast explicite avec du void*...

Normal, un pointeur sur n'importe quoi peut se transformer automatiquement en void *

Par contre, l'inverse n'est pas vrai, un pointeur void * (le retour de mmap) doit est casté explicitement en pointeur sur objet.