Boost logo

Boost :

Subject: Re: [boost] [review] Multiprecision review results
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-08-05 04:41:18

Many thanks Jeff for managing the review!

> Performance
> --------
> Phil, the lone NO vote, lamented that the scope of the library was
> evidently beyond simple fixed-precision (e.g., 128-bit or 256-bit)
> integral
> types, which is his desired use case. Indeed, at least in an earlier
> version of MP, expression templates seemed to give a performance penalty
> relative to using the raw back-end types; in theory, expression templates
> should give no performance hit, but compilers just may not be there yet.
> In
> any case, several reviewers requested that the scope of the library be
> clarified up front in the documentation.

As noted in a recent post - the cost of wrapping a native type inside
mp_number should be close to zero now *when expression templates are off*.

When ET's are turned on, this will always IMO be slower, consider an
operator returning an expression template - it's basically returning a pair
of references (and larger objects still for more complex expressions), where
as say a wrapped integer is actually returning a smaller cheaper to copy
object in that case. So for a wrapped integer, returning the result by
value will always win out, and that's before you even consider the cost of
unpacking the expression template.

So, basically reserve expression templates for objects that are either large
and/or allocate memory: I'll try to make that clearer in the docs.


I have an open question for you all: I was planning on working on cpp_int
performance next, and trying to improve the computation geometry use cases.
Obviously that pushes back a potential release. The alternative is to
address all the issues relating to the front end first, and aim for an
earlier first release. Which would folks prefer?

Regards, John.

Boost list run by bdawes at, gregod at, cpdaniel at, john at