Re: [boost] [Multiprecision] Benchmarking

Subject: Re: [boost] [Multiprecision] Benchmarking
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-14 14:09:48

On Thu, Jun 14, 2012 at 10:51 AM, John Maddock <boost.regex_at_[hidden]>wrote:

> - Expression templates make the code slower.
>>>
>>>
>> Hmmm...John: comments?
>>
>
> As I mentioned, thay add a non-trivial amount of housekeeping to figure
> out how to best evaluate the expression template.  If temporaries are
> expensive, then this is a big win, if they're cheap (cpp_int with small
> values), then it's a small hit.
>
>  I think I understand the motivation for sign-magnitude for variable-length
>>> representation, but I don't see any benefit in the case of e.g.
>>> mp_int128_t.
>>>
>>>
>> John, perhaps this is something that can be configurable?
>>
>
> Sign magnitude and 2's complement types mostly require completely
> different algorithms, besides the old 2's complement code is *mostly*
> slower as all the limbs are always used.
>
>  I wonder also if there is a non-negligible penalty for abstracting all
>> backend operations as, essentially, op-assign operations, as in "x = y +
>> z", it seems one must loop twice, once over, say, y and x to effect "x =
>> y", then once over x and z to effect "x += z".
>>
>
> That isn't what's happening here - the library can - if the backend
> chooses to support it via the "optional" part of the backend requirements -
> support out-of-place operations as well as inplace ones.
>
> In that case x = y + z doesn't involve copying followed by addition, it
> just does the addition direct.  However, for more complex expressions, you
> may well get "copy-followed-by-inplace-op" if that avoids a temporary.
>  This is normally a win, but there may be a case (cheap temporaries) where
> it's a dis-optimization.
>
> Basically, it's difficult to be all things to all people...
>

Of course, and that all makes sense, thanks for clearing the above up!

- Jeff