[boost] Re: Re: Re: Re: Re: partial<> proposal

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-02-25 22:08:36

Fernando Cacciola wrote:

[...]

> That would have to be _measured_; my guess is that it could be twice
> slower, specially considering that I don't think boost sources will
> ever include assembly
> code; it's a portability nightmere.

I've just generated some code, and the compiler can even optimize more when
the parameter of operator [] is compile-time constant:
    0x8048606 <main+6>: movsbl 0xffffffff(%ebp),%eax
    0x804860a <main+10>: shr    $0x3,%eax
    0x804860d <main+13>: add    $0xfffffff8,%esp
    0x8048610 <main+16>: and    $0x1,%eax

The only thing that would not be portable up to now is the number of bits in
a char (8).  I do not wish to include assembler code directly, what I meant
was the "generated" machine code by the compiler.

>>> So, what are you trying to optimize with this bool array?
>>> and most importantly, why do you feel that such optimization is
>>> needed? Consider that gaining storage, say 31 bits, per optional<>
>>> will incurr in
>>> a significant overhead, so in order to think that the gain is needed
>>> you need to weight size/speed benefits.
>>> This sort of things are typically considered only afer some
>>> benchmarks shown the need for the optimization.
>>
>> Even tough array<bool> is not optimized, the boolean values will
>> follow
> each
>> other and will not waste any space between themselves.
>>
> Yes, though I still can't see if this would be _needed_.

Well boost::type_with_alignment<> would be more meaningful in optional<>.
Also I am pretty sure the number of optional<> instances will be greater
than 1.  Placement operator new will be able to deal with external
initializations also.

I have to take a break... ;)

Philippe A. Bouchard