Skip to content

feat: remove generic parameter from the BigNum trait#44

Merged
TomAFrench merged 8 commits intomainfrom
mc/bignum-compatibility-changes
Nov 8, 2024
Merged

feat: remove generic parameter from the BigNum trait#44
TomAFrench merged 8 commits intomainfrom
mc/bignum-compatibility-changes

Conversation

@iAmMichaelConnor
Copy link
Copy Markdown
Collaborator

Although not explained in the original code, there's a reason why arrays of size N are never passed to/from setters and getters of BigNum; it's so that external libs can write use a generic BigNum where BigNum: BigNumTrait, without having to specify an N. Removal of from_array and get_limbs resolves this.

Also resolves a modulus_bits typo in one of the off-the-shelf params files.

Comment thread src/bignum.nr Outdated
Comment thread src/bignum.nr Outdated
Comment thread src/bignum.nr Outdated
Comment thread src/bignum.nr Outdated
Comment thread src/bignum.nr Outdated
Comment thread src/bignum.nr Outdated
Comment thread src/fields/secp256r1Fq.nr
@TomAFrench TomAFrench changed the title feat: bignum compatibility with external libs feat: remove generic parameter from the BigNum trait Nov 8, 2024
@TomAFrench TomAFrench merged commit 53f652b into main Nov 8, 2024
@github-actions github-actions bot mentioned this pull request Nov 7, 2024
TomAFrench added a commit that referenced this pull request Nov 8, 2024
* main:
  feat: remove generic parameter from the `BigNum` trait (#44)
  fix: fix broken tests in `runtime_bignum_test.nr` (#39)
  feat: remove a bunch of unnecessary bytecode from unconstrained ops (#50)
  fix: Fix barrett reduction bug (#51)
  feat: optimize brillig execution of `split_X_bits` functions (#47)
Comment thread src/bignum.nr
evaluate_quadratic_expression::<_, MOD_BITS, _, _, _, _>(
params,
map(lhs_terms, |bns| map(bns, |bn| Self::get_limbs(bn))),
map(
Copy link
Copy Markdown
Collaborator Author

@iAmMichaelConnor iAmMichaelConnor Nov 14, 2024

Choose a reason for hiding this comment

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

@TomAFrench I've honed in on this PR being the one that caused a regression in the constraint counts of BigNum. In particular, I was measuring the constraints of calls to this evaluate_quadratic_expression function.
Any thoughts on why the changes in this PR are increasing constraint counts? Is it simply that converting between slices and arrays is not free?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

The extra ACIR opcodes (for a main function which calls this evaluate_quadratic_expression) function appear to be:

INIT (id: 0, len: 4) 
EXPR [ (-1, _5) 0 ]
MEM (id: 0, read at: x5, value: x6) 
EXPR [ (-1, _7) 1 ]
MEM (id: 0, read at: x7, value: x8) 
EXPR [ (-1, _9) 2 ]
MEM (id: 0, read at: x9, value: x10) 
EXPR [ (-1, _11) 3 ]
MEM (id: 0, read at: x11, value: x12) 
INIT (id: 1, len: 4) 
MEM (id: 1, read at: x5, value: x13) 
MEM (id: 1, read at: x7, value: x14) 
MEM (id: 1, read at: x9, value: x15) 
MEM (id: 1, read at: x11, value: x16) 

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yeah, this is bad actor codegen as we're just reading all the values out of the array to write into another one.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Neater code here, to fix it: #53

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.

2 participants