Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-29 18:08:11

On Sun, Jan 30, 2011 at 6:32 AM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> AMDG
>
> On 1/29/2011 1:18 PM, Dean Michael Berris wrote:
>>
>> On Sun, Jan 30, 2011 at 4:39 AM, Steven Watanabe<watanabesj_at_[hidden]>
>> Â wrote:
>>>
>>> On 1/29/2011 1:25 AM, Dean Michael Berris wrote:
>>>>
>>>> -- which means the VMM no matter what you do will
>>>> actually have to find the memory for you and give you that chunk of
>>>> memory. This means potentially swapping pages in/out. You limit this
>>>> likelihood by asking for page-sized and page-aligned chunks and using
>>>> those properly;
>>>
>>> Why?
>>>
>>
>> Why will page-sized/page-aligned chunks avoid the likelihood of
>> (unnecessarily) swapping pages in and out? Because if you didn't take
>> care that your data would spill over to page boundaries the amount of
>> pages you're touching is one more than you need to touch.
>>
>
> One more comment, and then I'm done with this thread.
> I agree that page-alignment will help reduce swapping.
> What I remain unconvinced about are the benefits of
> allocating only single pages.
>

Right.

When I say "allocate", I use it as in "ask a C++ allocator to give me
a chunk" -- as in call the alloca member of the allocator instance.

The thought really is prudence: ask only for what you need and make
the most of what you have.

In the string context: For concatenation nodes, laying it out in a
page-aligned/aware manner and packing as much of them in a single page
as possible is generally a good thing -- better than if you just
willy-nilly allocate from anywhere or without regard for page
boundaries. For block nodes, this means having a "usable block" that
can be shared by multiple strings and referred to by concatenation
nodes.

In general, since you cannot control the growth factor for heap spaces
generally from within a C++ application, using predictably sized units
(like page sizes worth of memory) for *segmented* data structures is a
good thing. Again if you knew beforehand that you need contiguous
memory *and* don't really care about page alignment then you don't
need this scheme.

When growing segmented data structures having a predictable
(preferably constant) growth characteristic or segment size is usually
a good approach. This requires cooperation from an allocator that
knows how to reserve/grow/shrink appropriately sized memory that is
again page-aligned for maximum efficiency.

HTH

FWIW, I'm done with this thread too now.

-- 
Dean Michael Berris
about.me/deanberris