Re: [boost] Re: Challenge: pool allocator

From: Michael S. Tsirkin (mtsirkin_at_[hidden])
Date: 2000-07-06 05:00:56

Hello!
Quoting r. Greg Colvin (greg_at_[hidden]) "Re: [boost] Re: Challenge: pool allocator":
> From: <mtsirkin_at_[hidden]>
> >
> > Another issue worth considering IMHO is the locality principle:
> > when you have a container (e.g. vector) and inside it
> > a pointer to allocated memory, you might want to try to
> > put the allocated chunk as close as possible to the original 
> > object itself, to reduce the amount of memory pages used.
> > 
> > We use a commercial memory management library that provides such 
> > allocator, but I know of no public domain implemntation that can do 
> > this.
> > Or testing shows that when memory usage is high, results can be 
> > imressive, performance-wise.
> 
> What is the interface to this allocator?  That is, how do you
> tell it that you want two objects to be on the same memory
> page?  Or does it figure this out for itself?
> 
> [...]

The library provides an overloaded operator "new" that 
accepts an additional parameter which is void* for
the object in the same memory page.
I do not know how it is implemented.

Allocator therefore just calls
    new (size,this)

as the allocator object is part of the container,
this will achieve the desired effect.

We have seen that this reduces amount of page faults 
significantly (depends on the application, of course,
but applications tend to do collection.begin and then go over
the collection, not save the iterator in some other location
in memory).

MST

-- 
This message content is not part of Intel's views or affairs
Michael S. Tsirkin
    >   Four things are to be strengthened: Torah,and good deeds,
    >   prayer and one's good manners (Berachoth)