Version imprimable
Salut,
J'ai besoin de charger en mémoire (allocation dynamique d'objets) un gros paquet de données. Au total la taille mémoire requise pour tous les objets doit dépasser le 2Go et apparemment c'est ça qui provoque le plantage de mon programme. Je voudrais savoir s'il existe un moyen de dépasser cette limite (option de compilation ou autre).
Je suis sous windows avec visual C++ au cas ou ça aurait de l'importance.
Merci
2 GO dans la RAM... Mais ça va pas???
Si ton ordi a moins de 2 GO,tu vois un peu le problème....
supersnail >> disons que si son programme doit tourner sur des machines avec 16 Go de RAM, 2 GO n'est plus grand chose. Par contre, sur une machine courrante, boom :aie:.
Ca dépense déjà de la version de windows que tu utilises... Est-ce bien un windows 64 bits ?
Oui effectivement je suppose qu'on a la RAM qui va avec et éventuellement un peu de swap. Le jee ne pense pas que mon "boom" est lié à un manque de mémoire, mais plutôt à une incapacité de gérer un espace d'adressage > 2Go.Citation:
Envoyé par Davidbrcz
Suivant les versions de Windows 32 bits, on peut augmenter l'espace virtuel adressable de 2 a 3GB avec l'option /3GB dans boot.ini et utiliser plus de mémoire physique que 4GB en utilisant PAE.
Je suis quand même assez surpris que vous deviez charger plus de 2GB d'objets en mémoire. Si vous n'avez pas le choix, il serait peut être préférable d'utiliser un système 64 bits... Mais est-ce vraiement raisonnable?
- W
Pourquoi pas fragmenter ton bloc et charger les données au fur et à meusre?
Dans le meilleur des cas, il pourrait mettre ses objets dans une vraie base de données (donc sur disque) et n'utiliser la mémoire que pour les objets 'actifs'.Citation:
Envoyé par supersnail
Je ne sais pas si un language objet sait faire cela de façon transparente (ie, ne va-t-il pas falloir faire "à la main" sa propre gestion mémoire.
-W
C'est nul Windows ou quoi ? Sous Linux 4Go de RAM en 32 bits par processus ça ne pose aucun problème.
http://msdn.microsoft.com/en-us/libr...1z(VS.71).aspx
:boulet:Citation:
Envoyé par loufoque
Par défaut Linux 32 bits permet à un process utilisateur d'adresser 3GiB et au système le GB restant. Windows est en 2GiB/2GiB.Citation:
Envoyé par loufoque
Si on veut pouvoir utiliser jusqu'à 64GiB de RAM il faut aussi mettre en route l'option PAE.
- W
Faux. Seulement sur les noyaux d'entreprises. Sur les noyaux classiques, la limite est entre 2 et 2.5Go.Citation:
Envoyé par loufoque
On s'est mal compris. Le noyau peut accéder à une certaine quantité de RAM. Sur x86 32 bits sans PAE on est effectivement limité à 3Go.
Ça n'a rien à voir avec l'espace que peut adresser un processus en espace utilisateur.
3GiB est la taille maximale de l'espace d'adressage utilisateurCitation:
Envoyé par loufoque
Il n'est pas nécessaire qu'il y ait 3GiB de RAM pour faire malloc (3GiB).
- W
On peut adresser 4Go dans un processus 32bits. Ensuite, le processeur lui est en 36bits, et grâce à la MMU l'OS peut adresser bien plus s'il est conçu pour. A ce moment, chaque processus pourrait adresser 4Go différents.
En revanche, dans un processus Linux classique, on ne dépasse pas les 2.5Go alloués/allouables dans le processus. Sous Windows, c'est 3Go allouables au maximum (et donc en adressable, on dépasse bien si on compte le système accessible depuis un processus).
Yup, j'ai précisé "utilisateur" dans mon post précédent.Citation:
Envoyé par Matthieu Brucher
Néanmoins, par défaut Windows 32 bits. l'espace utilisateur max est de 2Go si on ne le démarre pas /3GO.
Pour Linux, les versions "récentes" sont 3Go/1Go.
- W
Merci de votre aide,
Je n'ai pas résolu mon problème, mais j'ai opté pour un contournement qui consiste à indexer le fichier qui contient les données et à l'interroger à la demande. Evidemment ça prend beaucoup plus de temps que si les données sont en mémoire...mais ça marche. Au passage je me suis bien pris la tête concernant la limite de 2Go cette fois pour l'adressage de la lecture du fichier...:aie: Je n'ai pas trouvé de solution avec les fonctions standard (getline seekg tellg) donc obligé de passer au fonctions système (SetFilePointer ReadFile)
En général, elles offrent des possibilités de "cache" qui devraient permettre d'optimiser les entrées sorties.
- W
Les 2 Gb représentent l'espace adressable. Elle ne dépend pas de la quantité de mémoire vive. Si vous avez des barrettes de 32 Gb, ça n'y changera rien. La limite se trouve au niveau du système d'exploitation.
Sur Windows, par défaut c'est du 2 Gb. On peut augmenter cette limite et la faire passer à 3Gb en allant modifiant le fichier boot.ini. Il faut aussi compiler les exécutables qui devront dépasser ces 2 Gb avec l'option /LARGEADDRESSAWARE.
Cette limite de 3 Gb peut être dépassée sur certains systèmes Windows (les versions Server il me semble).
Sous Linux, la limite est supérieure à 2 Gb mais je me souviens plus quelle est cette limite exactement.
C'est effectivement la bonne solution....Citation:
Envoyé par tnarol
Ca c'est pas normal... ca ne devrait pas, à moins que tu doives ré-utiliser sans arrêt les données précédemment lues. Mais en général ce n'est jamais le cas, sauf pour un petit ensemble de données (que tu vas donc conserver en mémoire pour le coup).Citation:
Evidemment ça prend beaucoup plus de temps que si les données sont en mémoire...mais ça marche.
Aïe.... mauvaise pioche... Oublies les fichiers *sequentiels* (à la ReadFile/SetFilePointer)... Si tu veux aller vite, avec un accès aléatoire à un gros fichier, va regarder les CreateFileMapping....Citation:
Au passage je me suis bien pris la tête concernant la limite de 2Go cette fois pour l'adressage de la lecture du fichier...:aie: Je n'ai pas trouvé de solution avec les fonctions standard (getline seekg tellg) donc obligé de passer au fonctions système (SetFilePointer ReadFile)
C'est un peu la méthode inverse:
mapping = CreateMapping(monfichier);
while () {
memoire = MapViewFile(mapping,index,taille) // taille doit etre un multiple de secteurs du disque
utilisation directe de "memoire"...
}