udiv_qr_4by2

[Marco Bodrato]

Ciao,

Il Mer, 4 Settembre 2019 7:19 am, Marco Bodrato ha scritto:
> Il Mar, 3 Settembre 2019 11:00 pm, Niels Möller ha scritto:

>> I think it's supposed to be useful on architectures with high mul
>> throughput but poor latency.

> We will see if something more changes with this further optimisation.

We did not jet have the history preservation feature for devel/thres/
pages, but I saved the one about DIV_QR_2_PI2_THRESHOLD.

Before the last change to udiv_qr_4by2 we had 18 numeric measured
thresholds (I mean != MP_SIZE_T_MAX  /* never */), in the range 10-39; now
we have 25, in the range 7-29.

In particular I notice the following results.

Before:
zen-pc-linux-gnu	32 	matigentoo64.gmplib.org-stat 	23
zen-pc-linux-gnu	64 	matigentoo64.gmplib.org-stat 	39
zen-pc-linux-gnu	64 	pirigentoo64.gmplib.org-stat 	∞
zen-pc-linux-gnu	64 	surigentoo64.gmplib.org-stat 	∞
zen-pc-linux-gnu	32 	pirigentoo64.gmplib.org-stat 	∞
zen-pc-linux-gnu	32 	surigentoo64.gmplib.org-stat 	∞

After:
zen-pc-linux-gnu	32 	matigentoo64.gmplib.org-stat 	7
zen-pc-linux-gnu	64 	matigentoo64.gmplib.org-stat 	15
zen-pc-linux-gnu	64 	pirigentoo64.gmplib.org-stat 	24
zen-pc-linux-gnu	64 	surigentoo64.gmplib.org-stat 	25
zen-pc-linux-gnu	32 	pirigentoo64.gmplib.org-stat 	∞
zen-pc-linux-gnu	32 	surigentoo64.gmplib.org-stat 	∞

As we can see, on mati, the thresholds was more than halved, on piri and
suri, with the 64-bits ABI, the new code can be used...

But my main observation is that mati (zen2, according to
https://gmplib.org/devel/testsystems.html) wants some values, while piri
and suri (zen and zen+) wants very different ones. That's true for other
thresholds too. But they all share the same gmp-mparm.h file. Maybe it's
worth distinguishing them somehow with our config.guess?

Ĝis,
m

-- 
http://bodrato.it/papers/