Re: patch for speed

> How many "users" will want to use tune/speed and at the same time not be > able to figure out that we alias mpz_legendre to mpz_jacobi? That alias > might not be documented, but tune/speed is "more undocumented". note also that since mpz_legendre only accepts odd primes as second argument, its

Re: hgcd1/2

t...@gmplib.org (Torbjörn Granlund) writes: > Conclusion: The HGCD2_METHOD 2 code in its current form is not useful on > any of our platforms. (Perhaps we should wait a few days more as not > all hosts have reported results yet.) Sounds good. Give it a few days, and delete if it still looks slow

Re: patch for speed

paul zimmermann writes: the benefit for the user is to be able to measure the speed of mpz_legendre. Since the documentation does not say that mpz_legendre is an alias for mpz_jacobi, I believe it is legitimate. How many "users" will want to use tune/speed and at the same time not be able

Re: hgcd1/2

ni...@lysator.liu.se (Niels Möller) writes: Maybe I'm confused. And I think tradeoffs are different for the double-limb and the single-limb loops. Or I am confused. I have mostly thought of div1, less of div2. For the single-limb loop, I think special handling of q == 1 means we avoid a

Suggested tune/tuneup.c patch

Below patch adds a helper function for tuning *_METHOD values, evaluated at some fix size. What do you think? Regards, /Niels diff -r ed6ddbb7a15b tune/tuneup.c --- a/tune/tuneup.c Tue Sep 10 00:00:35 2019 +0200 +++ b/tune/tuneup.c Tue Sep 10 21:29:34 2019 +0200 @@ -519,8 +519,8 @@ }

Re: patch for speed

> I'd like to understand the benefits of ./speed mpz_legendre first, since > I don't really see any. Currently, it's an alias for mpz_jacobi, and I'm > not aware of any concrete plans to change that. the benefit for the user is to be able to measure the speed of mpz_legendre. Since the documentati

Re: patch for speed

paul zimmermann writes: >Niels, > >> Wouldn't that patch call mpz_legendre (a, p) with p not prime? Which is >> invalid, but kind-of works *because* mpz_legendre is an alias for >> mpz_jacobi. > > good point. Do you want a new patch which ensures p is an odd positive prime? I'd like to u

Re: hgcd1/2

t...@gmplib.org (Torbjörn Granlund) writes: > ni...@lysator.liu.se (Niels Möller) writes: > > > That should in particular be true if the q = 1 code is removed from > > hgcd2, for machines with good multiplication throughput. > > Can we remove that for everything but HGCD2_METHOD == 2? It wou

Re: patch for speed

Niels, > Wouldn't that patch call mpz_legendre (a, p) with p not prime? Which is > invalid, but kind-of works *because* mpz_legendre is an alias for > mpz_jacobi. good point. Do you want a new patch which ensures p is an odd positive prime? Paul ___

Re: patch for speed

paul zimmermann writes: >> Adding a different symbol in the library for mpz_kronecker or >> mpz_legendre, would be an incompatible change to the interface. Not likely >> in the near future. > > ok, then what about the original subject (adding mpz_legendre to speed)? Wouldn't that patch call mpz_

Re: hgcd1/2

ni...@lysator.liu.se (Niels Möller) writes: > I believe METHOD 1 could almost always be pointless if METHOD 3's > straight line code is made really efficient. I'd guess so too. But benchmarks are better than faith alone ;-) I have a lot of faith in benchmarking! :-) > That should in pa

Re: patch for speed

> Adding a different symbol in the library for mpz_kronecker or > mpz_legendre, would be an incompatible change to the interface. Not likely > in the near future. ok, then what about the original subject (adding mpz_legendre to speed)? Paul ___ gmp-deve