Skip to content

Memory management

January 17, 2007

Il n’y a toujours pas de versioin de Massive Stream rendue publique. Il est apparu que le logiciel avait quelques problèmes au niveau de la gestion de la mémoire. Regardons comment la gestion de la mémoire est effectuée.

Gestion simple

Regardons la gestion de mémoire dite simple, mise en place jusqu’à présent : schema de management simple Les Contexts du schéma correspondent aux briques que vous pouvez voir dans le logiciel. Tous les gros block de données sont aloués par les contexte. Et donc tous les liens entre les blocks sont allouées tout le temps. Avec des giga de mémoire vive dans les ordinateurs d’aujourd’hui, la solution du ça passe semblait une bonne option. Cette solution a aussi l’avantage d’être simple. Gestion simplifié, pas trop à se prendre la tête, bref du bonheur.

Sauf quand si on a la bonne idée de charger une grosse image (du genre 3500*2000 et des brouettes, environ 27Mo en BMP) qui est transformé en format HDR (qui multiplie la taille par 4, donc on abouti à 108Mo par image). Atteindre 1Go de ram bouffé, est très vite atteint, en une bonne dizaine de block et *Boum* plus assez de mémoire, crash et autres joyeusetés. Au final la solution de la gestion simple de mémoire n’est clairement pas viable.

Gestion Poolée

management pooled

L’idée dans le gestion poolée est seulement de partager une définition des données, ce qui a une taille négligeable par rapport aux données : environs une centaines d’octets contre 108Mo pour les données. Nous rajoutons un autre objet pour allouer les données à la demande, le pool. Grâce à sa vue globale du graph, il peut également désallouer la mémoire dès qu’il n’y a plus de besoin. Cela induit une perte du temps pour executer la désalocation, mais on a rien sans rien. La définition normale du pool est d’allouer de multiples petit objets et d’éviter de perdre du temps dans les allocations. Ici c’est différent, nous avons de très grands objets que nous devans supprimer dès que possible pour éviter de bouffer toute la mémoire.

Et la vraie méthode utilisée…

Est un mix entre la méthode pooled et la méthode simple. Tout simplement par grosse flemme. Les données sont alouées à la demande (comme dans la gestion pooled donc), mais les données sont toujours situées entre les contextes, et un petit nettoyage est fait automatiquement et localement. Ca évite à de se coltiner l’implémentation du pool et, je l’espère, être plus rapide pour les demandes. Le principe de base est de compter le nombre d’utilisation des données, réinitialisé à chaque passe. Si le nombre d’utilisation tombe à 0, boom, on libère la mémoire. Dans certains cas il arrive que des bouts de mémoires deviennent immortels pour garder des calculs intermédiaires. Cette dernière optimisation permet d’évincer les contexts dont les données ne bougent pas et ainsi d’éviter le recalcul inutile de ces mêmes données.

Donc voilà l’idée avec l’allocation de données à la demande, on espère pouvoir traiter des grosses données (comme l’image en HDR) sans faire peter la mémoire à toutes les 2 secondes.

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: