Re: [boost] mpl and pqs (physical quantities library)

From: Andy Little (andy_at_[hidden])
Date: 2006-01-09 08:17:54

"Paul A Bristow"  wrote

> Well we always had fears about the compute cost of all units systems, but
> this is useful, if depressing, news.

I'd like to emphasise that its specifically use of mpl constructs  such as
sequence that is the problem. Sequence theoretical advantage is that it is
length adjustable, but it is very expensive in compiler resources  because of
that.  I now think that using mpl is where many boost units libraries get bogged
down in practise... as I am currently, but only temporarily I hope ;-)

I would be keen if possible to use arithmetic functions such as mpl::plus, but
even here it is not optimal because the plus function uses 5 parameters  , where
I cant ever  use more than two. I also question the trend to use
mpl::plus<int_<1>,int_<2> > over simple 1 +2 in many cases.
As an example of the problem lets take an addition of two quantities. In current
case (pqs_3_0_1) each quantity is comprised of seven rationals , each rational
of two integral_constants. That is at minimum 42 uses of mpl::plus, now with a
total of 210 parameters per addition!
In each operation on two quantities these are the sort of entities that need to
be constructed per operation if I use mpl( Actually many many more in practise).
Using a custom rational and not using a sequence as a container I can get this
down to 14 parameters in an addition function.  That 15 % or so of the absolute
minimum baggage using mpl., much less than that in practise.

If anyone wants to dispute these figures then please do not feel shy....

I already have previous  versions of pqs where the compile time is very
reasonable and the use of compiler resources is much reduced compared with the
current boost version (pqs_3_0_1), so I intend to base the next boost version on
that and make it even simpler than that if possible.

> Now that MS VS 8 is widely available, free even, does anyone have an idea if
> VS8 is any more efficient (or has bigger tables allocated)?
>
> It is becoming clearer to me that a proper language 'typeof' is a really
> high priority, and perhaps we just have to wait for this?

I dont think it will happen any time soon.
In VC8 I believe that there is no efficient typeof facility,whereas due to a
fluke of the compiler there is in VC7.1.
I  shall have to make use of Boost.Typeof optional in the next version of pqs
too in order to allow user to decide whether they want to use it and also to
monitor the effect on compilation times.

regards
Andy Little