Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-06-05 06:38:27

>>Let us know as soon as you have some results.
>
> Tested the time taken to run through all the Boost.Math Bessel function 
> tests, with type double, real_concept (a simple wrapper around double from 
> Boost.Math's test suite) and mp_number<float_backend<double> > (a trivial 
> mp_number backend that wraps a floating point type):
>
> Time for double = 0.0157549 seconds
> Time for real_concept = 0.0166421 seconds
> Time for float_backend<double> = 0.0408635 seconds
> Time for float_backend<double> - no expression templates = 0.0253047 
> seconds
>
> So as you can see, expression templates are a dis-optimization for such 
> simple types, and even without them you take a noticeable hit: I'm a 
> little disappointed by this, but not that surprised, mp_number is a rather 
> heavyweight solution for lightweight types if you see what I mean.
>
> In any case I'll have a look at the assembly to see if there are any 
> obvious non-optimizations going on.

>From a quick casual look it appears as though the extra time is going in 
functions not expanded inline - that's certainly the case for the expression 
template unpacking code.  Seems like there may be some small opportunity for 
optimization of the comparison operators as well (i.e. not evaluating in 
terms of a compare() function).  However, that latter case is only 
appropriate for exceptionally lightweight backends, for most typical 
extended precision backends, non of this will make the slightest difference 
at all...

John.