-
Notifications
You must be signed in to change notification settings - Fork 4
Conversation
0df5203
to
3ed5d9f
Compare
TODO: add curve-specific parameters for batch ops: prefetching number |
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.
Very cool we got to this stage. I know this is still WIP but I thought it's a good time to take a look.
General comments and questions:
- Why was it important to add the
prime_fields
andextension_fields
features? - Seems like the tests use
extensions_fields
in plural rather than singular. - GLV doesn't seem to be generic and so maybe we should assert on the parameters that actually work.
- I'm a bit concerned about adding another timer mechanism. But if the benefits are large, I'm generally OK with it.
In general, this is a pretty big PR. In the future, if we want to make big changes, we should make a "tower of PRs", a series of PRs that build on top of each other. It makes it much easier to review.
const NUM_LIMBS: usize = 8; | ||
|
||
fn main() { | ||
println!("cargo:rerun-if-changed=build.rs"); | ||
|
||
let is_nightly = version_meta().expect("nightly check failed").channel == Channel::Nightly; | ||
|
||
let should_use_asm = cfg!(all( | ||
let _should_use_asm = cfg!(all( |
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.
Is this still needed?
algebra-core/build.rs
Outdated
feature = "llvm_asm", | ||
target_feature = "bmi2", | ||
target_feature = "adx", | ||
target_arch = "x86_64" | ||
)) && is_nightly; | ||
|
||
#[cfg(features = "llvm_asm")] | ||
if should_use_asm { |
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.
Does this compile if should_use_asm
is undefined?
algebra-core/src/curves/glv.rs
Outdated
use crate::{biginteger::BigInteger, ModelParameters, PrimeField}; | ||
use core::ops::Neg; | ||
|
||
/// TODO: deal with the case where b1 and b2 have the same sign |
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.
Do we worry we have a case like that?
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.
Yes, because they can reverse sign. Empirically speaking. Due to the exceeding the modulus.
// If we are doing a subgroup check, we should multiply by the original scalar | ||
// since the GLV decomposition does not guarantee that we would not be | ||
// adding and subtracting back to zero | ||
if k == modulus { |
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.
Interesting.
We shouldn't do it now, but there are endomorphism-based methods for subgroup membership checking.
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.
Yes, I am aware. It should also be possible to handle this case by using biginteger rather than field. I will look into whether it can be handled generically.
}; | ||
use rand::Rng; | ||
|
||
#![allow(unused_imports)] |
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 do we need to allow this?
assert_eq!(naive.into_affine(), fast.into_affine()); | ||
} | ||
#[allow(unused)] | ||
pub fn test_msm<G: AffineCurve>() { |
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 is this unused now?
use std::ops::Neg; | ||
|
||
fn main() { | ||
let _omega_g1 = BigInteger768([ |
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.
Can you clarify where these numbers are from?
type WideBigInt = BigInteger768; | ||
|
||
/// phi((x, y)) = (\omega x, y) | ||
/// \omega = 0x531dc16c6ecd27aa846c61024e4cca6c1f31e53bd9603c2d17be416c5e44 |
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.
Can you clarify where these numbers are from?
No particular reason. Sometimes the benchmarks can be messy. Nicer to look at pure Fp for instance to evaluate the asm impl.
Will change
I prefer to rewrite as generic, as it comes hand in hand with checking the math. Target is done by wednesday.
It's something that is already integrated and works. We can migrate to another timer (
This is true, but the problem is code drift. There was also a lot of refactorisation. A more pertinent solution may be to try to get merges more quickly. |
To clean up the git history, and to make reviewing easier, I would recommend using something like I took this approach with a recent PR (arkworks-rs#186) |
Workflow now:
|
Also, need to change glv script to example first |
closed in favour of #16 |
This PR is meant to resolve the code drift since the previous two PRs. It leaves the recursive batch verification code commented out. It also retains GLV. There will be a sister PR with GLV redacted. This is meant to merge atop that.
Features:
Combined speedup (with w-NAF) for
Without GLV: 1.65-1.8x and 1.4x resp.
Speedup for subgroup verification
TODO: