Buffer, fichier, read et fread

Buffer, fichier, read et fread - C++ - Programmation

Marsh Posté le 18-06-2003 à 19:00:56    

Salut,
 
Une question pratique à deux balles. Je suis un train d'écrire un système de lecture/ecriture trés bas niveau (faut gérer un système de recovery pour une application critique) et j'hésite entre utiliser directement:

  • read/write (pas de buffer)
  • ou fread/fwrite (stream, buffer)


J'étais joyeusement parti sur read/write, en recréant un buffer quand je me suis aperçu que fread/fwrite avait mon buffer! Mais comme je cherche un code clean et optimisé pour mon utilisation, j'aimerais savoir de quel buffer on parle:
1) c'est juste un buffer pour regrouper les commandes?
2) le buffer est intelligent et si j'écris le code dessous, il n'ira pas faire d'accés disque pour le lire le contenu mais il s'apercevra qu'il a déjà ce que je lui demande dans son buffer?

Code :
  1. FILE f = fopen("...", ".." );
  2. Page MyPageSave = new Page(...);
  3. Page MyPageLoad;
  4. fwrite((void*)MyPageSave, sizeof(MyPageSave), 1, f);
  5. fseek(f, -sizeof(MyPageSave), 0);          // Retour au début de l'enregistrement précédent
  6. fread((void*)MyPageLoad, sizeof(MyPageLoad), 1, f);


(désolé pour les erreurs de code, c'est juste l'idée qui compte)
 
Merci de vos éclaircissements!


---------------
Horizon pas Net, reste à la buvette!!
Reply

Marsh Posté le 18-06-2003 à 19:00:56   

Reply

Marsh Posté le 18-06-2003 à 19:27:22    

Mais j'y pense read/write n'est pas standardisé??? Ca fait du vieux standard Unix C...


---------------
Horizon pas Net, reste à la buvette!!
Reply

Marsh Posté le 18-06-2003 à 22:14:44    

et faire du C++, ça te dit? si oui laisse tombr tes cast à la con, et utilise les std::fstream

Reply

Marsh Posté le 18-06-2003 à 23:06:13    

++Taz a écrit :

et faire du C++, ça te dit? si oui laisse tombr tes cast à la con, et utilise les std::fstream


 
Tiens j'y avais pas pense :D Les fstream (sur lesquels on a aucun controle) pour gerer un systeme de recovery, c'est tres moyen!
Cela dit, si les fstream se comportent comme mon 2), j'achete...

Reply

Marsh Posté le 18-06-2003 à 23:23:37    

ben heureusement que les fstream sont buferrises!!!!

Reply

Marsh Posté le 18-06-2003 à 23:57:38    

++Taz a écrit :

ben heureusement que les fstream sont buferrises!!!!


 
Pareil? ils gerent un systeme de page/cluster et on pas besoin d'aller charger une page sur le disque s'ils l'ont deja charge?
 
Oh putain, la revelation :ouch:, toujours utilises sans me soucier du buffer (j'avais pas de prb de perf!)
 
Edit: Ben oui, je viens de me taper la specification...monstrueux!!


Message édité par Willyzekid le 19-06-2003 à 00:00:50
Reply

Marsh Posté le 19-06-2003 à 00:06:59    

t'es completement à la masse toi... tu débarques d'ou?

Reply

Marsh Posté le 19-06-2003 à 00:17:16    

ouais mais regarde son nom, le gars c'est willyzekid quoi

Reply

Marsh Posté le 19-06-2003 à 06:11:06    

++Taz a écrit :

t'es completement à la masse toi... tu débarques d'ou?


 
Cela dit, ca me donne pas beaucoup (suffisament?) de contrôle sur le buffer. Pour l'algorithme ARIES, il faut au minimum (!) que je sache ce qui est commited et ce qui ne l'ai pas. Or même en héritant de basic_filebuf et en le passant à mon fstream, je suis même pas sûr de pouvoir obtenir cette info.


---------------
Horizon pas Net, reste à la buvette!!
Reply

Marsh Posté le 19-06-2003 à 07:50:12    

ben de toutes façon aucun système te donnera cette assurance. si tu veux avoir un controle tres precis, sous linux par exemple, ben si tu recuperes le descripteur de fichier, tu peux faire ce que tu veux. tu peux aussi dimensionner la taille du buffer à ta guise. maintenant, je crois que t'as interet à utiliser une version standard bufferisé, par ce que je te sens pas du tout faire ta propre version

Reply

Marsh Posté le 19-06-2003 à 07:50:12   

Reply

Marsh Posté le 19-06-2003 à 14:43:45    

++Taz a écrit :

ben de toutes façon aucun système te donnera cette assurance. si tu veux avoir un controle tres precis, sous linux par exemple, ben si tu recuperes le descripteur de fichier, tu peux faire ce que tu veux. (...)


 
Le buffer est construit/géré par la STL ou la STL ne fait que reprendre le buffer et la stratégie de l'OS? Et quid de fwrite/fread?
 
Sinon existe-t-il une fonction (standardisé, on peut réver) qui permet d'accéder aux fichiers sans buffer?


---------------
Horizon pas Net, reste à la buvette!!
Reply

Marsh Posté le 19-06-2003 à 14:49:19    

ben tout dépend... de l'implémentation... tu peux meme avoir de fstream basé sur les FILE*. pour les acces non bufferisés fo voir avec ton OS. moi j'utiliserai sans crainte les fonctions standard bufferisés par ce que les performances n'ont un peu rien à voir.

Reply

Marsh Posté le 19-06-2003 à 16:57:18    

Bon, c'est pas la joie....Je vais effectivement utiliser la STL dans un premier temps. Et peut-être créer un système de buffer autour de système call basiques si les inconvenients de la STL l'emportent sur le bordel que c'est d'écrire un truc portable et efficace (!!!!)
 
Dans l'état, je vois deux problèmes de la STL (j'indique l'état de mes recherche pour monter un peu le niveau de ce topic :D et pour aider d'autres personnes qui passeraient par là).

  • Toujours le problème de système de recupération de crash ingérable sans accés aux flags du buffer.
  • Je gére de gros fichiers (type database) sur Win et Linux. La STL et FILE* (sur laquelle l'implémentation Windows de la STL repose) utilisent la stratégie du LRU (Least Recently Used) pour gérer le cache. Or c'est pas bon pour gérer des gros fichiers qui peuvent être lu séquentiellement. Avec un fichier de 10000 records parcourus 2 fois séquentiellement, avec 50ms d'overhead par record passé a un buffer contenant 1000 records, on a 100 000ms d'overhead du au buffer dans le cas de la LRU (a chaque lecture, on a une ecriture dans le buffer). Avec la MRU (Most Recently Used), on a (2*(10000-1000)+1000)*50=95000 seulement (au deuxième parcours du fichier, on a déjà 1000 records en mémoire). Soit 5% de perf en plus...Est-ce que ca vaut le coup de se faire chier pour 5%?


A titre d'info, voici une comparaison intéressante entre les différents moyen d'accés / librairies :
http://www.cs.utk.edu/~plank/plank [...] cture.html
 
Edit: pour rendre ce post un peu plus clair


Message édité par Willyzekid le 19-06-2003 à 17:00:07

---------------
Horizon pas Net, reste à la buvette!!
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed