[boost] Re: Re: Re: Re: Smart pointers: One more implementation +question

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-02-06 03:00:23

On Thu, 06 Feb 2003 03:20:14 +0100, Dave Abrahams wrote:

> On Wednesday, February 05, 2003 3:53 PM [GMT+1=CET], Daniel Frey
> <d.frey_at_[hidden]> wrote:
> 
>> > Which compiler?  How were you using intrusive counting?
>>
>> I used some benchmark code which compared several smart-pointers (my
>> own and the boost version). I had a simple class
>>
>> #define LOAD int dummy[2];
>>
>> struct A0 { LOAD };
>> struct A1 : boost::counted_base { LOAD };
>>
>> The size of A0 is 8 bytes, the size of A1 was 20 bytes for the Intel
>> (6/7) compiler and 44 bytes for the GCC (3.2.1). If you like, I can
>> send the complete code.
> 
> No need.  The size of A1 should be 16 bytes on most 32-bit
> architectures, but there's nothing fancy going on here.  If compilers
> are making bigger classes it's just
> 
> GCC-3.2.3 on x86 reports:
> 
>     sizeof(A0) = 8
>     sizeof(sp_counted_base) = 16
>     sizeof(A1) = 24
> 
> They didn't change the object layout, so I'm a little shocked at your
> figure of 44 bytes.  With threading disabled, it's:
> 
>     sizeof(A0) = 8
>     sizeof(sp_counted_base) = 12
>     sizeof(A1) = 20

This is the result of the Intel compiler I tested, thus I think my code is
OK. Still the GCC 3.2.1 reported 44 bytes. Your results are for the GCC
3.2.3 which makes me hoping the best. If I find the time, I will fetch the
GCC 3.2.2 and check it again.

> This is as small as you could expect it to be given the requirements. In
> any case, that method of making intrusive pointers has been deprecated,
> and replaced with a new one which doesn't add more than the size of the
> count to your object (of course, you pay for a separately allocated
> count object which is 12/16 bytes depending on threading).

Maybe I'm too worried about that, but I would guess that this can make a
difference. Intrusive counting saves allocations, which is one of it's
biggest benefits, having to allocate small objects as a side-dish is
something I don't want from a smart pointer.

I aim for a smart pointer which is 4 bytes and adds another 4 bytes to the
intrusivly counted object - no more. AFAICS boost cannot offer this with
the current design. Loki is much better, but some first benchmarks show
that it has some performance problem in certain cases: Swapping some
pointers around was ~10 times slower than both boost's pointers and ~20
times slower than my smart pointers. I will keep analysing it and report
more results later.

>> Because it addresses the same problems. I don't want to insult anyone
>> here by taking away users or (even worse) developers.
>
> I don't think anyone will be insulted.  Nobody around here is jealously
> guarding development resources, AFAICT.
>
>> Although I am pretty sure
>> I can do that even if I intend to, but this impression is what I would
>     ^^^ "can't?"

Of course. (Would this be a candidate for the typo-of-the-year? ;)

>> like to avoid.
> 
> Don't worry about it.  The more discussion, the more better.
>
>> > > Andrei has done a lot of good things not just by creating them, but
>> > > also by writing a book about it.
>> >
>> > Agreed, of course.  What I mean is that I'm not completely satisfied
>> > with the implications that his MI design has for smart pointer size
>> > on real-world compilers.
>>
>> And size does matter - the smaller the better ;) Which reminds me to
>> add Andrei's PBSP to my benchmark and check some stuff. The problem for
>> me is that I know the importance of documentation, but I'm not good in
>> writing it :o)
> 
> No offense intended, but that's a bit of a cop-out.  If you're going to
> be the one asking for better comprehensibility, it isn't really fair to
> plead "I'm bad at documentation."

That I'm not good at writing documentation doesn't mean I won't do it.
It's just something that takes me longer than others (comparing it with my
colleagues) and as I am not a native english speaker, the result may be a
weird way of expressing things :) And this is the reason why I always
prefer more readable code over more documentation.

Regards, Daniel