Investigate usage of "big add" gates in the bb dsl folder #6085
Assignees
Comments
guipublic
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Oct 3, 2024
Handle ACIR AssertZero opcodes of any width, by creating intermediate quad gates using w4_omega. 'fixes' noir-lang/noir#6085, but we still need to have Noir using the unlimited width.
AztecBot
pushed a commit
to AztecProtocol/barretenberg
that referenced
this issue
Oct 4, 2024
Handle ACIR AssertZero opcodes of any width, by creating intermediate quad gates using w4_omega. 'fixes' noir-lang/noir#6085, but we still need to have Noir using the unlimited width.
5 tasks
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 24, 2024
# Description ## Problem\* Resolves #6085 ## Summary\* This PR tries to benefit from Barretenberg's 'big-add gates' support, which was enabled by PR AztecProtocol/aztec-packages#8960 It's a simple optimisation which removes intermediate variables usually created by the CSatTransformer if they are not re-used elsewhere. The PR assumes that the backend is able to handle infinite width, but still requires the CSatTransformer, which is not really consistent. I plan to make follow-up PRs to get rid of this (but I can't guarantee it will work). ## Additional Context I tested the optimisation on all 'execution_sucess' test cases. In most cases, there were no change at all, while in some cases we would win one or two (10 max) on the circuit size. However, in a few cases, listed below in the form "test case: circuit size with 'intermediate var' optimisation vs no optimisation", it can be more significant: 7_function: 2955 vs 2992 bit_shifts_runtime: 5451 vs 5761 eddsa: 65805 vs 70406 hashmap: 135023 vs 150661 nested_array_dynamic: 12594 vs 12922 nested_array_in_slice: 5371 vs 5449 poseidon_bn254_hash: 1028 vs 1060 poseidon_bn254_hash_width_3: 1028 vs 1495 poseidonsponge_x5_254: 1244 vs 1307 regression_5252: 76491 vs 83862 sha256_var_size_regression: 74093 vs 74529 sha2_byte: 93998 vs 94006 slice_dynamic_index: 6308 vs 6419 slices: 3835 vs 3874 to_be_bytes: 135 vs 143 to_bytes_consistent: 6 vs 51 to_bytes_integration: 434 vs 484 u128: 4662 vs 4707 u16_support: 3023 vs 3057 ## Documentation\* Check one: - [X] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [X] I have tested the changes locally. - [X] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings. Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Speaking with Kesha today he mentioned that we could accumulate the intermediate variables created when decomposing a large expression more efficiently by using the "big_add" gates in barretenberg.
https://github.com/AztecProtocol/aztec-packages/blob/184cc882b3f1b90d74f149e46100474263a3665d/barretenberg/cpp/src/barretenberg/stdlib_circuit_builders/ultra_circuit_builder.cpp#L265-L297
We should look at having the dsl folder produce these gates and also how to modify how we break up large expressions to ensure that it's compatible.
The text was updated successfully, but these errors were encountered: