[boost] Re: Re: Re: Re: Formal Review in progress

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-05-28 11:18:37

"Peder Holt" <peder.holt_at_[hidden]> wrote

> On 5/28/05, Arkadiy Vertleyb <vertleyb_at_[hidden]> wrote:
>
> > This workaround is much better than mine because it doesn't degrade vc8
> > preformance.  And it might be better than the original (before
workaround)
> > solution in terms of portability -- other compilers might have the same
> > problem vc8 has.  One thing -- we might consider a function template
instead
> > of preprocessor-generated values...
>
> Not quite sure how that should work.

instead of:

char (&value0)[...];
char (&value1)[...];
char (&value2)[...];
...
char (&value50)[...];

just have:

template<int n>
char (&value(mpl::int_<n>))[...];

But now I am thinkig this may re-introduce the original performance
problem...

> One more thing, I also tried modifying boost::type_of::vector a bit:
>
> struct vector_base {
>    char (&value0)[1];
>    char (&value1)[1];
>    char (&value2)[1];
>    ...
>    char (&value50)[1];
> };
>
> template<typename T=void>
> struct vector0 : vector_base {
> }
>
>
> template<typename P0,typename T=void>
> struct vector1 : vector_base {
>    char (&value0)[T0::value];
> }
>
> ...
> template<typename P0,..typename P49,typename T=void>
> struct vector50 : vector_base {
>   ...
> };
>
> template<class T>
> typename encode_type<vector0<>,T>::type typeof_result(const T&);
>
> This seems to make a ~20% improvement on the VC compilers at least
> (haven't tried GCC on this change yet)

Cool.

I originally thought that type_of::vector<> is just a temporary workaround,
until mpl::vector<> performance problem with GCC is fixed, but now I am not
so sure...  It was already about 20% performance improvement over
mpl::vector<> on VC7 (because operations were specialized directly rather
than their implementations, which resulted in fewer template
instantiations).  Now even better performance...

I think the Typeof library is intended to be very low-level, and as such,
deserves a fine-tuned custom compile-time sequence with no overhead that
can't be avoided by a generic solution.  The current implementation allows
to easily switch from one type of such a sequence to another, which
simplifies performance testing, and which may turn out useful if different
sequences turn out to be the best for different compilers.

I do think that we should keep the interface of the mpl::vector<>.

Again, something to think about after the review.

Regards,
Arkadiy