fix: memory fragmentation fixes to cut UltraHonk memory usage by 26% #11895
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lucasxia01
changed the title
lucasxia01
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
prove_ultra_honk on the verify_honk_proof circuit goes from 3059.63MiB to 2251.31MiB, a decrease of 26%.
The fix hinges on a couple key issues: we want to deallocate large objects when we don't need them anymore and we need to be careful with our vector usage.
First, we should deallocate the builder after the prover is constructed and before we call construct_proof, and we should also deallocate the commitment_key during sumcheck since we do not need to commit to any polynomials during that phase.
Second, this deallocation of the commitment key does not actually help memory that much, in large part due to fragmentation. I discovered that our usage of the manifest, which uses vectors for each round data, caused tiny vectors to be littered across memory, often breaking up what otherwise would be a large contiguous block of memory.
With this in mind, we now only use the manifest when we build in debug mode and also if we specify that we want the manifest specifically, i.e. for the manifest tests.