Skip to content
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

Finalize #334

Merged
merged 10 commits into from
Jan 4, 2021
Merged

Finalize #334

merged 10 commits into from
Jan 4, 2021

Conversation

npwardberkeley
Copy link
Contributor

Initial attempt to resolve #333

@npwardberkeley npwardberkeley marked this pull request as draft December 31, 2020 05:44
@npwardberkeley npwardberkeley marked this pull request as ready for review December 31, 2020 05:44
@weikengchen
Copy link
Member

This fmt issue may have something to do with the Rust version, aka

  • is it 1.48.0?
  • is it stable?

Because some other versions, and some nightly, have different cargo fmt preferences.

@weikengchen
Copy link
Member

let me cc @Pratyush and @ValarDragon here for some feedback on the API.

@@ -149,6 +165,18 @@ impl<F: Field> ConstraintSystem<F> {
self.mode == SynthesisMode::Setup
}

/// Check whether this constraint system aims to optimize weight or
/// number of constraints.
pub fn get_optimization_goal(&self) -> OptimizationGoal {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
pub fn get_optimization_goal(&self) -> OptimizationGoal {
pub fn optimization_goal(&self) -> OptimizationGoal {

Comment on lines 515 to 517
fn reduce_constraint_weight(&mut self) {
self.outline_lcs();
}
Copy link
Member

Choose a reason for hiding this comment

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

We can remove this now, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wasn't the idea to add other weight-reducing optimizations, apart from just outlining? (That's what the comment here says.) In which case we'd still want this as a separate function

Comment on lines 828 to 832
pub fn get_optimization_goal(&self) -> OptimizationGoal {
self.inner().map_or(OptimizationGoal::Constraints, |cs| {
cs.borrow().get_optimization_goal()
})
}
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
pub fn get_optimization_goal(&self) -> OptimizationGoal {
self.inner().map_or(OptimizationGoal::Constraints, |cs| {
cs.borrow().get_optimization_goal()
})
}
pub fn optimization_goal(&self) -> OptimizationGoal {
self.inner().map_or(OptimizationGoal::Constraints, |cs| {
cs.borrow().optimization_goal()
})
}

@@ -91,6 +95,16 @@ pub enum SynthesisMode {
},
}

/// Defines the parameter to optimize for a `ConstraintSystem`.
#[derive(Copy, Clone, Debug, Eq, PartialEq, Ord, PartialOrd)]
pub enum OptimizationGoal {
Copy link
Member

Choose a reason for hiding this comment

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

Should we have a None here, which will do no optimization passes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That makes sense. Do you think None, or Constraints, should be the default?

Copy link
Member

Choose a reason for hiding this comment

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

I think constraints should be the default

Copy link
Member

Choose a reason for hiding this comment

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

What are the semantics of calling finalize with None? In the end we have to get rid of all SymbolicLC before converting to matrices

Copy link
Member

Choose a reason for hiding this comment

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

I think None would still need to inline Symbolic LC (self.inline_all_lcs(), without which to_matrices would fail.

Dev, what do you think? Basically, at this moment, None would be the same as Constraints, and it is uncertain if in the future we will treat them differently.

Copy link
Member

Choose a reason for hiding this comment

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

I think given that no specific use cases pop up for None, and we currently do not have a good idea of faster inlining (without optimization to reduce constraints), maybe we can omit None and add it later. Dev, what do you think?

Copy link
Member

@ValarDragon ValarDragon Jan 3, 2021

Choose a reason for hiding this comment

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

Sounds good to me!

Copy link
Member

@ValarDragon ValarDragon Jan 3, 2021

Choose a reason for hiding this comment

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

Actually, I do think None is still useful, in that it could just make far fewer symbolic LC's for memory reduction. E.g. when multiplying by a constant, we don't need to make a new symbolic LC if we don't care about optimizations

Copy link
Member

Choose a reason for hiding this comment

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

And we could have drop semantics to symbolic LC's to remove intermediate variables from the map as soon as they're dropped from memory. It is a significant engineering effort though, so maybe not worth having it now. (Its non breaking to add it later)

Copy link
Member

Choose a reason for hiding this comment

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

That makes sense. Then let us keep None and, for now, let None also do inline_all_lcs. More changes may be coming in the future.

/// (usize, Option<Vec<F>>)
/// The transformer function is given a references of this constraint system
/// (&self), number of times used, and a mutable reference of the linear
/// combination to be transformed. (&ConstraintSystem<F>, usize,
Copy link
Member

Choose a reason for hiding this comment

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

Were these comments re-ordered by a linter? Its kinda weird imo that the tuple is split across a new line

@weikengchen
Copy link
Member

It seems that all the comments have been resolved, with this one needing more discussion:

whether or not to keep this function

fn reduce_constraint_weight(&mut self) {

Since this function is now fn rather than pub fn, I think for now it is okay to remove this function. The function is only, previously used by Marlin (who needs to change accordingly).

Nick, what do you think?

@npwardberkeley
Copy link
Contributor Author

Yes, that makes sense!

@weikengchen
Copy link
Member

Let me cc @Pratyush and @ValarDragon for a final pass

@Pratyush
Copy link
Member

Pratyush commented Jan 3, 2021

I left a comment about None

@weikengchen
Copy link
Member

Based on the discussion above, I think we will keep None for now and redirect it to self.inline_all_lcs(). This is the last change needed/ In the future, different treatments may occur, such as reducing the amount of symbolic LC.

@weikengchen
Copy link
Member

Checks pass :) Pratyush and Dev, if it looks good, feel free to merge or do some final edits.

@weikengchen
Copy link
Member

One more: we need to export OptimizationGoal here:

https://github.com/npwardberkeley/snark/blob/finalize/relations/src/r1cs/mod.rs#L21

Otherwise, Marlin could not find it.

@weikengchen
Copy link
Member

add one to enforce that set_optimization_goal must check that no constraint/variable has been written.

        num_instance_variables: 1,
        num_witness_variables: 0,
        num_constraints: 0,
        num_linear_combinations: 0,

(sorry to bother Nick---I could add them if you add me as a PR repo's writer)

Copy link
Member

@weikengchen weikengchen left a comment

Choose a reason for hiding this comment

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

The final changes have been applied. Going to merge and updating Marlin then.

@weikengchen weikengchen merged commit 8d9055d into arkworks-rs:master Jan 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

provide a higher level API for CS finalization
4 participants