New mid-range backend and dispatch code for polynomial multiplication - #2824
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This large PR does a few related things:
Take the packed-mpn classical+Karatsuba polynomial multiplication code from the
mpn_modmodule, move it tompn_extras, optimize it, and generalize it to signed coefficients and unbalanced sizes. This multiplication code is now usable by bothmpn_mod_polyandfmpz_poly, and we addfmpz_poly_mul_mpn/fmpz_poly_mulmid_mpnthat convert to packed mpn format internally.Also adds
fmpz_poly_mul(mid)_toom_karatsuba-- recursive Karatsuba withtoom_scalaras the basecase.Improve and consolidate the
fmpz_poly_mul*andsqr*algorithm dispatch. All multiplications (mul,mullow,sqr,sqrlow,mulmid) now go through_fmpz_poly_mulmid. This dispatcher fixes some inaccuracies in the previous tuning and adds use ofmpn,toom_scalar,toom_karatsubaandclassical_fft_smallwhere these win.As a result of the refactoring,
_fmpz_poly_muland_fmpz_poly_mullownow accept their arguments in either order. Several callers have been simplified accordingly.The bulk of patch is thousands of lines of generated kernel mpn code: m x n limb unsigned and signed dot products and basecase polynomial multiplication routines. The dot products are meant to be reusable for other things. Note that these kernel routines very likely could be optimized by generating x86-64 assembly instead of C.
To compensate a bit for the added code, all the
fmpz_poly_mul*_karatsubafunctions are removed. These were completely obsolete; they are always slower thantoom_karatsubaormpn.The cyclotomic multiplication code in the APRCL module is also refactored and optimized.
Developed using several Claude models, mainly Fable 5, Opus 5 and Fable 5.1.
Performance impact
Gives more than a 2x speedup for
fmpz_polyarithmetic if you happen to do lots of short to medium length multiplications exactly in one of the sweet spots for the new algorithms (~100-1000 bits formpn; several thousand bits and up fortoom_scalarandclassical_fft_small). On realistic, complex tasks one is more likely to see a 5-10% speedup. Operations on very short polynomials with small coefficients and short sparse polynomials can get slightly slower.Speedup on tests/examples
Very noisy, best of 5 timings, take with a grain of salt.
The
fqmodule test slowdown is real, but I think it's not necessarily representative of real usage (note thatfq_polyandfq_mattests got faster).Speedup for
fmpz_poly_mulSpeedup x 100 to multiply two length-n polynomial with randbits(bits) coefficients, e.g. 123 means the new code is 1.23x faster.
Speedup for
fmpz_poly_mullowLength n inputs, product truncated to length n.
Speedup for
fmpz_poly_sqrSpeedup for
fmpz_poly_sqrlowSpeedup for
fmpz_poly_mulmidBalanced mulmid window: 2n x n -> [n, 2n)
Speedup for APRCL
Time to call
fmpz_is_primeon nextprime(2^(bits+1)/3):