Pouvez-vous allouer un très gros bloc de mémoire (> 4 Go) en c ou en c ++?

Question

Avec de très grandes quantités de RAM ces jours-ci, je me demandais, est-il possible d’allouer une seule tranche de mémoire supérieure à 4 Go? Ou aurais-je besoin d'allouer un tas de petits morceaux et de gérer la commutation entre eux?

Pourquoi ??? Je travaille sur le traitement de certaines données XML openstreetmap et ces fichiers sont énormes. Je les diffuse actuellement car je ne peux pas les charger tous en un seul morceau, mais je suis curieux de savoir quelle est la limite supérieure de Malloc ou du nouveau.

Answer 1

Réponse courte: Peu probable

Pour que cela fonctionne, vous devez utiliser un processeur 64 bits. Deuxièmement, cela dépend du support du système d’exploitation pour allouer plus de 4 Go de RAM à un seul processus.

En théorie, cela serait possible, mais vous devriez lire la documentation de l’allocateur de mémoire. Vous seriez également plus susceptible aux problèmes de fragmentation de la mémoire.

Il existe de bonnes informations sur la gestion de la mémoire Windows .

Answer 2

Notions de base sur les dispositions de mémoire physique et virtuelle

Il vous faudrait un processeur 64 bits et une version système d'exploitation ainsi que suffisamment de mémoire pour éviter de gommer votre jeu de travail. Un peu de contexte:

Une machine 32 bits (en gros) possède des registres pouvant stocker l’une des 2 ^ 32 (4 294 967 296) valeurs uniques. Cela signifie qu'un pointeur 32 bits peut adresser n'importe lequel des 2 ^ 32 emplacements de mémoire uniques, d'où provient la limite magique de 4 Go.

Certains systèmes 32 bits tels que SPARCV8 ou Xeon ont des MMU qui permettent d’utiliser plus de mémoire physique. Cela permet à plusieurs processus d’occuper une quantité de mémoire totale supérieure à 4 Go, mais chaque processus est limité à son propre espace d’adresse virtuelle 32 bits. Pour un processus unique examinant un espace d'adressage virtuel, seuls 2 ^ 32 emplacements physiques distincts peuvent être mappés par un pointeur 32 bits.

Je n'entrerai pas dans les détails, mais Cette présentation (avertissement: PowerPoint) décrit comment cela fonctionne. Certains systèmes d'exploitation disposent d'installations (telles que celles décrites ici - grâce à FP ci-dessus) pour manipuler la MMU et échanger différents emplacements physiques dans l'espace d'adressage virtuel sous le contrôle de l'utilisateur.

Le système d'exploitation et les E / S mappés en mémoire occuperont une partie de l'espace d'adressage virtuel. Par conséquent, la totalité de ces 4 Go n'est pas nécessairement disponible pour le processus. Par exemple, Windows utilise par défaut 2 Go de ce nombre, mais peut être défini pour ne prendre que 1 Go si le commutateur / 3G est appelé au démarrage. Cela signifie qu'un processus unique sur une architecture 32 bits de ce type ne peut construire qu'une structure de données contiguës d'un peu moins de 4 Go en mémoire.

Cela signifie que vous devrez explicitement utiliser PAE installations sur Windows ou Installations équivalentes sous Linux basculer manuellement dans les calques. Ce n’est pas forcément si difficile, mais il faudra un certain temps pour commencer à travailler.

Sinon, vous pouvez obtenir une boîte 64 bits avec beaucoup de mémoire et ces problèmes disparaissent plus ou moins. Une architecture 64 bits avec des pointeurs 64 bits peut créer une structure de données contiguë comportant jusqu'à 2 ^ 64 (18 446 744 073 709 551 616) adresses uniques, du moins en théorie. Cela permet de créer et de gérer des structures de données contiguës plus grandes.

Answer 3

L'avantage des fichiers mappés en mémoire est que vous pouvez ouvrir un fichier beaucoup plus gros que 4 Go (presque infini sur NTFS!) et y insérer plusieurs fenêtres de mémoire < 4 Go.
C'est beaucoup plus efficace que d'ouvrir un fichier et de le lire en mémoire. Sur la plupart des systèmes d'exploitation, il utilise le support de pagination intégré.

Answer 4

Cela ne devrait pas poser de problème avec un système d’exploitation 64 bits (et un ordinateur disposant de beaucoup de mémoire).

Si malloc n’arrive pas à s’en sortir, le système d’exploitation fournira certainement des API permettant d’allouer directement de la mémoire. Sous Windows, vous pouvez utiliser l'API VirtualAlloc .

Answer 5

Cela dépend du compilateur C que vous utilisez et de la plate-forme (bien sûr), mais il n’ya aucune raison fondamentale pour laquelle vous ne pouvez pas allouer la plus grande partie de la mémoire disponible contiguë, ce qui peut être inférieur à vos besoins. Et bien sûr, vous devrez peut-être utiliser un système 64 bits pour adresser plus de RAM ...

voir Malloc pour l'historique et les détails

appelez HeapMax dans alloc.h pour obtenir la plus grande taille de bloc disponible

Answer 6

Avez-vous envisagé d’utiliser des fichiers mappés en mémoire? Puisque vous chargez des fichiers vraiment volumineux, il semblerait que ce soit la meilleure solution.

Answer 7

Cela dépend si le système d'exploitation vous fournira un espace d'adressage virtuel permettant d'adresser de la mémoire au-dessus de 4 Go et si le compilateur prend en charge son allocation à l'aide du nouveau / malloc.

Sous Windows 32 bits, vous ne pourrez pas obtenir un seul bloc supérieur à 4 Go, car la taille du pointeur est 32 bits, ce qui limite votre espace d'adressage virtuel à 4 Go. (Vous pouvez utiliser la extension d'adresse physique pour en obtenir davantage. 4 Go de mémoire; cependant, je pense que vous devez mapper vous-même cette mémoire dans l’espace d’adresse virtuelle de 4 Go)

Pour Windows 64 bits, le compilateur VC ++ prend en charge les pointeurs 64 bits avec une limite théorique de l'espace d'adressage virtuel à 8 To.

Je soupçonne qu'il en va de même pour Linux / gcc: 32 bits ne vous le permettent pas, alors que 64 bits vous le permettent.

Answer 8

Comme l'a souligné Rob, VirtualAlloc pour Windows est une bonne option à cet effet, tout comme un mappage de fichiers anonyme. Cependant, en particulier en ce qui concerne votre question, la réponse à "si C ou C ++" peut attribuer, la réponse est NON, CE N'EST PAS SUPPORTÉ MÊME SUR WIN7 RC 64

Dans la spécification PE / COFF pour les fichiers exe, le champ spécifiant la réserve HEAP et la validation HEAP est une quantité de 32 bits. Cela correspond aux limites de taille physique de la mise en œuvre de segment de mémoire actuelle dans le tube cathodique de Windows, qui est juste en dessous de 4 Go. Il n’existe donc aucun moyen d’allouer plus de 4 Go à partir de C / C ++ (techniquement, les fonctions de support de système d’exploitation de CreateFileMapping et VirtualAlloc / VirtualAllocNuma, etc., ne sont pas C ou C ++).

Assurez-vous également AWARE qu'il existe des constructions ABI x86 ou amd64 sous-jacentes connues sous le nom de "tables de page". Cela DOIT effectivement faire ce qui vous intéresse, allouer des morceaux plus petits pour votre requête plus importante, même si cela se produit dans la mémoire du noyau, il y a un effet sur le système global, ces tables sont finies.

Si vous allouez de la mémoire dans de tels domaines, vous feriez bien d'allouer en fonction de la granularité de l'allocation (ce que VirtualAlloc applique) et également d'identifier des indicateurs facultatifs ou des méthodes permettant d'activer des pages plus volumineuses.

4 Ko pages étaient la taille de page initiale pour le 386, puis le Pentium ajouté 4 Mo. Aujourd’hui, le AMD64 (Guide d'optimisation logicielle pour AMD Famille 10h) a une taille d’entrée de table de page maximale de 1 Go. Cela signifie pour votre cas ici, disons que vous venez de faire 4 Go, il ne faudrait que 4 entrées uniques dans le répertoire du noyau pour localiser \ assigner et autoriser la mémoire de votre processus.

Microsoft a également publié ce manuel qui présente certains des aspects les plus fins de la mémoire d’application et son utilisation pour la plate-forme Vista / 2008 et plus récente.

Table des matières

Introduction. 4

À propos du gestionnaire de mémoire 4

Espace d'adressage virtuel. 5

Allocation dynamique du noyau virtuel Espace d'adressage. 5

Détails pour les architectures x86. 6

Détails pour les architectures 64 bits. 7

Saut de pile en mode noyau dans x86 Architectures. 7

Utilisation de la mémoire de réserve excédentaire. 8

Sécurité: Disposition d'espace d'adressage Randomisation. 9

Effet de ASLR sur le chargement d'image Adresses. 9

Avantages de l'ASLR .. 11

Comment créer dynamiquement basé Images. 11

Bande passante d'E / S. 11

Microsoft SuperFetch. 12

Écriture de fichier de page. 12

Coordination du gestionnaire de mémoire et Gestionnaire de cache 13

Clustering de style Prefetch. 14

Gestion des fichiers volumineux 15

Veille prolongée et veille. 16

Modèle vidéo avancé 16

NUMA Support 17

Allocation de ressources. 17

Noeud par défaut et affinité. 18

Interrompre l'affinité. 19

Fonctions du système NUMA-Aware pour Applications. 19

Fonctions du système NUMA-Aware pour Pilotes 19

Pagination. 20

Evolutivité. 20

Efficacité et parallélisme .. 20

Numéro de page-image et base de données PFN. 20

Grandes pages. 21

Allocation de pool alignée sur le cache. 21

Machines virtuelles. 22

L'équilibrage de charge. 22

Optimisations supplémentaires. 23

Intégrité du système. 23

Diagnostic des erreurs matérielles. 23

Intégrité du code et signature du pilote. 24

Préservation des données lors de la vérification des bogues. 24

Ce que tu devrais faire. 24

Pour les fabricants de matériel. 24

Pour les développeurs de pilotes. 24

Pour les développeurs d'applications. 25

Pour les administrateurs système. 25

Ressources. 25

Answer 9

Si size_t est supérieur à 32 bits sur votre système, vous avez franchi le premier obstacle. Mais les normes C et C ++ ne permettent pas de déterminer si un appel particulier à new ou malloc aboutit (à l'exception de malloc de taille 0). Cela dépend entièrement du système d'exploitation et de l'état actuel du tas.

Answer 10

Comme tout le monde l’a dit, obtenir un ordinateur 64 bits est la voie à suivre. Mais même sur une machine Intel 32 bits, vous pouvez traiter des zones de mémoire supérieures à 4 Go si votre système d’exploitation et votre processeur prennent en charge > PAE . Malheureusement, WinXP 32 bits ne le fait pas (Vista 32 bits??). Linux vous permet de le faire par défaut, mais vous serez limité à 4 Go, même avec mmap () car les pointeurs sont toujours en 32 bits.

Ce que vous devriez faire cependant est de laisser le système d’exploitation se charger de la gestion de la mémoire pour vous. Installez un environnement capable de gérer autant de mémoire vive, puis lisez le ou les fichiers XML dans une ou plusieurs structures de données, puis laissez-le vous allouer de l'espace. Puis opérez sur la structure de données en mémoire, au lieu d’opérer sur le fichier XML lui-même.

Même dans les systèmes 64 bits, vous n'aurez pas beaucoup de contrôle sur les parties de votre programme qui se trouvent réellement dans la RAM, dans le cache ou sur le disque, du moins dans la plupart des cas, car le MMU s'en occupe lui-même.