C implementation of mod_1_1

[Niels Möller]

Torbjorn Granlund <tg at gmplib.org> writes:

> I suspect it was perhaps mainly your cps improvements for x86 and
> x86_64.

That should lower overhead on those targets. But it doesn't explain
lowered thresholds in, e.g., mpn/powerpc64/mode64/p5/gmp-mparam.h...

> You're measuring MOD_1_1P_METHOD even when mod_1_1 is natively in
> assembly.

Yes.

> But it surely will be ignored then, even if inserted in some
> gmp-mparam.h?

Yes, it's examined only in geeric/mod_1_1.c, which is not compiled if
there's a native implementation.

> Perhaps we should suppress the measuring, or at least avoid putting
> ignored parameters in the gmp-mparam.h files?

I think there's some value in measuring all available variants and warn
for anomalies such as an assembly implementation not being fastest. But I
have no strong feelings either way.

> Function pointers are not ubiquitously branch predicted, and therefore
> may cost a full pipeline delay.  And if-else statement like above will
> 100% predicted.

I was under the impression that function pointers were involved anyway.
But then I realized that I don't know how this works. Looking a bit
deeper, it seems we need to force mpn_mod_1_tune to call the right
function, so I'd have to put these ifs in generic/mod_1.c (under
TUNE_PROGRAM_BUILD) rather than in tuneup.c.

Regards,
/nisse

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.