[boost] Re: new compile-time dimensional analysis and unitlibrary

From: Andy Little (andy_at_[hidden])
Date: 2003-12-22 05:39:12

"David Abrahams" <dave_at_[hidden]> wrote in message
news:usmjei16w.fsf_at_boost-consulting.com...
> "Andy Little" <andy_at_[hidden]> writes:
>
> > "David Abrahams" <dave_at_[hidden]> wrote in message
> > news:ullp7fa6l.fsf_at_boost-consulting.com...
> >
> >> Do you have an a priori reason to think that using the MPL is going
> >> to make compilation times longer than doing it some other way?
> >
> > Yes. IF the other way involves less metaprogramming of any kind.
>
> Well, that's not correct.  Various kinds of metaprogramming trade off
> against one another.  Template instantiation depth is very expensive
> on EDG compilers, for example.  If you *add* the right kind of
> metaprogramming constructs you can actually *reduce* compilation times
> by shifting the "amount" of metaprogramming (whatever that actually
> means)

I guess I meant  less work for the compiler... not what I said... sorry

>  to an idiom which is less expensive.  That's why it's important
> that MPL is a high-level library.  Things like built-in "loop
> unrolling" (which increases the "amount" of metaprogramming) can
> actually have a positive impact on the expense of instantiating a
> template, because a structure like:
>
>    \
>    /\
>     /\
>      /\
>       /\
>        /\
>         /\
>
>
> becomes, with an unrolling depth of 4:
>
>     \ _
>     /| |\ _
>         /| |\
>

OK  Just to clarify. I am assuming the tree is representing the compilers
internal database of instantiated templates.
Though quite how MPL achieves this...hmm...I dont think I want to know :-)

Now. ( I hope you dont mind me concentrating on my physical_quantities
type.( pqs for short)
(I am being short sighted and I appreciate you are talking in a general way,
but this is my current concern)
My physical-quantity type is designed as a 'replacement' for an inbuilt
type.
In my wind turbine application there are a large number of instantiations of
differing pqs scattered about, and operations
on them also instantiations. So I am Seriously interested if /how MPL or
metaprogramming generally can improve compile times.
(ie the pqs are up against inbuilt types... whatever I do I have assumed
compile times will be affected by using the type in preference to inbuilt
types.
So this is a big hurdle.. if I wanted the type to be accepted for general
purpose use.)
Here is the current 'abstract_pq' part of the type... similar idea to the
one in your Powerpoint presentation:
//Length,Time,Mass,Temperature,Current,Substance,Intensity
    template
    <
        int P_len  ,
        int P_time=0,
        int P_mass=0,
        int P_temp=0,
        int P_current=0,
        int P_substance =0,
        int P_intensity=0
    >
    struct abstract_pq{
        static int const pwr_length = P_len;
        static int const pwr_time = P_time;
        static int const pwr_mass = P_mass;
        static int const pwr_temperature = P_temp;
        static int const pwr_current = P_current;
        static int const pwr_substance = P_substance;
        static int const pwr_intensity = P_intensity;
    };

(There are also of course similar ops to plus<a,b>::type etc)
I have Assumed(not tested... yet) that this will be about the fastest way to
do this From a (general)compile-time point of view.
ie faster than a mpl::vector_c.  (I appreciate there are a lot of variables
,e.g compiler etc involved)
but what is your view... solely on compile times.(There is some implication
from the above that I am wrong and I would be very happy to be Wrong :-) )

I have also assumed (and now appreciate that I am wrong) that MPL was
primarily about creating complex structures(types) at compile time.
But  you seem to be saying that it has other useful purposes. If this is the
case.. When is this MPL book coming out? I want a good old fashioned book
perched on my knee (preferably one with a good binding so that all the pages
dont fall out)

> >  (Hence I
> > am awaiting your book. the MPL optimisation techniques will
> > presumably be applicable to other metaprogramming )
>
> Maybe.  While we'll probably cover some of this stuff, we're trying
> not to expose too many low-level details in the book.

That is Exactly what I want :-)...

> That's the
> point of using a high-level library.  It's the same reason that you
> won't find an STL book which goes into detail about the way that its
> algorithms are optimized for various kinds of iterators.  Just try to
> find a description of introsort in an STL book, for example.

I'm not even going to ask.

regards
Andy Little