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.

[screetch]

j'ajoute que meme si on ne parle pas avec les memes termes, le resultat est bien le même.

un peu de lecture sur le sujet :
http://www.boost.org/libs/pool/doc/concepts.html

[yan]

le memory pool est interessant juste pour de petit objet??

[screetch]

pas uniquement, mais c'est plus frequent d'allouer et de desllouer beaucoup de petits emplacements que des gros.

si ton application alloue frequemment des objets d'une certaine taille alors tu peux utiliser les object pool ou les memory pool.

il faut savoir aussi qu'un memory pool consomme beaucoup de memoire pour rien; c'est en general un bloc alloué a l'avance, jusu'a 1Mo, divisé en tas de petits blocs. si on en utilise que 2 blocs, c'est pres d'1Mo qui est gaché. en moyenne, le memory pool est seulement aux 3/4 remplis

multiplie par le nombre de memory pools que tu as (un pour les 4, un pour les 8, etcc etc) et ca commence a devenir imposant. donc tu peux allouer un memory pool specifique a la taille que tu souhaites allouer (2232 si ca t'amuses) mais pas pour toute les tailles jusque 1Mo

[yan]

et dans le cas d'objet de 4-5 Mo ??
alloué / désalloué assez régulièrement? Autant faire un malloc ?

[screetch]

ca depend :

- est ce un chiffre precis
- vas tu allouer/desallouer beaucoup ? (vu la taille, ca parait peu probable, mais bon sait on jamais)

pour une utilisation normale, malloc s'en tirera. si tu as specifiquement UNE taille qui va etre allouée et desallouée, tu peux penser a un memory pool

[nicroman]

La taille n'est pas l'unique raison à l'utilisation d'un pool:

- L'overhead de taille allouée (il y a au moins 4 octets d'overhead en 32-bits, 8 en 64-). Ce qui rend les pools interessants pour les nombreuses allocations de petits objets. C'est aspect tend à disparaitre au fur et à mesure que la taille de la mémoire disponible augmente. (100000 objets de 8 octets => 1,5Mo avec l'overhead, => 781Ko en pool).
- L'overhead de temps d'allocation (allouer dans le tas va au mieux bloquer tous les threads du process, au pire tous les process partageant le même 'tas'). Le pool devient alors interessant car sur certains 'types', l'allocation ne sera plus bloquante, resultant en une meilleure utilisation des multi-core.
- Eviter la fragmentation mémoire...Ca dépend beaucoup de l'implémentation du tas... Avec 1Go de mémoire dispo: malloc(500Mo) malloc(5Ko) free(500Mo) malloc(5Ko) malloc(500Mo) => echec. Si on utilise des pools (que ce soit pour les objets de 500Mo ou de 5Ko d'ailleurs) ca passera. Normalement l'allocation dans le tas est "intelligente", elle va allouer les gros blocs à la fin, et les petits blocs au début... mais c'est dépendant de l'implémentation.
- Accélerer l'allocation en elle-même quand celle-ci est complexe, et demande du système beaucoup de temps machine.
- Eviter un temps d'initialisation "long" (par exemple, une connection à une base de donnée qui va nécessiter un login, une connection https qui va demander un handshake de certificats, etc...) des objets alloués.

[Invité]

J'ajoute quand même que l'allocateur standard est déjà bigrement rapide, et que s'il est possible de faire un allocateur multi-thread plus rapide (peut-être x2), ce n'est pas à la portée du premier venu. Si on sait qu'on travaille avec un seul thread, alors il est possible sans trop d'effort (si on alloue des objets de taille fixe) d'atteindre des gains de performances d'un facteur 10.

Carl