Re: [boost] lifetime of ranges vs. iterators

Subject: Re: [boost] lifetime of ranges vs. iterators
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-03 14:39:50

On Wed, Sep 3, 2008 at 7:21 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> on Wed Sep 03 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
>
>>
>> Do you think we are breaking the iterator abstraction? How? Or I've
>> misunderstood the question?
>
> Well, if we add "Factorable" or something like it, the iterator
> abstraction gets broken down into smaller bits for the purpose of
> storage, complicating some code [like a generic range for example ;-)]
> and it imposes an extra coding duty on writers of high-quality iterator
> adaptors.  I'm asking if its worth it.
>
>> We are simply trying to come up with a simple and clean trick to keep
>> iterator size under control.
>
> Really?  IIUC so far we're only discussing compressing the size of
> ranges, unless we're willing to pay for indirection inside of iterators
> (I'm not).

But iterators like filter_iterator that need to know iteration
boundaries, can store a range instead of an iterator, so they can
benefit from the compression.

>
>>>> I'm interested in using dynamic iterators in the near future for code
>>>> decoupling
>>>
>>> You mean, like, any_iterator?
>>>
>>
>> Yes.
>>
>>>> and It would be a pity if these ranges couldn't fit in a small object
>>>> optimization buffer.
>>>
>>> Do you know how big that target ("small object optimization buffer") is?
>>
>> I'm going to implement my own any_iterator, so I'll make the buffer
>> big enough for the average iterator size.
>
> Oh, that's not the small object optimization.  The SOO is only done by
> compilers: it means passing small objects in registers instead of on the
> stack.
> http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/323704.aspx
> IIUC you're talking about the too-specifically-named "small string
> optimization."

Ah, ok, I also saw it begin called small buffer optimization. I
confused object with buffer.

>
> I don't understand why you would implement any_iterator yourself when
> there are so many extant implementations, but maybe it's none of my
> business.
>

Mostly for experimenting. I'll might end up using something third
party in real code.

>> Currently the iterators I use are often over 400 bytes, which is a bit
>> to big :), thus the need to squeeze their size down as much as
>> possible. A hundred bytes could be enough [1].
>
> Again, have you measured?
>

If you mean the size, yes, I've measured it. If you mean my assertion
that 100 byte SBO may be optimal, then I wont' let facts interfere
with my opinions :)

Now, honestly, I'm trying to rationalize the fear that I had for a
while that complex iterator adaptor sequences really can grow large.
For example, the current filter_iterator double its size at every
stacking. If you couple it with a relatively heavy predicate, the
stack usage might start to really matter. On heavy threaded
applications, stack usage is a somewhat limited resource.

-- 
gpd