Re: [boost] [Multiprecision] Benchmarking

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

On Thu, Jun 14, 2012 at 9:24 AM, Simonson, Lucanus J <
lucanus.j.simonson_at_[hidden]> wrote:

> Phil Endecott wrote:
>
> >But we can't write this:
> >   int64_t a, b ...;
> >   int128_t r = a * b;
> >because here a*b is a 64x64->64 multiply; instead we have to write
> something like
> >   r = static_cast<int128_t>(a)*b;
> >so that our operator* overload is found; but this operator* doesn't know
> that its int128_t argument
> >is actually a promoted int64_t, and it has to do an 128x64->128 or
> 128x128->128 multiply, requiring 8 or 16
> >32x32->64 multiplies.  The only chance of avoiding the extra work is if
> >the compiler can do constant-propagation, but I have my doubts about that.
> >Any thoughts?
>
> If you used an expression template for the multiply you could dispatch r =
> a * b; to a three argument multiply template function from within the
> assignment operator that would inspect the precision of each addend and the
> sum types and choose the algorithm that does minimal work with minimal loss
> of precision.  However, it would be a big effort and it wouldn't work if
> both arguments of the multiply were builtin types.  I'm not suggesting it
> is a good idea, it is just the first thing I thought of.  Calling
> multiply(r, a, b) directly might be a better idea.
>

As John has alluded to earlier (and I believe you concurred), he hasn't yet
found a satisfying design approach to mixed-type arithmetic (and I can't
blame him). I think it's reasonable to leave this unresolved at the moment,
but I guess it's up to the reviewers if this is a deal breaker. I think it
does unfortunately limit its applicability in the computational geometry
realm where your expression tree is often of bounded height (at least in my
experience), hence you want to be able to use arithmetic types of varying
precision depending on the level of the tree.

This should really be done in the vector unit, and that will become even
> more true as better vector units come out.  We need a standard mp
> specification so that the compiler/hardware vendors will provide library
> implementations that take advantage of existing and future hardware to
> accelerate their use.  Boost can't be expected to provide an optimal
> multi-precision type that makes full use of the hardware, but we can be
> expected to come up with an interface that will help the standard committee
> specify a standard mp.  The hardware vendors will happily compete to
> provide the highest possible performance implementation of the standard and
> the code that uses that hardware will be portable.
>

Vectorized arithmetic is the way to go for maximum performance.

- Jeff