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