-
Notifications
You must be signed in to change notification settings - Fork 496
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
Move config responsibilities from Layouter
to Chip
#253
Conversation
Codecov Report
@@ Coverage Diff @@
## main #253 +/- ##
==========================================
+ Coverage 81.71% 81.99% +0.28%
==========================================
Files 32 32
Lines 3221 3210 -11
==========================================
Hits 2632 2632
+ Misses 589 578 -11
Continue to review full report at Codecov.
|
19c52dc
to
7904da5
Compare
Layouter
to Chip
Layouter
to Chip
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.
Partial review.
Co-authored-by: Jack Grigg <jack@electriccoin.co>
8e127ec
to
03da010
Compare
examples/simple-example.rs
Outdated
@@ -275,7 +319,7 @@ struct MyCircuit<F: FieldExt> { | |||
|
|||
impl<F: FieldExt> Circuit<F> for MyCircuit<F> { | |||
// Since we are using a single chip for everything, we can just reuse its config. | |||
type Config = FieldConfig; | |||
type Config = FieldConfigEnum; |
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.
type Config = FieldConfigEnum; | |
type Config = FieldConfig; |
I think this could also maybe instead be type Chip = FieldChip
, since I think now we'll always just construct the chip from its config immediately inside Circuit::synthesize
. But that's a higher-level refactor (and would probably also require making the layouter choice an associated type), so let's leave that out of this PR.
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Co-authored-by: Jack Grigg <jack@electriccoin.co>
examples/sha256/main.rs
Outdated
hasher.finalize(layouter.namespace(|| "finalize")) | ||
} | ||
} | ||
// //! Gadget and chips for the [SHA-256] hash function. |
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.
Use a block comment (/* ... */
) so that when #256 fixes the example, we can see the actual changes in the diff. (Nice PR number btw 😆.)
a: Self::Num, | ||
b: Self::Num, | ||
) -> Result<Self::Num, Error> { | ||
let config = self.config().add_config.clone(); |
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 it possible to avoid these clones? I tried but the lifetime requirements defeated me.
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.
These ones, I think not (at least if we want the sub-cores to be usable on their own). We still have a large reduction in config cloning from this PR.
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.
utACK
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.
utACK
Closes #235
Review recommendations:
cargo run --example two-chip
;sha256
example is commented out here and fixed in Fixsha256
example for new config abstraction #256trait Chip<F: FieldExt>
is responsible for:layouter().config()
we now haveself.config()
; andThe "top-level" chip is simply the chip with the most comprehensive config, i.e. it provides all columns and permutations needed by other chips.
trait Layouter<F: FieldExt>
is responsible for:assign_region(&mut self)
assigning values according to its own defined strategy;The layouter knows nothing about any config. This is fine because when a chip calls
layouter.assign_region()
, it has access toself.config()
to inform the layouter. So we no longer see aLayouter<C: Chip>
generic type, and this removal also trickles down toRegionLayouter
,Region
.