C implementation of mod_1_1
nisse at lysator.liu.se
Wed Mar 2 14:56:58 CET 2011
Torbjorn Granlund <tg at gmplib.org> writes:
> I suspect it was perhaps mainly your cps improvements for x86 and
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
> But it surely will be ignored then, even if inserted in some
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.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel