Skip to content
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

Poly: Investigate Faster sparse polynomial evaluation methods #123

Closed
ValarDragon opened this issue Dec 9, 2020 · 1 comment · Fixed by #214
Closed

Poly: Investigate Faster sparse polynomial evaluation methods #123

ValarDragon opened this issue Dec 9, 2020 · 1 comment · Fixed by #214
Labels
D-easy Difficulty: easy T-feature Type: new features T-performance Type: performance improvements

Comments

@ValarDragon
Copy link
Member

At the moment, the logic for sparse polynomial evaluation is:

let total = self.coeffs.iter()
            .map(|(i, c)| (*c * point.pow(&[*i as u64])))
            .sum();

This recomputes the power of point for each term, which is more costly than need be.

Sparse polynomials for the most part used in vanishing polynomials in our codebase. I suggest we write a fast path for sparse polynomial evaluation, when all terms are powers of 2. (This captures vanishing polynomials for unions of cosets, and vanishing polynomials for subspaces of binary fields)

Then for general sparse polynomial evaluation, I suggest we compare the current method against computing all of the squares, and then make the per-term work just computing the correct product of the squares. (As this removes any duplicate squarings computed)

Originally posted by @ValarDragon in #117 (comment)

@ValarDragon ValarDragon added T-performance Type: performance improvements T-feature Type: new features D-easy Difficulty: easy labels Dec 9, 2020
@jon-chuang
Copy link
Contributor

jon-chuang commented Feb 8, 2021

well, naively, one solution is just to precompute the powers of 2 of the point, and implement the right addition chain for the given exponent i.

This should reduce the eval time by 3x.

I agree this current method is quite ugly.

@jon-chuang jon-chuang mentioned this issue Feb 8, 2021
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D-easy Difficulty: easy T-feature Type: new features T-performance Type: performance improvements
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants