Lagrange evaluation performance improvements#1409
Lagrange evaluation performance improvements#1409akoshelev merged 3 commits intoprivate-attribution:mainfrom
Conversation
There is really no reason for taking an iterator, just makes things worse for the compiler
rustc didn't optimize the `eval` function and ended up doing 131072*32*992 loop iteration per Lagrange compute. For some unknown reason to me, optimizer works only if we operate on integers, not on fields. Maybe modulo reduction is to blame
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1409 +/- ##
==========================================
- Coverage 93.46% 93.14% -0.32%
==========================================
Files 223 225 +2
Lines 38456 38568 +112
==========================================
- Hits 35944 35926 -18
- Misses 2512 2642 +130 ☔ View full report in Codecov by Sentry. |
akoshelev
changed the title
| // Staying in integers allows rustc to optimize this code properly | ||
| // with any reasonable N, we won't run into overflow with dot product. | ||
| // (N can be as large as 2^32 and still no chance of overflow for 61 bit prime fields) | ||
| debug_assert!( | ||
| F::PRIME.into() < (1 << 64), | ||
| "The prime {} is too large for this dot product implementation", | ||
| F::PRIME.into() |
There was a problem hiding this comment.
We are multiplying two field values and then summing. I'd say that the conservative requirement is 2 * F::BITS + N.next_power_of_two().ilog2() <= u128::BITS.
There was a problem hiding this comment.
that's right, I think this assertion just assumes N being reasonable and the second argument of this expression negligible compared to F::BITS. I don't mind changing it, the reasoning behind this was just to optimize for readers
There was a problem hiding this comment.
I don't think what I said was correct here - I did go over the math again and we can't sustain
It turns out the original check was wrong estimating overflow conditions
3 participants
rustc didn't optimize the
evalfunction and ended up doing13107232992 loop iteration per Lagrange compute.
For some unknown reason to me, optimizer works only if we operate
on integers, not on fields. Maybe modulo reduction is to blame