-
-
Notifications
You must be signed in to change notification settings - Fork 541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use PARI implementation of Frobenius morphism #35316
Conversation
As opposed to suggestions in the linked issue, it does not use a matrix method, although this could be implemented concisely using this snippet:
The linear method needs to cache O(d) field elements, whereas PARI field morphism are defined by the image of the single generator, using less memory. For practical field sizes, the difference remains small and both methods are vastly more efficient than exponentiation, except for extremely small characteristics or very large extension degrees. Performance numbers are as follows: for a 16-bit prime, the simple exponentiation is faster than PARI field morphisms only for degrees > 128.
|
4bad9d9
to
ad39dde
Compare
…lements PARI implements Frobenius morphisms as field morphisms defined by the image of the generator. Caching these morphisms requires O(degree) field elements in memory and computation requires O(sqrt(degree)) field multiplications instead of O(degree * log p) for the exponentiation method. For very small powers or very large extension degrees, the power method will be used for the p-th power Frobenius.
ad39dde
to
bd225fd
Compare
Updated with review comments and updated commit message (Brent-Kung complexity is sqrt(degree)) |
Documentation preview for this PR is ready! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. LGTM.
### 📚 Description Calling repeatedly PARI fffrobenius function involves redundant computations that can be avoided by reusing already computed powers. This is a follow-up to #35316 improving the performance of Frobenius on first call: ``` sage: p = next_prime(2**120) ....: K = GF(p**120, 'a') ....: x = K.random_element() sage: %time _ = [x.frobenius(i) for i in (0, 20, 40, 60, 80, 100)] Sage 9.8 CPU times: user 9.73 s, sys: 8 ms, total: 9.73 s Sage 10 beta 8 CPU times: user 6.84 s, sys: 194 µs, total: 6.84 s After patch CPU times: user 681 ms, sys: 0 ns, total: 681 ms When cached (10.0beta8) 30.9 ms ± 155 µs per loop (mean ± std. dev. of 7 runs, 10 loops each) sage: K = GF(5**240, 'a') ....: x = K.random_element() sage: %time _ = [x.frobenius(i) for i in range(240)] Sage 9.8 CPU times: user 1.72 s, sys: 1.12 ms, total: 1.73 s Sage 10.0beta8 CPU times: user 1.02 s, sys: 1.02 ms, total: 1.02 s After patch CPU times: user 219 ms, sys: 12 µs, total: 219 ms When cached (10.0beta8) 168 ms ± 391 µs per loop (mean ± std. dev. of 7 runs, 10 loops each) ``` ### 📝 Checklist - [x] The title is concise, informative, and self-explanatory. - [x] The description explains in detail what this PR is about. - [ ] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. URL: #35456 Reported by: Rémy Oudompheng Reviewer(s): Marc Mezzarobba
📚 Description
This pull request uses PARI
fffrobenius
andffmap
to implement the p-th power map for Finite fields using the PARI implementation (issue #4625).It does not seem necessary to implement a similar thing for the Givaro implementation (where exponentiation is very fast) or the NTL implementation (only for characteristic 2).
📝 Checklist