-
Notifications
You must be signed in to change notification settings - Fork 182
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
feat: field/goldilocks (more efficient 1-limb modulus arith) #177
Conversation
|
||
{{ template "reduce" .}} | ||
{{ template "reduce" .}} |
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.
Should reduce
be in an else clause? There's no situation where we would need two reductions. Does it matter?
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.
I don't understand the two reductions part / does it matter --> both code path must exist at the template level, when all bits are set and you have a carry to the last addition, then you need to reduce, but if not, you still need to check that z < q
.
This PR adds
field/goldilocks
(q = 0xffffffff00000001) .Mostly tunes the code generation for field arithmetic to produce more efficient code when len(modulus) == 1 limb; no assembly is generated (it would be counter productive) and no "goldilocks" specific tricks are used.
plonky2 paper mentions some "arithmetic tricks" that makes modular reduction efficient. In practice, perf is in the same range than the CIOS Montgomery reduction for 1-liimb.
closes #174