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

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-05 11:04:19

On Tue, Jun 5, 2012 at 3:38 AM, John Maddock <boost.regex_at_[hidden]> wrote:

> 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...
>

Hasn't Eric had some issues with Boost.Proto not being fully inlined by
some compilers in the past (or maybe still in the present)? And/or having
to explicit decorate some Boost.Proto functions with some kind of "force
inline"?

- Jeff