Improved binvert algorithm
marco.bodrato at tutanota.com
marco.bodrato at tutanota.com
Thu Jul 2 16:25:01 CEST 2026
Ciao,
2 lug 2026, 10:48 da tg at gmplib.org:
> Niels Möller <nisse at lysator.liu.se> writes:
>
> E.g., the decade old Intel Atom processors seem to lack mul pipelining
> (if I read https://gmplib.org/~tege/x86-timing.pdf correctly, 18
> cycles). Looks like there's at least one atom machine, "glm", in the gmp
> farm that could be used to test performance. Any other examples?
>
I have an Atom:
$ ./config.guess
atom-pc-linux-gnu
$ cat /proc/cpuinfo |grep name|head -n 1
model name : Intel(R) Atom(TM) CPU N570 @ 1.66GHz
In 2022 I wrote some lines of code to be added into tune/modlinv.c,
I also wrote a binvert_limb_pipe somehow similar to what David proposes.
So, I changed binvert_limb_pipe to the new proposal and I pushed the patch.
On that atom processor I get$ build/tune/speed -c -r -s1 -p1000000000 binvert_limb binvert_limb_sec binvert_limb_pipe binvert_limb_uintfast
overhead 8.05 cycles, precision 1000000000 units of 6.52e-10 secs, CPU freq 1534.49 MHz
binvert_limb binvert_limb_sec binvert_limb_pipe binvert_limb_uintfast
1 108.62 0.8056 1.2223 #0.7040
This means that on that CPU, the new sequence is slower (time+22%) than the current,
the fastest option (-30%) is the current, but using initially UHWtype instead of mp_limb_t.The _sec_ option (with fewer multiplications) is reasonably fast
because of the use of UHWtype there too.
On a low end ARM64 processor I have
$ ./config.guess
armcortexa53-unknown-linux-gnu
$ cat /proc/cpuinfo|grep -E Hardware\|Processor
Processor : AArch64 Processor rev 4 (aarch64)
Hardware : sun50iw1p1
$ tune/speed -r -s1 -p100000000 binvert_limb binvert_limb_sec binvert_limb_pipe binvert_limb_uintfast
overhead 0.000000007 secs, precision 100000000 units of 1.00e-09 secs, CPU freq unknown
binvert_limb binvert_limb_sec binvert_limb_pipe binvert_limb_uintfast
1 0.000000031 1.0277 1.1353 #0.8056
But on my (quite old anyway) laptop, the proposed sequence is the fastest.
$ build/tune/speed -r -c -s1 -p1000000000 binvert_limb binvert_limb_sec binvert_limb_pipe binvert_limb_uintfast
overhead 5.26 cycles, precision 1000000000 units of 5.28e-10 secs, CPU freq 1895.52 MHz
binvert_limb binvert_limb_sec binvert_limb_pipe binvert_limb_uintfast
1 29.25 1.0809 #0.6998 0.9984
and on shell too:
$ /var/tmp/bodrato/gmp/hg/build/tune/speed -r -c -s1 -p1000000000 binvert_limb binvert_limb_sec binvert_limb_pipe binvert_limb_uintfast
overhead 4.87 cycles, precision 1000000000 units of 2.86e-10 secs, CPU freq 3500.17 MHz
binvert_limb binvert_limb_sec binvert_limb_pipe binvert_limb_uintfast
1 28.39 1.0919 #0.6940 1.0000
Anyway, it seems like a good idea to get rid of the table
Ĝis,m
More information about the gmp-devel
mailing list