On Tue, Jun 5, 2012 at 3:38 AM, John Maddock <boost.regex@virgin.net> 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