Boost logo

Boost :

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
> > solution in terms of portability -- other compilers might have the same
> > problem vc8 has. One thing -- we might consider a function template
> > 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

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


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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at