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

From: Peder Holt (peder.holt_at_[hidden])
Date: 2005-05-28 09:40:46

On 5/28/05, Arkadiy Vertleyb <vertleyb_at_[hidden]> wrote:
> "Peder Holt" <peder.holt_at_[hidden]> wrote
> 
> > On 5/28/05, Arkadiy Vertleyb <vertleyb_at_[hidden]> wrote:
> > > "Peder Holt" <peder.holt_at_[hidden]> wrote
> > >
> > > > I did some tests on VC8 beta, and it compiles the testcase in half the
> > > > time compared to the present implementation of typeof_impl. As far as
> > > > I have been able to test, it also works around the compiler bug for
> > > > VC8 discussed earlier.
> > > >
> > > > Here is a more detailed sketch of the proposed solution:
> > > >
> > > > namespace boost {namespace type_of{
> > > >     template<typename T>
> > > >     struct encode_result {
> > > >         typedef typename encode_type<BOOST_TYPEOF_VECTOR(0)<>,
> > > > T>::type encoded_type;
> > > >         typedef typename mpl::size<encoded_type>::type size;
> > > >         char (&value0)[...];
> > > >         char (&value1)[...];
> > > >         char (&value2)[...];
> > > >         ...
> > > >         char (&value50)[...];
> > > >     };
> > > >
> > > >     template<class T>
> > > >     encode_result<T> typeof_result(const T&);
> > > > }}
> > > > #define BOOST_TYPEOF_AT(n, expr)
> > > > sizeof(boost::type_of::typeof_result(expr).BOOST_PP_CAT(value,n))
> > >
> > > Interesting... Let me guess:
> > >
> > > char(&value2)[mpl::at<encode<T>::type, mpl::int<(2 < size) ? 2 : 0>
> > > >::type::value]; //?
> >
> > Yep :)
> >
> >         char(&value2)[mpl::at<encoded_type,mpl::int_<(2 < size::value)
> > ? 2 : 0>
> > >::type::value];
> 
> Than there is no magic here :-)
> 

None intended :)

> You just re-introduced the simple type optimization I removed to workaround
> the vc8 problem.  Cutting performance in half was the result I got.
> Apparently in this simpler context vc8 is able to handle this.

Yep. I got no significant performance boost on VC7.1 or GCC with the
new version.

> 
> 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.

> 
> Althouth I believe this change _should_ be applied, along with the change
> that allows to remove _TPL, let's not make these changes now, and consider
> this more carefully after the review.

Agreed.

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)

Regards,
Peder

> 
> Regards,
> Arkadiy
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>