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.
Fixes #427.
@Popeyef5 I don't think it is possible to significantly beat the "vanilla" implementation you have for your case in #427 of a very large prime. The reason is that I'm doing everything you're doing (and in the same way, ie in pure Python). But I'm also doing more -- argument verification, bounds checking in
FieldArray
, and other overhead when creating theFieldArray
andPoly
classes -- that I can't remove. However, I should be able to come close to the "vanilla" implementation whenufunc_mode="python-calculate"
.Now in cases where I can use Numba and JIT compile (ie
ufunc_mode="jit-lookup"
orufunc_mode="jit-calculate"
), I do outperform the "vanilla" version.I agree
galois
is not currently close in your use case. I found a few issues:lagrange_poly()
routine was theO(N^2)
version. That was replaced with the more efficientO(N*log(N))
version in Make convolution JIT function more efficient for prime fields #431.Poly
object overhead during the routine.Below are some performance examples.
Your example modified `test_427.py`
Example 1: JIT + lookup tables -- 50x
Example 2: JIT + explicit calculation -- 43x
Example 3: Pure Python calculation -- 1.13x