Open ashWhiteHat opened 2 years ago
I want to take the first commit from this branch but not (yet) the second. I don't really want to maintain a second macro-based field implementation (the other being the proc-macro-based ff_derive
). We should think about how we want to make the field impls more maintainable going forward, whether that be this declarative macro, ff_derive
, something based on crypto-bigint
, or another approach. But that should be separated from the doubling improvement.
I've opened #49 for discussing code de-duplication approaches. In the meantime, I will open another PR with the first commit from this branch, so we can get it reviewed.
Per https://github.com/zcash/pasta_curves/pull/50#issuecomment-1276980492, the manual bitshift-based doubling does not appear to be more efficient than the self.add(self)
doubling.
Hi @str4d Thank you for the review.
I think we can speed up if we implement as following. https://github.com/zero-network/zero/blob/master/primitive/crypto/src/arithmetic/limbs/bits_256/normal.rs#L29
fn dbc
do 1 right shift, and return high and low.
It can optimize double and square as well.
https://github.com/zero-network/zero/blob/master/primitive/crypto/src/arithmetic/limbs/bits_256/normal.rs#L64
I am going to implement these if you think it's good idea.
_ | Before | After |
---|---|---|
push | 2 | 1 |
mov | 10 | 11 |
add | 7 | 8 |
adc | 9 | 9 |
xor | 1 | 1 |
movabs | 6 | 6 |
shrd | 2 | 1 |
shld | 1 | 2 |
lea | 1 | 0 |
sar | 3 | 3 |
and | 3 | 3 |
pop | 2 | 1 |
ret | 1 | 1 |
SUM | 48 | 47 |
soooo slightly improved 😅 It seems near to refactoring.
Abstract
Hi there. I improve the
double
method with bit shift and commonalize the field operation.What I did
add
anddouble
methoddouble
arithmetic with bit shiftI would appreciate it if you could confirm. Thank you!