Skip to content
This repository has been archived by the owner on Jan 26, 2022. It is now read-only.

Alg Opt with GLV #4

Closed
wants to merge 99 commits into from
Closed

Alg Opt with GLV #4

wants to merge 99 commits into from

Conversation

jon-chuang
Copy link

@jon-chuang jon-chuang commented Sep 3, 2020

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:

  • Batch Affine ops
  • Batch and ordinary w-NAF
  • GLV framework, params only for bw6. GLV precomputation script.
  • GLV impl for both batch affine and projective mul
  • Batch bucket addition tree
  • Batched MSM (1.4-1.7x bump)
  • Batch subgroup verification based on addition to random buckets
  • 2D test matrix feature-gating with axes (curve, test type)
  • Refactor tests to use common template
  • Code timing instrumentation with fine grained control of functions and callers

Combined speedup (with w-NAF) for

  • Batched mul (with GLV): 2.3-2.7x.
  • Projective mul (with GLV): 2.1x.
    Without GLV: 1.65-1.8x and 1.4x resp.

Speedup for subgroup verification

  • Over old impl 25-80x.
  • Over new batch mul: 10-30x.

TODO:

  • Extend ordinary w-NAF to non-GLV curves.

@jon-chuang
Copy link
Author

TODO: add curve-specific parameters for batch ops:

prefetching number
batch size

Copy link
Collaborator

@kobigurk kobigurk left a 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 and extension_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(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still needed?

feature = "llvm_asm",
target_feature = "bmi2",
target_feature = "adx",
target_arch = "x86_64"
)) && is_nightly;

#[cfg(features = "llvm_asm")]
if should_use_asm {
Copy link
Collaborator

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?

use crate::{biginteger::BigInteger, ModelParameters, PrimeField};
use core::ops::Neg;

/// TODO: deal with the case where b1 and b2 have the same sign
Copy link
Collaborator

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?

Copy link
Author

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 {
Copy link
Collaborator

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.

Copy link
Author

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.

algebra-core/src/curves/models/bw6/mod.rs Outdated Show resolved Hide resolved
algebra/src/cp6_782/fields/tests.rs Outdated Show resolved Hide resolved
};
use rand::Rng;

#![allow(unused_imports)]
Copy link
Collaborator

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>() {
Copy link
Collaborator

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([
Copy link
Collaborator

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
Copy link
Collaborator

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?

@jon-chuang
Copy link
Author

jon-chuang commented Sep 14, 2020

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 and extension_fields features?

No particular reason. Sometimes the benchmarks can be messy. Nicer to look at pure Fp for instance to evaluate the asm impl.

  • Seems like the tests use extensions_fields in plural rather than singular.

Will change

  • GLV doesn't seem to be generic and so maybe we should assert on the parameters that actually work.

I prefer to rewrite as generic, as it comes hand in hand with checking the math. Target is done by wednesday.

  • I'm a bit concerned about adding another timer mechanism. But if the benefits are large, I'm generally OK with it.

It's something that is already integrated and works. We can migrate to another timer (tracing) in the future.

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.

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.

@jon-chuang jon-chuang closed this Sep 15, 2020
@jon-chuang jon-chuang reopened this Sep 15, 2020
@Pratyush
Copy link

Pratyush commented Sep 15, 2020

To clean up the git history, and to make reviewing easier, I would recommend using something like git reset --soft XYZ to reset the git history to commit XYZ. This keeps the changes, but simply uncommits and unstages them. Then, you can add changes either by module, or interactively via git add -i. This way you can group logical changes together.

I took this approach with a recent PR (arkworks-rs#186)

@jon-chuang
Copy link
Author

Workflow now:

  1. Wait to merge updated master.
  2. Then create branches no_glv, and just_tests, successively redacting glv and everything but tests.
  3. Then quickly do final review and merge into celo-org.
  4. Then, make 3 PRs to scipr-lab and recommend they be addressed one at a time...

@jon-chuang
Copy link
Author

Also, need to change glv script to example first

@jon-chuang
Copy link
Author

closed in favour of #16

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants