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

From: David Abrahams (dave_at_[hidden])
Date: 2003-12-21 11:29:43

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

    \ _
    /| |\ _
        /| |\

> Use it If you need it... "you never get something for nothing".

You have to pay in size of library source code, but aside from that,
yes, you can get "something for nothing".  It's the same sort of
thing that happens in large linear algebra problems when they are
"tiled" to stay in the cache.  You add a lot of complexity to the
library source code, but by dividing the problem strategically, you
get dramatic efficiency gains.

> Although you may/will come a great deal closer as compilers and the
> language itself evolve.  Yep I am thinking short term.... and from
> my own coding style. I remember the old days when MSVC1.0 took an
> inexhorable time to compile anything(40Mhz 386).It affects the way
> you go about things. These days I tend to use C+ on my compiler like
> an interpreted... not a style I recommend to anyone else.  I have
> looked at mpl vectors and lists for my physical quantity type.  I
> have rejected the idea(currently), because it is unnecessary
> complexity for my (current) needs.(need to learn,compile
> time...debug) I am using some metaprogramming and spent a small
> amount of time on trying to optimise compile times.  Even that
> smallish amount of metaprogramming Will affect compile
> times....non-boost critics will point this out to Me too.  (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'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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com