-
Notifications
You must be signed in to change notification settings - Fork 260
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
fix: remove finalize from acir create circuit #6585
Conversation
Changes to circuit sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Proof generationEach column represents the number of threads used in proof generation.
L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.
Stats on running time collected for app circuits
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contract classes are registered in the tx.
Transaction size based on fee payment method | Metric | | Transaction processing duration by data writes.
|
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.
Looks good in general, but seems to be double counting these extra gates?
@@ -164,7 +164,8 @@ bool proveAndVerifyHonkAcirFormat(acir_format::AcirFormat constraint_system, aci | |||
// Construct a bberg circuit from the acir representation | |||
auto builder = acir_format::create_circuit<Builder>(constraint_system, 0, witness); | |||
|
|||
size_t srs_size = builder.get_circuit_subgroup_size(builder.get_total_circuit_size()); | |||
auto num_extra_gates = builder.get_num_gates_added_to_ensure_nonzero_polynomials(); | |||
size_t srs_size = builder.get_circuit_subgroup_size(builder.get_total_circuit_size() + num_extra_gates); |
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 not double count the ensure_nonzero gates? Since get_num_gates_added_to_ensure_nonzero_polynomials will add these gates in, and then get_total_circuit_size would already account for these extra gates.
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.
get_total_circuit_size doesn't account for the added gates for non-zero polys, only the gates that have been added explicitly plus those that will be added via the finalize method.
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.
What I'm saying is that calling get_num_gates_added_to_ensure_nonzero_polynomials will add the non-zero gates and then get_total_circuit_size calls get_num_gates which calls get_num_gates_split_into_components which sets the count to be this->num_gates which should include the added non-zero gates.
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.
but the added non-zero gates aren't added until we construct an instance
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.
Oh, maybe the confusion is this: get_num_gates_added_to_ensure_nonzero_polynomials
doesn't actually add the gates. It creates a new builder, adds them to that, then counts them. The original builder is unaffected
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.
ah got it. I didn't look hard enough at that function oops
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.
I added some comments to make that a bit more explicit
process_non_native_field_multiplications(); | ||
process_ROM_arrays(); | ||
process_RAM_arrays(); | ||
process_range_lists(); | ||
circuit_finalized = true; | ||
} else { | ||
// Gates added after first call to finalize will not be processed since finalization is only performed once | ||
info("WARNING: Redudant call to finalize_circuit(). Is this intentional?"); |
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.
nice
Largely undoing the changes made in this PR that added a call to
finalize_circuit
in the create_circuit methods in acir_format. This change was originally made in order to facilitate accurate final gate counts (previously handled via a hack). The finalize model has been reverted and the hack has been replaced with a method that computes the number of gates added by theadd_gates_to_ensure..
methods in the builders. This change was necessary in order to allow gates to be added to a circuit generated from acir, which is needed in ClientIvc accumulation.