Re: [boost] [Multiprecision] Benchmarking

Subject: Re: [boost] [Multiprecision] Benchmarking
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-06-15 02:48:44

>>>> - Expression templates make the code slower.


>>> For sure - expression templates are about eliminating temporaries - if
>>> the temporaries are cheap (cpp_int containing small values and no
>>> dynamic memory allocation) then there's no benefit and probably a hit
>>> from bringing in all that machinary.  That's why expression templates
>>> are disabled for the fixed size cpp_int typedefs.

>> I'd like to propose an alternate viewpoint: in the context of numerics,
>> expression templates are about delaying evaluation to gather more
>> context, so you can perform the computation more efficiently.  From that
>> point-of-view there's absolutely no reason that they should ever make
>> code slower.  Just generate the appropriate code for the types and
>> expressions involved.

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

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;

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?

Best regards, Chris.