Type de fonction système derrière un fstream.read()

Version imprimable

28/06/2010, 14h37
Matthieu Brucher

Type de fonction système derrière un fstream.read()

Hello à tous,

D'après certaines documentations, la fonction ifstream.read() lit un bloc de données. Or, il s'avère que mon code qui se base sur cette fonction passerait par des mmap(), ce qui a dans mon cas des performances déplorables.

Y a-t-il moyen de savoir comment les bibliothèques système sont implémentées à ce niveau ? Et est-il possible de forcer leur comportement ?
28/06/2010, 16h21
Arzar

Salut,

Je ne connais pas l'implémentation linuxienne par contre j'ai inspecté il y a quelques temps l'implémentation de la bibliothèque standard IOstream fournie avec Visual Studio 2010 (donc basée sur celle de Dinkumware), ce qui permet au moins de faire un parallèle...

En résumé, c'est à dire en omettant de nombreux appels de fonctions intermédiaires on a :

Constructeur de ifstream (quel que soit le mode)
Appelle fopen()
Qui appelle CreateFile()

Lecture (que ce soit par un std::getline ou par la fonction membre read())
Appelle fgetc()
Qui appelle Readfile() (qui lit par bloc de 4096 octets)

La biblio standard C de MSVC - et donc la biblio standard C++ - ne semble donc jamais utiliser de fichier mappé. Quel que soient les modes d'ouverture ou la manière de lire le fichier on finit toujours pas retomber sur de la lecture bufferisée avec CreateFile + ReadFile.

Donc pour répondre aux questions, sur Windows :

Citation:

Y a-t-il moyen de savoir comment les bibliothèques système sont implémentées à ce niveau ?

Ben perso, j'avais fait du debug en pas en pas dans les sources de la lib C et C++.

Citation:

Et est-il possible de forcer leur comportement ?

Je n'ai pas croisé de switch/define permettant de changer le comportement dans les sources.
28/06/2010, 16h39
Matthieu Brucher

On passe par un read de 4ko ?? C'est complètement débile !
Dans mon cas, je fais une demande de 18Mo environ, donc si ça passe par des 4ko, on n'a pas fini... Derrière, le serveur de fichier lit automatiquement par tranches de 8Mo. Comment mettre à la poubelle plus de 7.9Mo à la poubelle avec une implémentation débile (désolé, je suis sur les dents avec des conneries pareilles :D)

Merci pour l'info, j'imagine que Linux ne doit malheureusement pas être trop différent...
28/06/2010, 17h10
méphistopheles
je me souviens avoir fait des tests comparatif sur la vitesse de lecture d'un fichier en mode
Code:

1 2 while (file>>a>>b>>c) [...]
et j'avais un facteur 10 entre le sdk de visualC++2005 et gcc (je me rapelle plus le numéro de version). (gcc plus rapide)

D'un autre coté, ça reste quand même tres lent, et je ne sais plus ou j'avais lu que les flux de la stl étaient mal implémentés... donc mieux vaut peut-être prendre une fonction spécialisée.
Sinon, il me semble que ce chapitre du méga cours de C++ décris en détail l'implémentation des flux dans la stl. Je l'avais parcouru, mais j'avoue que cela m'est quelque-peu sorti de la tête:roll:

bonne chance ;)

Citation:

Envoyé par Matthieu Brucher

On passe par un read de 4ko ?? C'est complètement débile !
Dans mon cas, je fais une demande de 18Mo environ, donc si ça passe par des 4ko, on n'a pas fini... Derrière, le serveur de fichier lit automatiquement par tranches de 8Mo. Comment mettre à la poubelle plus de 7.9Mo à la poubelle avec une implémentation débile (désolé, je suis sur les dents avec des conneries pareilles :D)

En creusant un peu, je me suis rendu compte que l'on pouvait changer la taille du buffer de lecture :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include <fstream> int main() { // file.dat est un fichier de plusieurs dizaines de Mo. std::ifstream file("file.dat", std::ios::binary); std::filebuf* fbuf = file.rdbuf(); fbuf->pubsetbuf(NULL, 8192); char* buffer = new char[16384]; file.read(buffer, 16384); // 2 ReadFile }
Passer un pointeur nul et une taille à pubsetbuf indique au filebuf qu'il doit continuer à utiliser son buffer interne mais qu'il doit le redimensionner. Et au final pubsetbuf appelle setvbuf de la biblio standard C sur la stream C sous-jacente au filebuf. (Et setvbuf fait un free sur le buffer de la stream puis un malloc à la nouvelle taille).

Lors de la lecture on vérifie bien que ReadFile lit maintenant par bloc de 8192 au lieu du 4096 par défaut.

Maintenant, perso je ne sais pas du tout comment la lecture de fichier est géré au niveau système donc je n'ai pas la moindre idée si l'augmentation de la taille du buffer est bénéfique ou pas. :aie:
Faut tester.

Citation:

Envoyé par Arzar

Faut tester.

J'ai cédé à la curiosité :aie:

Le bench suivant, réalisé sous Windows 7 avec VS2010, lit un fichier "file.txt" de 32 Mo en tranches de 8 Mo, et ce de quatre manière différentes :
1) Avec un ifstream.read(). Le buffer de lecture par défaut est de 4096 octets.
2) avec un ifstream.read dont le buffer de lecture a été redimensionné à 8 Mo.
3) Avec la fonction native Win32 ReadFile()
4) Avec des fichiers mappés.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
#include <Windows.h>
#include <iostream>
#include <fstream>
#include <boost/iostreams/device/mapped_file.hpp>
 
const int NB_LOOP = 100;
const long long SIZE_BUFFER = 8388608; // 8mo
 
void foo1()
{
   char* buffer = new char[SIZE_BUFFER];
 
   for(int i = 0 ; i < NB_LOOP; i++)
   {
      std::ifstream file("file.txt", std::ios::binary);
      file.read(buffer, SIZE_BUFFER);	
      file.read(buffer, SIZE_BUFFER); 
      file.read(buffer, SIZE_BUFFER); 
      file.read(buffer, SIZE_BUFFER); 
      // 32 Mo
   }
}
 
void foo2()
{
   char* buffer = new char[SIZE_BUFFER]; 
   char* internal_buffer = new char[SIZE_BUFFER]; 
 
   for(int i = 0 ; i < NB_LOOP; i++)
   {
      std::ifstream file("file.txt", std::ios::binary);
      std::filebuf* fbuf = file.rdbuf();
      fbuf->pubsetbuf(internal_buffer, SIZE_BUFFER);
 
      file.read(buffer, SIZE_BUFFER);
      file.read(buffer, SIZE_BUFFER);	
      file.read(buffer, SIZE_BUFFER);	
      file.read(buffer, SIZE_BUFFER);	
      //32 Mo
   }
}
 
void foo3()
{
   char* buffer = new char[SIZE_BUFFER];
 
   for(int i = 0 ; i < NB_LOOP; i++)
   {
      DWORD nbByteRead;
      HANDLE h = CreateFile(L"file.txt", GENERIC_READ, NULL, NULL,  OPEN_EXISTING, NULL, NULL);
      ReadFile(h, buffer, SIZE_BUFFER, &nbByteRead, NULL);
      ReadFile(h, buffer, SIZE_BUFFER, &nbByteRead, NULL); 
      ReadFile(h, buffer, SIZE_BUFFER, &nbByteRead, NULL); 
      ReadFile(h, buffer, SIZE_BUFFER, &nbByteRead, NULL); 
      // 32 Mo
      CloseHandle(h);
   }
}
 
void foo4()
{
   char* buffer = new char[SIZE_BUFFER];
 
   for(int i = 0 ; i < NB_LOOP; i++)
   {
      boost::iostreams::mapped_file file("file.txt");
      memcpy(buffer, file.data() + 0 * SIZE_BUFFER, SIZE_BUFFER); 
      memcpy(buffer, file.data() + 1 * SIZE_BUFFER, SIZE_BUFFER);
      memcpy(buffer, file.data() + 2 * SIZE_BUFFER, SIZE_BUFFER);
      memcpy(buffer, file.data() + 3 * SIZE_BUFFER, SIZE_BUFFER);
      // 32 Mo
   }
}
 
int main()
{
   int begin = GetTickCount();
   foo1();
   int end = GetTickCount();
 
   std::cout << "ifstream default buffer (4096o) : " << end - begin << "\n";
 
   begin = GetTickCount();
   foo2();
   end = GetTickCount();
 
   std::cout << "ifstream custom buffer (8 Mo) : " << end - begin << "\n";
 
   begin = GetTickCount();
   foo3();
   end = GetTickCount();
 
   std::cout << "Win32 ReadFile (no buffer) : " << end - begin << "\n";
 
   begin = GetTickCount();
   foo4();
   end = GetTickCount();
 
   std::cout << "Mapped file (no buffer) : " << end - begin << "\n";
}

Et l'on obtient :
ifstream default buffer (4096o) : 5991
ifstream custom buffer (8 Mo) : 5444
Win32 ReadFile (no buffer) : 3229
Mapped file (no buffer) : 2980
(Ce sont des moyennes, car les timings fluctuent beaucoup)

30/06/2010, 16h29
Matthieu Brucher

Merci pour l'info. C'est sans doute plus portable comme écriture, mais elle est bien plus complexe que le pread/pwrite sous Linux...
Disons que l'intérêt de charger les données dépend de l'application. Dans mon cas, j'utilise toute la donnée immédiatement, donc autant me la donner. Le système disque lit beaucoup plus de données que les 4k qui me sont retournés, et j'ai besoin du reste. Au lieu de faire des dizaines d'accès, autant qu'il n'en fasse qu'un seul ;)

je n'ai pas résisté et j'ai fait un test sur linux (netbook donc petit hardware).
le code porté est:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
#include <iostream>
#include <fstream>
#include <time.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <boost/iostreams/device/mapped_file.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
 
const int NB_LOOP = 100;
const long long SIZE_BUFFER = 8388608; // 8mo
 
void foo1()
{
   char* buffer = new char[SIZE_BUFFER];
 
   for(int i = 0 ; i < NB_LOOP; i++)
   {
      std::ifstream file("file.txt", std::ios::binary);
      file.read(buffer, SIZE_BUFFER);
      file.read(buffer, SIZE_BUFFER);
      file.read(buffer, SIZE_BUFFER);
      file.read(buffer, SIZE_BUFFER);
      // 32 Mo
   }
}
 
void foo2()
{
   char* buffer = new char[SIZE_BUFFER];
   char* internal_buffer = new char[SIZE_BUFFER];
 
   for(int i = 0 ; i < NB_LOOP; i++)
   {
      std::ifstream file("file.txt", std::ios::binary);
      std::filebuf* fbuf = file.rdbuf();
      fbuf->pubsetbuf(internal_buffer, SIZE_BUFFER);
 
      file.read(buffer, SIZE_BUFFER);
      file.read(buffer, SIZE_BUFFER);
      file.read(buffer, SIZE_BUFFER);
      file.read(buffer, SIZE_BUFFER);
      //32 Mo
   }
}
 
void foo3()
{
   char* buffer = new char[SIZE_BUFFER];
 
 
   for(int i = 0 ; i < NB_LOOP; i++)
   {
      int fd=open("file.txt", O_RDONLY);
      off_t offset=0;
      pread(fd, buffer, SIZE_BUFFER, offset);
      offset+=SIZE_BUFFER;
      pread(fd, buffer, SIZE_BUFFER,  offset);
      offset+=SIZE_BUFFER;
      pread(fd, buffer, SIZE_BUFFER,  offset);
      offset+=SIZE_BUFFER;
      pread(fd, buffer, SIZE_BUFFER,  offset);
      offset+=SIZE_BUFFER;
      // 32 Mo
      close(fd);
   }
}
 
void foo4()
{
   char* buffer = new char[SIZE_BUFFER];
 
   for(int i = 0 ; i < NB_LOOP; i++)
   {
      boost::iostreams::mapped_file file("file.txt");
      memcpy(buffer, file.data() + 0 * SIZE_BUFFER, SIZE_BUFFER);
      memcpy(buffer, file.data() + 1 * SIZE_BUFFER, SIZE_BUFFER);
      memcpy(buffer, file.data() + 2 * SIZE_BUFFER, SIZE_BUFFER);
      memcpy(buffer, file.data() + 3 * SIZE_BUFFER, SIZE_BUFFER);
      // 32 Mo
   }
}
 
int main()
{
   boost::posix_time::ptime begin(
    boost::posix_time::microsec_clock::local_time());
   foo1();
   boost::posix_time::ptime end(
    boost::posix_time::microsec_clock::local_time());
   boost::posix_time::time_period duration(begin ,end);
   std::cout << "ifstream default buffer (4096o) : " <<
    duration.length().total_milliseconds() << "\n";
 
   begin = boost::posix_time::microsec_clock::local_time();
   foo2();
   end = boost::posix_time::microsec_clock::local_time();
   duration=boost::posix_time::time_period(begin ,end);
   std::cout << "ifstream custom buffer (8 Mo) : " <<
    duration.length().total_milliseconds() << "\n";
 
   begin = boost::posix_time::microsec_clock::local_time();
   foo3();
   end = boost::posix_time::microsec_clock::local_time();
   duration=boost::posix_time::time_period(begin ,end);
   std::cout << "unix ReadFile (no buffer) : " <<
    duration.length().total_milliseconds() << "\n";
 
   begin = boost::posix_time::microsec_clock::local_time();
   foo4();
   end = boost::posix_time::microsec_clock::local_time();
   duration=boost::posix_time::time_period(begin ,end);
   std::cout << "Mapped file (no buffer) : " <<
    duration.length().total_milliseconds() << "\n";
}

les résultats sont complètement différents:

Citation:

Envoyé par résultats en ms

ifstream default buffer (4096o) : 4999
ifstream custom buffer (8 Mo) : 4975
unix ReadFile (no buffer) : 4981
Mapped file (no buffer) : 6785

ici, peu de différence entre le ifstream et le pread ... peut-être que j'ai mal codé, mais j'opterais plutot pour une mauvaise implémentation vc++. Par contre boost se fait complètement manger... peut-être par-ce que je suis en -O3

faudrait faire des tests sur la même machine mais bon, la flemme de passer sous windows pour être sûr.

un troisième testeur ? :aie:

01/07/2010, 20h10
Arzar

AïeAïeAïe ça confirme bien ce que je craignais :

1) L'implémentation de fstream est à la ramasse sous Windows alors qu'elle est quasi optimale sous Linux (overhead très très faible par rapport à pread, pwrite)

2) Mais malheureusement les fichiers mappés, optimaux sous Windows (et qui peuvent être rendu portables et très élégants grâce à boost) sont à la ramasse sous Linux. Et ça ne vient pas de Boost je pense, car comme le dit Mathieu Brucher dans son premier post c'est les mmap qui sont à la traine sous Linux.

Donc finalement il n'y a pas de solution portable toute faite à l'heure actuelle qui choisit systématiquement l'implémentation la plus rapide. :cry:
01/07/2010, 20h36
méphistopheles

Citation:

Envoyé par Arzar

L'implémentation de fstream est à la ramasse sous Windows

Il me semble que dans ce cas, c'est le compilateur qui est à la ramasse non ? pas le système...

Un bon comparatif serait peut-être de tester ça avec mingwin.... :? un volontaire ?
01/07/2010, 23h37
Matthieu Brucher

Citation:

Envoyé par Arzar

1) L'implémentation de fstream est à la ramasse sous Windows alors qu'elle est quasi optimale sous Linux (overhead très très faible par rapport à pread, pwrite)

Ben non, dans mon application Linux, il s'avère que ce sont de mmap qui sont réalisés sur mes fichiers de 80Go :|
02/07/2010, 06h15
méphistopheles

Citation:

Envoyé par Matthieu Brucher

Ben non, dans mon application Linux, il s'avère que ce sont de mmap qui sont réalisés sur mes fichiers de 80Go :|

O_o tu veux dire dans la version foo1 ? sans qu'on modifie le buffer ?

sinon, tu a testé le programme ci-dessus pour voir si les résultats sont les mêmes ou si ce sont mes option de compilation qui font des problèmes ?
02/07/2010, 18h20
Matthieu Brucher

Après inspection avec un spécialiste, on a constaté que la bibliothèque standard C++ sous Linux faisait bien de gros accès de plusieurs Mo si demandé (strace -p sur le process), mais le problème est qu'on passe par un cache géré par le kernel (si j'ai bien compris), et le cache n'est pas libéré automatiquement, il y a donc du swap pendant un certain temps et en conséquence le kernel ne travaille que page par page. En passant par pread + posix_fadvise, on améliore un peu les choses (normalement, on peut spécifier qu'on ne veut pas conserver la page, mais elles restent encore en cache malgré tout).
02/07/2010, 18h22
méphistopheles

Citation:

Envoyé par Matthieu Brucher

En passant par pread + posix_fadvise, on améliore un peu les choses (normalement, on peut spécifier qu'on ne veut pas conserver la page, mais elles restent encore en cache malgré tout).

heu... ça donne quoi niveau implémentation (histoire de tester ...) ? :koi:
02/07/2010, 19h44
Matthieu Brucher

pread(fd, buffer, len, offset);
posix_fadvise(fd, offset, len, FADV_DONTNEED);
03/07/2010, 08h30
méphistopheles

Citation:

Envoyé par Matthieu Brucher

pread(fd, buffer, len, offset);
posix_fadvise(fd, offset, len, POSIX_FADV_DONTNEED);

heu... c'est bizarre, mais quand je remplace dans le foo3, la fonction bloque complétement (enfin j'ai arrêté après 15 secondes...) y'a un truc que je fais mal ?