Anomaly in mpn_sqrtrem and mpn_rootrem
bodrato at mail.dm.unipi.it
bodrato at mail.dm.unipi.it
Tue Jul 7 08:28:45 UTC 2015
Ciao,
Il Lun, 6 Luglio 2015 11:28 pm, Torbjörn Granlund ha scritto:
> bodrato at mail.dm.unipi.it writes:
>
> ... yes, I know, we really need to improve also odd sizes...
>
> Perhaps one could simply wrap the current function in code which appends
> a zero limbs, calls the current code, and then right-shift the root by
> half the limb bitcount?
This is a description of the patch I pushed yesterday:
https://gmplib.org/repo/gmp/rev/87ba695c8878
But I do not really like it. We alloc-copy-shift to add a dummy limb, then
we call a code that allocs-copies-shifts to (virtually) add two more dummy
limbs...
Anyway, in general the code for sqrt (no-remainder) is faster now than it
was before. With code from revision 16716 (3 weeks ago) we got
time tests/devel/try mpn_sqrt
[...]
user 0m25.299s
Now we get:
time tests/devel/try mpn_sqrt
[...]
user 0m23.300s
> (One would possibly need to suppress such code for operands below a
> certain size, to avoid slowdowns.)
There are some slowdown only for sizes 15,16,31,32, i.e. when the size is
near a small power of 2.
Now, for small sizes, computing the 4th root with mpn_rootrem is slower
than calling mpn_sqrtrem twice. Maybe we should improve mpn_rootrem for
small sizes in general...
Regards,
m
--
http://bodrato.it/papers/
More information about the gmp-devel
mailing list