Boost logo

Boost :

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Marc Glisse (marc.glisse_at_[hidden])
Date: 2012-06-05 14:59:39


On Tue, 5 Jun 2012, John Maddock 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

Out of curiosity, what compiler/options? I know from similar experiments
that it can play a huge role, and only with the highest optimizations
(profile feedback and all) were the performances the same. In other cases
the abstraction penalty never disappeared.

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

Is this related?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938

By the way, compare is required to return int, but sometimes it would be
more convenient if I could use long (for the same reason you picked int
and not an enum {-1,0,1}). Or even double. Do you do anything with the
result of compare that works better because it is an int? I might even
want to use a proxy.

-- 
Marc Glisse

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk