Classes de conteneur STL sauvegardées sur disque? [fermé]

Question

J'aime développer des algorithmes à l'aide de la STL, cependant, j'ai ce problème récurrent où mes ensembles de données sont trop volumineux pour le tas.

Je recherchais des remplacements directs pour les conteneurs STL et les algorithmes sauvegardés sur disque, c’est-à-dire les structures de données stockées sur le disque plutôt que le tas.

Un ami m'a récemment dirigé vers stxxl . Avant que je ne m'implique trop ... Existe-t-il d'autres solutions de remplacement STL sur disque que je devrais envisager?

REMARQUE: la persistance ou les bases de données incorporées ne m'intéressent pas. Veuillez ne pas mentionner boost :: serialization, POST ++, bibliothèque de modèles relationnels, Berkeley DB, sqlite, etc. Je suis au courant de ces projets et les utilise lorsqu'ils conviennent à mes besoins.

UPDATE: Plusieurs personnes ont mentionné les fichiers de mappage de mémoire et l'utilisation d'un allocateur personnalisé, de bonnes suggestions BTW, mais je les dirigerais vers la discussion ici où David Abraham suggère que des itérateurs personnalisés soient nécessaires pour les conteneurs sauvegardés sur disque. Cela signifie que l'approche d'allocateur personnalisé ne fonctionnera probablement pas.

Answer 1

J'ai mis en place quelque chose de très similaire. La mise en œuvre des itérateurs est la plus difficile. J'ai utilisé boost :: iterator_facade . pour implémenter les itérateurs. En utilisant boost :: iterator_facade , vous pouvez adapter facilement les éléments mis en cache sur les structures de données sur disque afin de disposer d'une interface de conteneur STL.

Answer 2

Je n'ai jamais eu à faire quoi que ce soit de la sorte, mais vous pouvez éventuellement faire ce que vous voulez en écrivant un allocateur personnalisé qui utilise un fichier mappé en mémoire pour sauvegarder vos données.

Voir boost :: interprocesses pour les documents sur leur implémentation facile à utiliser des fichiers mappés en mémoire, cet article de Dr. Dobbs pour une discussion détaillée sur l'écriture des allocateurs, et cette colonne du logiciel IEEE pour une description du problème et exemple de code .

Answer 3

Si vous ne vous intéressez pas à la persistance (au moment où vous écrivez), la solution la plus simple consisterait à augmenter la taille de votre segment de mémoire et à utiliser les fonctions de mémoire virtuelle de votre système d'exploitation. La partie du tas qui ne tiendra pas dans la mémoire physique de votre ordinateur finira par être paginée sur le disque, vous donnant exactement ce que vous voulez: un accès STL normal aux données souvent stockées sur le disque. Le système d'exploitation se chargera de mettre en cache les pages les plus utilisées dans la mémoire physique et d'expulser sur disque celles que vous n'utiliserez pas beaucoup. Votre code restera le même et vous pourrez augmenter ses performances en ajoutant simplement plus de mémoire physique.

Pour augmenter la taille de votre tas, vérifiez les paramètres de votre système d'exploitation, tels que ulimit (1) sous Unix et les propriétés système - Avancé - Performance - Avancé - Mémoire virtuelle sous Windows XP. Si vous avez atteint la limite de 4 Go en 32 bits, envisagez de passer à une architecture 64 bits ou en compilant votre programme pour 64 bits.

Answer 4

Je ne connais pas grand chose à ce sujet, mais il serait peut-être possible d'écrire une interface de type STL dans un fichier mappé en mémoire?

edit: Cette approche peut convenir si vous essayez d’obtenir une partie spécifique d’un fichier volumineux. Si vous essayez d'utiliser quelque chose avec le fichier entier, vous allez probablement générer un grand nombre de défauts de page en lisant des parties non mises en cache du fichier.