Re: [boost] [Countertree + Suballocator] New Version

Subject: Re: [boost] [Countertree + Suballocator] New Version
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-04-15 08:23:50

On 14/04/12 19:43, Francisco José Tapia wrote:
> I am not theoretical. To write code is my hobby , not my work. And after my
> work and my family, in my free time , I like to think about algorithms and
> to write them.
>
> I would know all the details about the GCC std::allocator ( named
> new_allocator) examining the code, but I have not time.I don't know what
> must do a pool allocator and how manage the memory.
>
> I like the simple and economical things, and the suballocator is designed
> according this.

So you're clearly saying you have little time to commit to this, and do 
not have the desire to clarify things and employ rigor in your developments.

Therefore I do not think your libraries would ever be suitable for 
inclusion in Boost.

>    According my information ( perhaps I am wrong). In the boost library you
> have two allocators : boost::pool_allocator and boost::fast_pool_allocator.
> The first fail when must allocate 50.000.000 elements because the time was
> excessive. The second is fast, an excelent allocator, but have problems
> with the memory. If you allocate many elements and  check the memory used,
> deallocate all the elements and check the memory again, you can see it is
> using the same amount of memory

As the documentation states, pool_allocator is for vector-like 
allocation, while fast_pool_allocator is for node-like allocation.

The fact the memory is not being freed is by design, this is what a pool 
allocator is.

I would guess that to get what you want, you should use an instance of a 
pool by container, not the singleton global pool.

>   The suballocator have several advantages compared with the
> boost::fast_pool_allocator :
>
> a) It is a byte faster. (This is the less important question)

Being a bit faster is a poor argument. It really depends on the cases, 
and you can make benchmarks mean whatever you want them to by picking 
the cases where your approach is the most useful.

> b) The allocator can be used with any allocator. If you have an allocator
> for share memory , you can't use the fast_pool_allocator

Working as an allocator adaptor is indeed a good thing.

> c) If in your program you are using a fast_pool_allocator,and  in a moment
> have a peak of work,  the memory used by the program grows. But when the
> work return to low level, the program  continues using the same amount of
> memory. If you use a suballocator, probably the memory used by the program
> decrease.

Doing this is the conservative choice taken by most malloc/free 
implementations. It however comes at a great cost in performance, 
especially when node-like containers are concerned.

The solution to this problem is to have several instances of pool 
allocators working independently, with the ability to free a whole pool 
and everything inside it at any time.
This is region-based memory management.