-
Notifications
You must be signed in to change notification settings - Fork 261
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
Unroll loops and use in-place ops for faster ff
and ec
arithmetic
#199
Conversation
LGTM. For the extension fields, |
6ead802
to
c1c52d8
Compare
This is ready for review. |
@@ -260,7 +265,6 @@ impl<P: Parameters> Default for GroupAffine<P> { | |||
#[derivative( | |||
Copy(bound = "P: Parameters"), | |||
Clone(bound = "P: Parameters"), | |||
Eq(bound = "P: Parameters"), |
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.
Why did this get removed?
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.
This got moved to a proper impl, because you shouldn't have a manual impl of PartialEq
and a derived impl of Eq
.
Hi @Pratyush , thanks for this quick follow up. I did a bench of this PR (name: assign) against simply implementing the unroll to big integer (just_unroll), here are the results: Thanks for catching cmp as being a helpful change. This improved things further over my original changes. However, I question the changes to the semantics of the non-assigning versions of the ops, which are changed to mutate the underlying variable. From an API standpoint, I think this is confusing, further, it achieves nothing over just @Pratyush Would you mind giving me partial access to this repo so I could push commits to a branch on the repo? It would simplify things for me so I wouldn't have to keep switching my git remote to target different urls. |
The semantics didn't change; I only removed unnecessary copies. In particular, the non-assigning versions take
That's surprising, I definitely benchmarked the
Let me figure that out. In the mean time a simpler way to handle it would be to just change the patch location |
Hmm actually this is orthogonal to that issue (since deps target master, and one still has to make changes to target branches). I'm just thinking in terms of friction in PR workflow. It's a small thing. Wrt the cross-dependency issue, I think patch doesn't fix the problem, I'll investigate if there is a good way to fix it.
Are you saying that the assign changes without the biginteger unroll changes produced an improvement?
Could you clarify this? I meant that the semantics have changed due to mutating the underlying variable now. To clarify:
My point essentially is that the old non assigning APIs don't have to be changed, even if one were to convert all group formulas to use assigning versions. Orthogonally, those conversions don't appear to help, at least according to the benchmarks I performed. |
Ah I just point the
Yes
The semantics to users are the same: let a = 2;
let b = 3;
let c = a.add(&b); // c = 5
println!(a); // will print 2 |
Here is my patch in curves, which works quite nice for me:
|
Also I re-benchmarked this, and confirmed that I only saw operation times go down for all operations benchmarked. (Between 2 and 10% reduction depending on the operation) |
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.
LGTM sans comment requests. Thanks for updating this!
68eb904
to
f86bb91
Compare
wait what happened in this force push |
Sorry, I just rebased on master, though I will be making a clean up of the history also soon, to separate out commits that change just the unrolling and commits that additionally use (Don't worry, I added your comment requests =P) |
f86bb91
to
63a56ef
Compare
Ok @jon-chuang @ValarDragon seems like the in place ops don't actually get you a big benefit; I can't reproduce whatever I had earlier (which might well have been wrong). In light of that, I think it makes sense keep only the first three commits (loop unrolling and reducing copies), as the in place ops make the code more difficult to read. Fields ops
Group ops
|
Description
add_nocarry
,sub_noborrow
,mul2
,div2
, andcmp
Overall, these changes provide a ~10% speedup to the relevant ops.
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
Pending
section inCHANGELOG.md
Files changed
in the Github PR explorer