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.
>> 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk