Discussion :

[donkeyquote]

Salut !!

J'ai entendu parler des "mémories pools"... Aparement ils sont bien pratiques quand on aloue de gros packages de mémoire et qu'on veut accelerer l'application.

Pouvez vous me dire quels sont les avantages, comment ça marche et comment les implémenter ?

Merci !

[Médinoc]

À ma connaissance, ce n'est pas tant quand on alloue de grosses quantités, mais quand on alloue et désalloue fréquemment...

[Invité]

Salut donkeyquote,

Lorsque tu utilises l'operateur "new" standard (::new) ou malloc(), tu utilises des allocateurs standards, destinés à fonctionner bien dans toutes les circonstances.

Lorsque les circonstances sont plus spécifiques, tu peux souvent optimiser un peu les choses pour obtenir une allocation plus rapide. Les "pool allocators" sont en général des allocateurs de mémoire qui excellent dans l'allocation d'objets dont la taille est connue. Tu peux par exemple avoir un allocateur pour des objets de 16 octets. En général, on combine des allocateurs pour pouvoir être un peu plus flexible. Par exemple un allocateur général peut déléguer à des allocateurs de "pool" pour toutes les tailles entières comprises entre 1 et 32 octets, et passer ensuite à l'allocateur standard pour les plus gros objets.

Carl

[bolhrak]

Salut,

Comme l'a dit Medinoc, les pools sont plus employés lorsque tu effectues de nombreuses allocations/désallocations, ou dans certains cas où tu souhaites limiter le nombre d'objets d'un certain type.

Il ne faut pas les confondre avec les allocateurs spécifiques, notamment ceux pour les petits objets auxquels fait allusion 5hdumatin (même si le fonctionnement peut s'en rapprocher, les allocateurs de petits objets gérant des chunks de mémoires, donc assimilables à des pools). Dans le cas d'allocateurs on gère vraiment la mémoire à bas niveau sans vraiment se soucier du type de l'objet (en tout cas pas dans la partie basse de l'allocateur) tandis que les pools se contentent de maintenir un certain nombre d'objets disponibles, de les allouer ou désallouer, mais sans se soucier réellement de comment est faite l'allocation.

Un exemple simple (et pas forcément efficace) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
class ObjectPool
{
 
public:
 
    ObjectPool() { allocObject(); }
 
    Object* getObject();
    void release(Object* object);
 
private:
 
    std::vector<Object*> m_objectList;
    static const int realloc = 10;
    std::vector<Object*> m_usedObjectList;
 
    void allocObject();
};
 
Object* ObjectPool::getObject() {
    Object* obj = m_objectList.back();
    m_objectList.pop_back();
    m_usedObjectList.push_back(obj);
    if(m_objectList.empty()) {
        allocObject();
    }
}
 
void ObjectPool::release(Object* object) {
    std::vector<Object*> iterator iter = std::find(m_usedObjectList.begin(), m_usedObjectList.end(), object);
    if(iter == m_usedObjectList.end()) {
        throw std::exception("Object not allocated by the pool");
    }
 
    m_usedObjectList.erase(iter);
    m_objectList.push_back(object);
    if(m_objectList.size() >= 2* realloc) {
        m_objectList.erase(m_objectList.begin() + realloc, m_objectList.end());
    }
}
 
void ObjectPool::realloc() {
    for(int i = 0; i < realloc; i++) {
        m_objectList.push_back(new Object);
    }
}

En gros il maintient une liste d'objets préalloués, et une list d'objets utilisés. Si la taille des objets utilisés atteint 10, il en alloue dix autres, si la taille des objets non utilisés dépasse 20, il désalloue pour retrouver une taille de 10. Le client n'alloue plus ses objest vai les opérateurs new et delete, mais par des appels à getObject et release. Voilà en gros pour le fonctionnement, après il y a différentes stratégies d'allocation/désallocation.

Tu peux également regarder du côté de boost, ils ont implémenté une lib de memory_pool.

[Invité]

Il ne faut pas les confondre avec les allocateurs spécifiques, notamment ceux pour les petits objets auxquels fait allusion 5hdumatin (même si le fonctionnement peut s'en rapprocher, les allocateurs de petits objets gérant des chunks de mémoires, donc assimilables à des pools).

Hmmm. Bon. Note pour plus tard: tourner 7 fois sa langue autour de la touche entrée avant de répondre... Ai confondu, désolé!

Carl

[screetch]

mouais.

dans le cas d'un "memoy pool" c'est plutot ce que disait 5h non ?

un "pool memoire" est un allocateur qui au lieu d'allouer et desallouer la memoire, maintient un certain nombre d'allocations vivantes pour les ressortir plus tard. c'est la definition stricte du "memory pool", une "piscine" d'emplacements memoire disponible qu'on ne libere pas completement au cas ou on en aurait besoin.

ensuite il y a plusieurs facons d'implementer ce memory pool

ce que tu as créé bolhrak ca s'en rapproche, c'est un object pool, c'est la meme chose mais au niveau au dessus. au lieu de liberer les objets on les garde au cas ou on aurait besoin d'un nouvel objet un peu plus tard. le concept du recyclage quoi.

dans le cas de 5h on parle de pool memoire; on peut placer dans cette memoire n'importe quelles données. les blocs peuvent meme etre de taille differente; mais c'est tres rare.

dans le cas de bolhrak, on ne parle pas de pool memoire (car ce n'est pas la mémoire qui est gérée) mais de pool d'objet, car on garde les objets vivants pour les reutiliser.

Pour completer ce que dit 5h du mat qui est fort exact, l'allocateur généraliste DougLea est constitué ainsi; pour toute les tailles multiples de 8 entre 4 et 256 (si mes souvenirs sont bons, mais reglable dans l'allocateur) il allouera via un pool (un pool de 4, un pool de 8, un pool de 16, un pool de 24, un pool de 32...)
si on reclame 27, il prendra la taille qui convient le mieux (ici, 32) et tant pis pour les 5 octets de trop.
Ensuite, au dela, il utilise un allocateur bien plus generaliste.