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

Calling the same unconstrained fn multiple times in the program multiplies debug metadata #5521

Closed
sirasistant opened this issue Jul 16, 2024 · 0 comments · Fixed by #5696
Closed
Assignees
Labels
bug Something isn't working

Comments

@sirasistant
Copy link
Contributor

sirasistant commented Jul 16, 2024

Aim

Have a program that uses brillig hints in a loop

Expected Behavior

Artifact size and compile time should not explode.

Bug

In this project ram usage goes to 100gigs, postprocessing after ACIR generation can take 10 minutes and the compressed debug metadata in the artifact weights 1 gigabyte.

The problem is that we always associate debug metadata with acir callsites. We've succesfully deduplicated the brillig code by the separation unconstrained fn / brillig call in the Program struct, but brillig-related debug metadata still gets added over and over again on every callsite, just changing the ACIR index.

To Reproduce

Minimal repro:

global ITERATION_COUNT = 100000;

unconstrained fn some_unconstrained_fn(x: Field, y: Field) -> Field {
    let x_u128 = U128::from_integer(x);
    let y_u128 = U128::from_integer(y);
    (x_u128 / y_u128).to_integer()
}

fn main(data: [Field; ITERATION_COUNT]) -> pub Field {
    let mut acc = data[0];

    for i in 1..ITERATION_COUNT {
        acc = some_unconstrained_fn(acc, data[i]);
    }

    acc
}

some_unconstrained_fn has 1558 locations. It gets called 100k times, and the final Program struct debug metadata locations has 155M entries.

Project Impact

None

Impact Context

No response

Workaround

None

Workaround Description

No response

Additional Context

No response

Installation Method

None

Nargo Version

No response

NoirJS Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

@sirasistant sirasistant added the bug Something isn't working label Jul 16, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Jul 16, 2024
github-merge-queue bot pushed a commit that referenced this issue Aug 8, 2024
# Description

## Problem\*

Resolves #5521 

## Summary\*

This PR adds a new `brillig_locations` map to our generated ACIR that
maps a brillig function id to an opcode locations map
`BTreeMap<OpcodeLocation, CallStack>`. If we have called that Brillig
function id before we do not add its debug locations.

For the same test as in the issue I ran `du -sh ./target` and got a size
of 2.3M. This is a >400x reduction in size of the artifact. Compilation
also takes a matter of a couple seconds now rather than 10 minutes.

## Additional Context

The call stacks are the same as expected. For example, under
`execution_failure/fold_nested_brillig_assert_fail` we have the
following call stack:
<img width="871" alt="Screenshot 2024-08-08 at 10 33 28 AM"
src="https://github.com/user-attachments/assets/716d5e53-dc7b-4873-950f-2e1b8fd6c5b9">


## 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: jfecher <[email protected]>
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants