Re: [boost] [Multiprecision] Benchmarking

Subject: Re: [boost] [Multiprecision] Benchmarking
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2012-06-15 05:41:58

Christopher Kormanyos wrote
> 
>>>>> - Expression templates make the code slower.
> 
> 
>> Hi,
>> I agree, the library should be able to decide whether expression
>> templates should be an improvement or not.
> 
>> A minor change in the library, defaulting the ExpressionTemplates
>> parameter to a trait depending on the backend could help to that.
>> The library could default to something reasonable, while the backend
>> developer could always provide a specialization.
>> Vicente
> 
> I like this idea. Unfortunately, I may not be the best one to program it,
> and I fear John would get stuck with it---if, that is, this turns out
> to be the way to go. So one would need to see what John thinks.
> 
> So Vicente, if I understand, you are saying that one might add
> more *intelligence* to the kind of object used as the template
> parameter for enabling/disabling the expression templates.
> 

Yea and not. This request was in order to make it clearer the meaning of the
bool parameter using something more domain specific.
 

> 
> Perhaps is it like the good idea you wrote on 31-May-2012,
> but takes it even one step further?
> 
> You wrote this, but it was for floats:
>> What about replacing the second bool template parameter by an
>> enum class expression_template {disabled, enabled};
>> which will be more explicit. That is
> 
>> Â  typedef mp::mp_number<mp::mpfr_float_backend<300>, false>
>> my_float;
>> versus
>> Â  typedef mp::mp_number<mp::mpfr_float_backend<300>,
>> mp::expression_template::disabled> my_float;
> 

Yes and not. This request was in order to make it clearer the meaning of the
bool parameter using something more domain specific.

The ExpresionTemplate parameter could be defaulted to e.g.

ExpresionTemplate = expression_template_trait<Backend>::value 

Where expression_template_trait could be defined with a defaulted value as

template <typename Backend>
struct expression_template_trait {
  static const expression_template value =
Backend::expression_template_value; 
};

Another defaulted value could also be possible, as disabled(or enabled) by
default

template <typename Backend>
struct expression_template_trait {
  static const expression_template value = expression_template::disabled; 
};
 
But I think a default expressed by the backend is a better default.

> But I also fear that it would take q bit of time to specify this kind
> of back-end parameter type.
> 
> Is it something one could add later, backwards compatibility
> being handled vie sensible default parameter?
> 
> 

Humm, we could do it later, but I don't think we could ensure backward
compatibility. IMO, if we consider it is a good thing, it should be included
before release as it doesn't implies too much work, we need just to define
which is the default of the trait.

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/Multiprecision-Benchmarking-tp4631293p4631326.html
Sent from the Boost - Dev mailing list archive at Nabble.com.