Allocation mémoire forcée

Bonjour,

je me trouve dans une situation où je dois utiliser un très grand espace mémoire pour le
stockage de mes variables. Je cherche une alternative, mais en attendant, j'aurai aimé
pouvoir faire tourner mon algorithme sur mes données, ce qui me ferai gagner du temps
en attendant d'optimiser mon programme.

Alors voilà, je dois stocker beaucoup d'informations en plus de mes données et je voulais
savoir si on ne pouvait pas imposer une taille de mémoire avant le lancement du
programme. Quelque chose qui dirait :

" Avant toute chose, je veux que tu réserves 10 Go de mémoire "

Si quelqu'un pouvait m'aider, merci.

Gruz

Bonjour,
Le problème est-il de "pré-allouer" de la mémoire(style pool mémoire), ou bien d'allouer une grande quantité de mémoire? Ce sont deux problèmes différents.

Pour le pool mémoire il existe des solution toute faite comme boost::pool ou le SmallObjectAllocator de Loki.

Mais j'ai l'impression que votre problème réside plus dans l'allocation d'une grande quantité de mémoire.
Pour une tel quantité(10Go), il va vous falloir un OS 64bit, et une compilation 64bit. De plus, votre machine doit avoir les 10Go de libre en RAM. Si toutes ces conditions sont réunis, il n'y as, généralement, rien a faire de plus.

Tout d'abord, merci Nogane pour votre réponse.

Je tourne effectivement sur une machine 64 bits avec 24 Go de RAM je crois, mais apparemment ça ne fonctionne pas :(
Mon programme fonctionne à merveille sur des petits jeux de données.

Faut-il que je déclare quelque chose pendant la compilation pour l'avoir en 64 bit ?

Je tourne sous Linux et utilise un makefile à base de g++ mais il ne me semble pas préciser quelque part que je tourne en 64 bits.

Citation:

Envoyé par Gruzzyh2

Tout d'abord, merci Nogane pour votre réponse.

Je tourne effectivement sur une machine 64 bits avec 24 Go de RAM je crois, mais apparemment ça ne fonctionne pas :(
Mon programme fonctionne à merveille sur des petits jeux de données.

Faut-il que je déclare quelque chose pendant la compilation pour l'avoir en 64 bit ?

Je tourne sous Linux et utilise un makefile à base de g++ mais il ne me semble pas préciser quelque part que je tourne en 64 bits.

J'ai lu çà sur un autre topic de developpez.com:

Citation:

Envoyé par Suryavarman

nativement gcc est en 64 bit et il est nécessaire de mettre l'option -m32 pour le forcer en 32bits.

Ce qui veut sûrement dire d'en ton cas qu'il est nécessaire d'avoir la dernière où plus récente mise à jour de gcc. ( ou que tu n'as pas un système 64bits ou un matériel 64bits )

Source: http://www.developpez.net/forums/d39...m64-ne-marche/

Quelle est l'erreur que tu as?

Citation:

Quelle est l'erreur que tu as?

J'ai un bad alloc et parfois un segmentation fault. Sur certains tests, il me créé un des tableaux, il arrive à lire toutes les premières entrées; et un certain nombre des dernières, mais au milieu il se perd (segmentation fault). En sachant que je les ai initialisées.

Citation:

Envoyé par Gruzzyh2

J'ai un bad alloc et parfois un segmentation fault. Sur certains tests, il me créé un des tableaux, il arrive à lire toutes les premières entrées; et un certain nombre des dernières, mais au milieu il se perd.

Donc il arrive probablement au bout de la mémoire qu'il peut allouer.

il a 24 Go de RAM, donc coté mémoire, çà devrait être bon. Quand tu le fais tourner, combien de mémoire disponible te reste t'il?
Quelle est ta version de gcc?
Peux tu montrer les options de compilation que tu utilises?

Citation:

Envoyé par rmaker

il a 24 Go de RAM, donc coté mémoire, çà devrait être bon. Quand tu le fais tourner, combien de mémoire disponible te reste t'il?

Je ne sais pas ça.

Citation:

Envoyé par rmaker

Quelle est ta version de gcc?

gcc 4.7.0

Citation:

Envoyé par rmaker

Peux tu montrer les options de compilation que tu utilises?

-w -lpthread -lX11 -g

deja il faudrait donner un peu plus d'information pour qu'on t'aide; lire "ca ne marche pas" c'est toujours frustrant.

"il me cree des tableaux" ce n'est pas assez precis; de meme, allouer 10Go c'est pas assez precis:

essayes tu d'allouer de maniere contigue?
essayes tu de creer un std::vector et de faire des push_back?
utilises tu un tableau C?

si tu veux de la memoire contigue, pour allouer tout ca, je crois que le mieux est de faire:
Code:

1 2 3 4 5 void* result = mmap(NULL, 10*1024*1024*1024, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0); .... munmap(result, 10*1024*1024*1024);
il y a aussi beaucoup de moyens de reserver 10Go d'espace memoire sans allouer l'espace physique derriere, es-tu certain d'avoir besoin de 10Go _en meme temps_ et de ene pas pouvoir travailler sur 1Go par 1Go ou meme moins.

Citation:

Envoyé par screetch

deja il faudrait donner un peu plus d'information pour qu'on t'aide; lire "ca ne marche pas" c'est toujours frustrant.

Désolée ^^' cela fait 3 semaines que je cherche des solutions et à force ça me parait assez évident.

Citation:

Envoyé par screetch

"il me cree des tableaux" ce n'est pas assez precis; de meme, allouer 10Go c'est pas assez precis:

essayes tu d'allouer de maniere contigue?

10 Go était un exemple, je suppose que le mot contigu était ce que je cherchais. Je vais essayer d'être plus claire, ce que j'essaie de faire, c'est de lui faire réserver un espace d'une taille que je définirai, pour qu'il fasse toutes les déclarations dedans. Suis-je plus claire ?

Citation:

Envoyé par screetch

essayes tu de creer un std::vector et de faire des push_back?
utilises tu un tableau C?

Je créé plusieurs tableaux, pointeurs, et un pointeur basé sur une structure particulière, voici ceux qui demandent le plus de mémoire :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 int birthmap[BM_dim*3]; blabla::cube * img3d = new blabla::cube[dimT] //blabla::cube vient d'une bibliothèque développée en parallèle class cube { public: // Constructors and destructors cube() : value(0), isCenter(0), isNew(0), toDraw(0), mean_inside(0), mean_outside(0), Attach(0), total_E(0) {} // Default constructor cube( unsigned char d_value, bool d_isCenter, bool d_isNew, bool d_toDraw, float d_mean_inside, float d_mean_outside, float d_Attach, float d_total_E); // Constructor ~cube(); // Default destructor // Variables unsigned char value; // Value of the point at this pixel bool isCenter; // 1 : this pixel is the center of one cube bool isNew; // 1 : this pixel is a new point bool toDraw; // 1 : this pixel is to draw float mean_inside; // Mean inside the cube float mean_outside; // Mean outside the cube, in the crown float Attach; // Attach to data float total_E; // Total of energy // Functions float overlap(int x, int y, int z, int i, int j, int k); };
Citation:

Envoyé par screetch

il y a aussi beaucoup de moyens de reserver 10Go d'espace memoire sans allouer l'espace physique derriere, es-tu certain d'avoir besoin de 10Go _en meme temps_ et de ene pas pouvoir travailler sur 1Go par 1Go ou meme moins.

malheureusement, mon jeu de données comprend plus de 6Go d'images et on m'a demandé de ne pas scinder le traitement qui doit être global, les données sont liées entre elles donc je pense que ça baisserai l'efficacité du traitement. :?

une regle si on va avoir un grand nombre de structures ca pourrait etre de les rendre le plus petit possible:
Code:

1 2 3 4 5 6 7 8 unsigned char value; // Value of the point at this pixel bool isCenter; // 1 : this pixel is the center of one cube bool isNew; // 1 : this pixel is a new point bool toDraw; // 1 : this pixel is to draw float mean_inside; // Mean inside the cube float mean_outside; // Mean outside the cube, in the crown float Attach; // Attach to data float total_E; // Total of energy
ces variables peuvent avoir un "padding" entre elles qui boufferait pas mal d'espace. Pour le coup, il n'y en a pas, mais c'est un coup de bol; la regle est de mettre les champs les plus volumineux en premier. En reordonnant
Code:

1 2 3 4 5 6 7 8 float mean_inside; // Mean inside the cube float mean_outside; // Mean outside the cube, in the crown float Attach; // Attach to data float total_E; // Total of energy unsigned char value; // Value of the point at this pixel bool isCenter; // 1 : this pixel is the center of one cube bool isNew; // 1 : this pixel is a new point bool toDraw; // 1 : this pixel is to draw
ca sera plus robuste.

si les donnees sont liees entre elles il y a peut etre moyen de les trier; a priori il y a de la dependance et de l'independance dans ces donnees. Un pre-traitement pourrait etre de mettre tes donnees dans des groupes/batches separes

par exemple, si tu as les donnees A B C D E F, avec
A lie a B et B lie a C,
D lie a E et E lie a F, tu as deux groupes independants: A B C, D E F.

Tu peux donc:
- charger A B et C ensemble, puis D, E, F
- traiter ABC sur un processeur et DEF sur un autre processeur

ce qui pourrait grandement rentabiliser toute operation de tri (qui peut etre assez couteuse)

ce ne sont que des exemples d'optimisations, cependant. Pour ton probleme principal, pour avoir de la memoire continue, utilise mmap comme j'ai mis plus haut; cela va reserver 10Go d'espace continu (sur 64 bits c'est presque garanti de fonctionner)

quelle est la valeur de dimT?

Salut,

Même s'il est, en théorie, superflu, tu peux déjà rajouter le flag " -m64" à ta ligne de commande pour être sur de compiler en 64 bits ;)

Mais pourrais tu déjà nous donner la sortie de gcc -v :question: (pour etre sur que tu utilises bel et bien une version 64 bits / multilib).

Pourrais tu également nous donner une idée de la mémoire occupée par ton système avant le lancement de tes tests :question:

Citation:

Envoyé par screetch

la regle est de mettre les champs les plus volumineux en premier.

Merci pour le conseil =)

Citation:

Envoyé par screetch

si les donnees sont liees entre elles il y a peut etre moyen de les trier;

Je cherche effectivement à les manipuler d'une manière plus intelligente

Citation:

Envoyé par koala01

tu peux déjà rajouter le flag " -m64" à ta ligne de commande pour être sur de compiler en 64 bits

ok je vais faire ça

Je crois bien aue je suis obligée de changer ma méthode de traitement si je veux faire simple, je vais donc reprendre certaines choses.

En tout cas merci à tous pour votre aide.

Es-tu certain qu'il te faut ces 10 Go de données en même temps ?

Ne peux-tu faire des chargements partiels ?

Cela compliquerai les choses pour les traitements au niveaux des "bords internes"
de mon image, puisque le traitement ne se fait pas sur une certaine épaisseur du volume
dans touts les directions.

De plus, pour un point, on a besoin des informations des points environnants sur une
certaine distance, donc je devrai recharger toutes les informations les concernants, ca
facilite pas forcément la tâche et ne réduira pas forcément la mémoire demandée, c'est pour
ça que j'hésite grandement.

Quand tu fais du traitement d'image en CUDA, c'est pourtant ce qu'on fait (couramment).

Pourrais-tu préciser le contexte d'utilisation ?

Pour être honnête, je ne sais pas ce qu'est le CUDA. Si j'ai bien compris, il s'agit de traitement en temps réel ?

Il s'agit de traitement d'images biomédicales, et mon responsable m'a demandé de préférence ne pas
scinder les données, je fais donc ce que je peux :traine:

Citation:

Envoyé par Gruzzyh2

Pour être honnête, je ne sais pas ce qu'est le CUDA. Si j'ai bien compris, il s'agit de traitement en temps réel ?

Oui, mais à la limite, peu importe.
Le principe est que chaque pixel est traité par un thread différent. Qui eux-mêmes sont répartis entre plusieurs cœurs, eux-mêmes répartis en plusieurs processeurs. Donc, tu découpes l'image pour pouvoir faire ton traitement en parallèle et/ou en séquentiel.
Les zones peuvent se recouvrir si tu appliques un filtre.

C'est donc tout à fait faisable, que tu bosses sur GPU ou CPU. Dans ton cas, l'intérêt est de limiter la consommation de RAM.

Citation:

Envoyé par Gruzzyh2

Il s'agit de traitement d'images biomédicales, et mon responsable m'a demandé de préférence ne pas scinder les données, je fais donc ce que je peux :traine:

Il a une bonne raison, pour ça ?
Parce que si tu arrives à 10 Go de données, il faudrait l'amener à revoir sa position.

Comme je l'ai dit plus haut, je suis en train de revoir justement la place que cela
peut prendre pour essayer de la réduire. Mon programme n'est pas non plus le plus optimisé
mais j'ai préféré faire simple tant que c'était possible. Et donc là, j'ai déjà permis d'éliminer
pas mal de soucis...

:bug:

Entre consommer du temps et de la RAM je ne sais pas quel est le plus raisonnable, mais
la pratique apprend beaucoup donc j'en tirerai les conclusions après, tant pis je me transformerai
en lapin d'Alice un petit moment.