$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.