mpl and pqs (physical quantities library)
Hi, Having now spent some time porting my pqs library http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html over to boost, I am currently of the opinion that using mpl is not really practical for use with the pqs library. The main issue is regarding the large amount of types created behind the scenes by the mpl library. This is not acceptable in pqs because pqs uses a large number of parameters per quantity. The VC7.1 compiler is now frequently coming up with an fatal error message 'out of keys' during compilation of tests. For comparison this wasnt a noiceable problem in the non-boost version Obviously for the library to be remotely useable I need to be as sparing as possible with compiler resouces, allowing the user as much room to work as possible. In order for the pqs library to be practical I need to use a family of types for the dimension parameters that is designed with great care with respect to the total number of types created behind the scenes. Even then I need to acknowledge the issue of use of compiler resources by the library in the documentation. An example niggle regarding the mpl arithmetic operations , that they each use 5 parameters for e.g. addition whereas minimally only 2 are required. This also adds to the bloat for example. This is a particlar problem in the pqs library. Another issue with mpl concerns the fact that mpl doesnt deal in types. This is a problem when trying to register types in conjunction with BoostTypeof . .. What types to register ? (This is only a problem because the lack of an inbuilt typeof operator in C++). I'll certainly leave the current version of boost::pqs around (pqs_3_0_1 now in the vault in Physical Quantities Units directory) . I am aware that the situation could be improved slighltly for example by not allowing conversions from rational types to integral types, though the problem would still remain in lesser form) I hope that pqs-3-0-1 will answer the question why I have opted not to use mpl in the implementation in the next version. regards Andy Little
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little | Sent: 08 January 2006 20:10 | To: boost@lists.boost.org | Subject: [boost] mpl and pqs (physical quantities library) | Having now spent some time porting my pqs library | | http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html | | over to boost, I am currently of the opinion that using mpl | is not really practical for use with the pqs library. Well we always had fears about the compute cost of all units systems, but this is useful, if depressing, news. 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? Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html
"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
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
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.
The compilation overhead imposed by Boost.Typeof comes in two flavours: 1) Time necessary to deduce type, when requested. A few things were done in the past to reduce it, including using our own compile time vector instead of mpl::vector (gave about 2.5 times increase in performance; this is very typeof-specific, though, and is related to element access by index, where index is known at preprocessing time). However, we'll never be able to completely eliminate this overhead, and it is especialy noticable for complicated types -- too many templates get instantiated; 2) Time necessary to just include the typeof stuff. This is currently spent mainly on generating definitions of our vector. This is especially painful when LIMIT_SIZE is set to a larger number, to allow for deducing of more complicated types. I think, once I commit the code recently provided by Tobias (and this should happen very soon, probably this evening), this problem will be mostly remedied. So, when you estimate the effect of the Boost.Typeof on the compilation time, please distinguish between per-file, one time overhead, and per-type overhead. This is important in order to decide how to address the issue. Regards, Arkadiy
participants (3)
-
Andy Little -
Arkadiy Vertleyb -
Paul A Bristow