Discussion :

[Ange_blond]

Bonjour,

Je me heurte à un probleme de gestion mémoire.
Rien de nouveau en C++ me direz vous, mais néanmoins...

Contexte :
Sur le projet que je developpe, on utilise des modeles objets plutot lourds, des libraires externes, etc... du bon gros projet de 120k lignes en somme.

Le soucis c'est qu'a présent, les données utilisées/generées (ex: graphe de scene) sont tellement devenues imposantes que la mémoire sature rapidement, déclenchant des magnifiques crash.
Je cherche donc un moyen de gerer les allocations mémoire pour éviter ou tout du moins limiter la portée des crash.
De ce que j'ai vu/lu les operateurs new levent des exception std::bad_alloc si necessaire, sans pour autant retourner NULL.

Ce que je voudrais éviter c'est de devoir encadrer chaque new par un manager d'exception (bloc try...catch).
Un seul bloc pourrait faire l'affaire s'il est placé à haut niveau, en tout cas je pense, mais la complexité est telle qu'il n'est pas évident de localiser le bon endroit pour le placer.

Ma question est donc de savoir si le fait de placer un seul bloc (ou une poigné) à haut niveau dans le code (par haut niveau j'entend le main() ou les méthodes principales) pourrait suffire à gerer les crash.
D'autre part, le catch permettra de ne pas crasher l'application, mais l'état des elements alloués en mémoire à ce moment ne sera selon moi pas connu, et donc il sera difficile de continuer l'execution du programme.

Il y a aussi la possibilité de surcharger/redéfinir l'operateur new, mais je doute que celà aide...

Voilà j'espere etre resté compréhensible, si ce n'est pas le cas n'hesitez pas à demander des clarifications.

Merci de votre aide.

[poukill]

Bonjour,
Ce que je voudrais éviter c'est de devoir encadrer chaque new par un manager d'exception (bloc try...catch).

Je te conseille en effet d'éviter ça !

Ma question est donc de savoir si le fait de placer un seul bloc (ou une poigné) à haut niveau dans le code (par haut niveau j'entend le main() ou les méthodes principales) pourrait suffire à gerer les crash.

Tu réponds tout seul à ta question : attraper une exception, c'est bien. La traiter c'est super. Mais continuer ton programme c'est une autre paire de manche. Surtout que recevoir une std::bad_alloc, ça ferme un peu le bal, car si l'utilisateur voulait vraiment faire ça, bah que peut il faire d'autre ?

Il y a aussi la possibilité de surcharger/redéfinir l'operateur new, mais je doute que celà aide...

Pour trouver qui a lancé et où si, mais à part ça...
http://loulou.developpez.com/tutorie.../partie1/#L2.2

Au final, tu devrais peut-être prendre un profiler et déterminer comment réduire ton empreinte mémoire, si besoin en diminuant l'optimisation. Réécrire les parties concernées ensuite ?
Ou alors prendre un PC plus musclé !

[Emmanuel Deloget]

Tu peux aussi jeter un coup d'oeil à set_new_handler().

Il y a des merveilles qu'on ne devrait pas cacher...

En gros, un handler est appelé chaque fois qu'une allocation échoue. Il peut ainsi libérer de la mémoire, et redonne le contrôle a new qui recommence, etc.

Bien évidemment, il y a un mécanisme d'arrêt parce que sinon, tu aurais bien des difficultés à sortir d'une telle boucle

[LittleWhite]

Bonjour,

Et si la surcharge de l'opérateur new vous permettez de renvoyer NULL lors d'un échec, est ce que cela peut convenir ?

[jblecanard]

Salut

As tu passé un coup de Valgrind sur ton projet, pour vérifier si ça ne fuit pas un peu partout ? Dans un projet comme ça, de petites fuites locales avoir un effet désastreux si elles se retrouvent dans des boucles.

[JolyLoic]

Pour trouver qui a lancé et où si, mais à part ça...
http://loulou.developpez.com/tutorie.../partie1/#L2.2

Attention : J'ai déjà signalé que ce code était non conforme, puisqu'il fait un #define sur un mot clef, mais ce problème n'est plus depuis peu un problème purement théorique. En C++0x (et contre mon vote), il est actuellement prévu que le mot clef new soit réutilisé dans un autre contexte où ce #define ne passera pas. Donc ce code ne pourra pas compiler de code C++0x.

[Ange_blond]

Salut

As tu passé un coup de Valgrind sur ton projet, pour vérifier si ça ne fuit pas un peu partout ? Dans un projet comme ça, de petites fuites locales avoir un effet désastreux si elles se retrouvent dans des boucles.

Oui ça a été fait.
Mais le programme n'a pas(peu) de fuites. Il s'agit réellement d'un consommation énorme parce qu'il doit gerer des masses de données, et sans cesse allouer/désalouer de la mémoire pour les afficher...

Bonjour,

Et si la surcharge de l'opérateur new vous permettez de renvoyer NULL lors d'un échec, est ce que cela peut convenir ?

J'y avais pensé oui, mais il faudrait tout de meme tester tous les new pour savoir si ça a échoué ou non, ce qui revient à coller des try catch partout au final.

Tu peux aussi jeter un coup d'oeil à set_new_handler().

Il y a des merveilles qu'on ne devrait pas cacher...

Je jette un oeil de ce pas merci. je ne connaissais pas mais ça pourrait s'avérer utile

Tu réponds tout seul à ta question : attraper une exception, c'est bien. La traiter c'est super. Mais continuer ton programme c'est une autre paire de manche. Surtout que recevoir une std::bad_alloc, ça ferme un peu le bal, car si l'utilisateur voulait vraiment faire ça, bah que peut il faire d'autre ?

Je vais tester une gestion qui va fermer le programme dans les regles, ou tout du moins éviter le crash à venir apres un bad_alloc.
Ce que je recherche c'est avant tout de la stabilité.

Au final, tu devrais peut-être prendre un profiler et déterminer comment réduire ton empreinte mémoire, si besoin en diminuant l'optimisation. Réécrire les parties concernées ensuite ?
Ou alors prendre un PC plus musclé !

Alors réécrire le code en quelques jours ça risque d'etre chaud
Et changer de PC... ben faut le dire au client mais j'arrete pas de le rabacher depuis 2 ans

Merci pour vos conseils, je vais continuer à creuser la question.
N'hesitez pas si vous avez encore des idées

[Emmanuel Deloget]

Si tu as beaucoup de données, peut-être peut tu tout simplement écrire un adapteur qui va en garder une grosse partie sur disque en attendant de t'en servir pour de vrai. Si c'est possible, il serait sage de combiner cette approche avec une notion de niveau de détails (premier niveau : pas beaucoup de données, mais une approximation de la totalité des données ; les niveaux en dessous sont de plus en plus détaillés ; voir ce qui se fait en mip mapping pour les jeux vidéo).

[Ange_blond]

Si tu as beaucoup de données, peut-être peut tu tout simplement écrire un adapteur qui va en garder une grosse partie sur disque en attendant de t'en servir pour de vrai. Si c'est possible, il serait sage de combiner cette approche avec une notion de niveau de détails (premier niveau : pas beaucoup de données, mais une approximation de la totalité des données ; les niveaux en dessous sont de plus en plus détaillés ; voir ce qui se fait en mip mapping pour les jeux vidéo).

C'est à dire que... c'est dejà le cas !
J'utilise des LOD qui sont paginé sur le disque et qui sont chargé depuis le disque à la runtime, et sont déchargé aussi à la runtime. (en fonction de la camera)
C'est ceci qui implique des mouvements massifs d'allocation/désallocation à la runtime et qu'il faut gerer car n'importe quand un gros paquet de données peut etre alloué ou désaloué.

Sans ce systeme de LOD, ça ferait longtemps qu'on aurait cessé d'essayé de charger autant de données

[screetch]

le problème peut être que tes objets ont tous des tailles différentes, et que tu peux en mettre n'importe ou. C'est pour un jeu vidéo donc?

il existe d'autres possibilités de stockage qui permettent de charger et decharger plus "amicalement":

mettons que tu reserves de base un enaaaaurme bout de mémoire (pas trop hein )
ton "monde" (la liste des objets) est divisé ensuite en couches:
la couche 0 est ce qui est visible en permanence
la couche 1 est divisée en case; elle n'est chargée que si on est proche de cette case
la couche 2 itou, cases plus petites.
Les lods les plus precis sont donc dans la couche 2, la couche 0 contient les objets les plus imprécis

lorsque la caméra est en un point x, y: tu charges (de base) la couche 0, et tu la mets tout au debut de ta memoire
tu determines ensuite sur quelle "case" tu es, tu risques d'avoir besoin des cases alentours évidemment (donc mettons 9 cases de couche 1: la case sur laquelle tu es et les 8 cases autour). Tu les charges. Puis de même avec les 9 cases de couche 2.
Lorsque tu te deplaces, tu devras donc decharger certaines cases de couche 1 et 2 pour les remplacer par d'autres. L'astuce est alors souvent de faire des cases qui ont pratiquement le même cout; alors on vide une case dont on a pas besoin et on la remplace par une case dont on va avoir besoin.

Ca peut etre lourd si tu changes en permanence de case genre tu te promènes juste sur la frontière. Dans ce cas, il se peut que tu doives decharger les cases dont tu n'as plus besoin mais... que tu ne charge pas toujours les cases dont tu vas avoir besoin, tant que tu n'es pas sur que tu vas vraiment t'en servir.

Il faut donc gérer tes données par batch, pas individuellement, et tu charges tout d'un coup, pas un par un. Et pour ce faire tu peux utiliser les mêmes blocs de mémoire.
Si une case ne tient pas en mémoire c'est que la case est trop gourmande, il faut la retravailler (je part du principe d'un jeu vidéo ou on a le choix, hein, donc si tu n'as pas le choix pour une raison x ou y ca va être cotton).

[Ange_blond]

le problème peut être que tes objets ont tous des tailles différentes, et que tu peux en mettre n'importe ou. C'est pour un jeu vidéo donc?

il existe d'autres possibilités de stockage qui permettent de charger et decharger plus "amicalement":

mettons que tu reserves de base un enaaaaurme bout de mémoire (pas trop hein )
ton "monde" (la liste des objets) est divisé ensuite en couches:
la couche 0 est ce qui est visible en permanence
la couche 1 est divisée en case; elle n'est chargée que si on est proche de cette case
la couche 2 itou, cases plus petites.
Les lods les plus precis sont donc dans la couche 2, la couche 0 contient les objets les plus imprécis

lorsque la caméra est en un point x, y: tu charges (de base) la couche 0, et tu la mets tout au debut de ta memoire
tu determines ensuite sur quelle "case" tu es, tu risques d'avoir besoin des cases alentours évidemment (donc mettons 9 cases de couche 1: la case sur laquelle tu es et les 8 cases autour). Tu les charges. Puis de même avec les 9 cases de couche 2.
Lorsque tu te deplaces, tu devras donc decharger certaines cases de couche 1 et 2 pour les remplacer par d'autres. L'astuce est alors souvent de faire des cases qui ont pratiquement le même cout; alors on vide une case dont on a pas besoin et on la remplace par une case dont on va avoir besoin.

Ca peut etre lourd si tu changes en permanence de case genre tu te promènes juste sur la frontière. Dans ce cas, il se peut que tu doives decharger les cases dont tu n'as plus besoin mais... que tu ne charge pas toujours les cases dont tu vas avoir besoin, tant que tu n'es pas sur que tu vas vraiment t'en servir.

Il faut donc gérer tes données par batch, pas individuellement, et tu charges tout d'un coup, pas un par un. Et pour ce faire tu peux utiliser les mêmes blocs de mémoire.
Si une case ne tient pas en mémoire c'est que la case est trop gourmande, il faut la retravailler (je part du principe d'un jeu vidéo ou on a le choix, hein, donc si tu n'as pas le choix pour une raison x ou y ca va être cotton).

En fait, je n'ai pas tellement le choix
Les données sont massives et ne sont pas les miennes.
Le systeme de LOD est geré par OSG (moteur de rendu 3D) donc a part les reglages je ne peux pas modifier le comportement, sans parler du fait que le comportement actuel est déjà plutot bon dans l'ensemble.

Plutot que de retoucher la maniere de gerer les LOD, je cherche une maniere de gerer la mémoire du processus sans failles

Merci de ton aide cependant

[Emmanuel Deloget]

Tu peux peut-être utiliser une technique de pré-allocation, afin d'éviter les allocations trop masssives : tu alloues un gros, gros buffer au début, tu gardes une grosse partie de ce buffer pour les gros objets, et le reste pour les petits objets (en gros, tu fais deux pools). Il y a de bons papiers sur le sujet sur le net (cf. aussi Modern C++ Design d'Andrei Alexandrescu). C'est généralement le type de technique adoptées dans le cas d'un système contraint par la mémoire (consoles, mais aussi appareils mobiles lorsque ceux-ci peuvent être programmés en C++ : cf. cet article). Selon ta plateforme, tu peux aussi jeter un coup d'oeil à dlmalloc au cas où il ne serait pas déjà utilisé par défaut (sur certaines versions de Linux).

Si tu utilises les collections offertes par le C++, tu seras peut-être intéressé par la possibilité de définir tes propres allocator (pas difficile : il suffit de faire une classe qui répond à la même sémantique que le default allocator des conteneurs), ce qui te permettra d'implémenter différentes stratégies d'allocation. Ensuite, tu peux essayer de voir si ces conteneurs sont ou non un point noir dans ton système : ils ont tendance à garder trop de mémoire pour eux - un bon point pour ce qui est de la rapidité, mais le problème devient vite très ennuyeux dès lors que tu commences à être limite en mémoire. Par exemple, les std::string sur les compilateurs récents supportent généralement l'optimisation connue sous le nom de small string optimisation (en gros : chaque string possède un buffer interne de 16 caractères pour stocker les petites chaines sans avoir besoin de les allouer ; le problème est que 100,000 chaines vides prennent alors 1,6 MB). De manière générale, la stratégie d'allocation des différents conteneurs de la librairie standard est suboptimale dans un système contraint par la mémoire, ça peut donc être une piste à évaluer.

Sinon, tu peux reprendre à la base avec ce papier (pdf), assez ancien, mais qui donne toutes les pistes à évaluer (enfin, toute celles à laquel l'auteur a pu penser en 1995 ; en même temps, les techniques n'ont pas évolué tant que ça depuis). A voir aussi, le Memory Pool System, un projet commercial transformé en projet open source il y a une petite dizaine d'année, toujours développé, et qui semble contenir la réponse à un bon nombre de questions.

[Flob90]

Si tu as besoin d'implémenter un système de gestion de la mémoire dans le même genre que celui de Loki (un pool dans lequel tu pioches grace à des new/delete surchargés), il y a plusieurs articles sur Dr Dobb's qui traitent de structure de donnée qui peuvent servir (dans le sens être plus performent), dans des cas spécifique, je pense au Splay Tree et au WRRMMap par exemple.

Et si tu peux, lis le chapitre de MC++D consacré au sujet, il explique assez bien le principe et comment le mettre en place.

[Nogane]

Bonjour,
Optimiser la mémoire est bien mais ne garantie pas que le programme continuera de tourner si la quantité de données augmente encore plus.

En plaçant un try catch au bon endroit, il doit être possible de revenir a un niveau de détail plus faible en cas de bad_alloc. Ainsi le programme continuerai de tourner comme si de rien n'était. Selon moi, un bad_aloc ne devrait pas être considéré comme la mort du programme.

[Ange_blond]

Bonjour,
Optimiser la mémoire est bien mais ne garantie pas que le programme continuera de tourner si la quantité de données augmente encore plus.

En plaçant un try catch au bon endroit, il doit être possible de revenir a un niveau de détail plus faible en cas de bad_alloc. Ainsi le programme continuerai de tourner comme si de rien n'était. Selon moi, un bad_aloc ne devrait pas être considéré comme la mort du programme.

J'aimerais aussi ne pas crasher en effet, mais changer les parametres des LOD est une solution interessante, ça permettrait de liberer un peu la mémoire.