On 19/08/2021 02:43, Neill Clift via Boost-users wrote:
Hi,
In my program I see a lot of time taken up by add/subtract_unsigned. I have a couple of thoughts on the code:
Carry propagation outside the range of the smallest number can be improved:
for (; i < x && carry; ++i)
carry = ::boost::multiprecision::detail::addcarry_limb(carry, pa[i], 0, pr + i);
Maybe this:
for (; i < x && carry; ++i)
carry = ::boost::multiprecision::detail::addcarry_limb(0, pa[i], 1, pr + i);
This generates just an inc on my machine but unfortunately it doesn’t eliminate the loads and stores. I think on average the carry chain must be small though.
You have the same situation on subtract.
add_unsigned and subtract_unsigned are inconsistent at the tail end after carry propagation:
add_unsigned:
if (i == x && carry)
{
// We overflowed, need to add one more limb:
result.resize(x + 1, x + 1);
if (result.size() > x)
result.limbs()[x] = static_cast
(1u); }
else
std::copy(pa + i, pa + x, pr + i); ß- if I == x we do the copy. We also do the copy even if the output and input overlap
subtract_unsigned:
// Any remaining digits are the same as those in pa:
if ((x != i) && (pa != pr)) ß------ we do these checks here and avoid the copy
std_constexpr::copy(pa + i, pa + x, pr + i);
I am seeing a lot of time being used by that general copy above in add_unsigned when it can be avoided.
This stuff is totally awesome and works well in my program. So thanks for working on this stuff.
Thanks Neill, it might be a few days at best before I can look at this in detail, I wonder could you either file a bug report or a PR at https://github.com/boostorg/multiprecision/ and then this won't get lost. Thanks!! John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus