2012-02-13 4 views
3

Vous devez utiliser un tableau de 10^10 entiers de 4 octets comme table de correspondance. Le chargement en RAM prend 40 Go, ce qui n'est pas faisable. Vous n'avez jamais besoin d'écrire dans ce tableau après son initialisation. Vous devez lire des valeurs entières individuelles à partir d'emplacements aléatoires de ce tableau simultanément à partir de plusieurs threads d'un même processus. Vous avez la garantie d'être sur une plate-forme 64 bits. Quelle est la mise en œuvre la plus rapide de cette table de consultation? En utilisant des fonctions de lecture de fichiers régulières ou par ex. Boost fichier mappé en mémoire?Table de correspondance basée sur les fichiers

+0

Qu'est-ce que ce tableau est supposé stocker/faire? –

+0

Pour l'accès aléatoire, je suppose que les flux réguliers IO. La mémoire mappée n'aide pas beaucoup s'il n'y a pas de modèle d'accès et qu'elle ne rentre pas (principalement) dans la RAM (à ma connaissance). –

+0

@Jim Fell: Le tableau est utilisé pour mapper la valeur d'indexation x à f (x), où f est une fonction très lente, donc il ne peut pas être utilisé au moment de l'exécution. – zeroes00

Répondre

1

Il semble que vous devriez faire des lectures explicites.

Le mappage de mémoire tire sa vitesse d'apporter de gros morceaux de pages à la fois (je crois que Windows fait 256KiB, pas sûr sur les autres plateformes) et vous permet de les ré-accéder sans pénalité après la première fois. Si vous lisez simplement des entiers à partir d'emplacements aléatoires, vous lirez 256 Ko pour seulement 4 octets sur une page, et peut-être même jamais y accéder à nouveau. Quel gâchis! Considérez également que vous avez également paginé beaucoup de données peut-être utiles à partir d'autres applications et le cache du système de fichiers.

1

Depuis qu'une fois le fichier est créé, vous avez seulement besoin d'y accéder en lecture seule, je ne pense pas que vous voulez le coût d'un fichier mappé en mémoire, Boost ou autrement. Cela serait plus utile si vous aviez plusieurs processus qui voulaient accéder simultanément aux mêmes données. Dans votre cas, vous n'avez que des threads en lecture seule, donc un simple fichier 40g devrait être le plus simple et le plus rapide.

Questions connexes