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.