Merged
Conversation
ludamad
reviewed
Feb 15, 2025
| : subtable(sub) | ||
| , index(idx) | ||
| , subtable_size(sub ? sub->size() : 0) | ||
| {} |
Collaborator
There was a problem hiding this comment.
Nit: could get away without storing size
Contributor
Author
There was a problem hiding this comment.
yeah I did this to save on the size() call every time in a hot loop but maybe thats overkill. I would def prefer just calling size()
Collaborator
There was a problem hiding this comment.
Yeah so what's going to happen:
- we are reading a pointer, offsetting it (basically free), then reading a field
vs - we are reading a field
the pointer we are dereferencing will be in cache, so it's a trivial difference
Collaborator
There was a problem hiding this comment.
We are also returning a rather big struct, which, fair if we are reading one field from it might be a hot loop, but if we are doing anything with a field the loop overhead is not that big. Comes down to how many times we will be iterating during a proving lifetime, I guess. Could be worth the cycles potentially
ludamad
approved these changes
Feb 15, 2025
TomAFrench
added a commit
that referenced
this pull request
Feb 17, 2025
* master: (207 commits) chore(docs): acir formal verification final report (#12040) feat(avm): packed field in bytecode decomposition (#12015) feat: Contract updates (#11514) feat!: enforce fees (#11480) chore: redo typo PR by maximevtush (#12033) git subrepo push --branch=master noir-projects/aztec-nr git_subrepo.sh: Fix parent in .gitrepo file. [skip ci] chore: replace relative paths to noir-protocol-circuits git subrepo push --branch=master barretenberg fix: unexposing test fr from vkey struct ts (#12028) chore: structured polys in Translator (#12003) fix(ci3): fix ./bootstrap.sh fast in noir-projects (#12026) feat: new op queue logic (#11999) git subrepo push --branch=master noir-projects/aztec-nr git_subrepo.sh: Fix parent in .gitrepo file. [skip ci] chore: replace relative paths to noir-protocol-circuits git subrepo push --branch=master barretenberg chore: skip flakey p2p (#12021) chore(ci3): label handling (#12020) feat: Sync from noir (#12002) ...
This file contains hidden or 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
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.
New class EccOpsTable to support the new concatenate-via-relations approach to the Merge protocol.
Background: The "Merge" protocol is essentially a protocol for establishing that a large table was constructed as the concatenation of smaller ones (subtables). In the original version of the protocol, the larger table was obtained by successively appending subtables (one from each circuit). The new version requires that subtables be PRE-pended. This results in a simpler protocol overall (and, importantly, one that's easier to make ZK) but its a bit more annoying from a data management standpoint since in general we don't want to pre-pend things in memory. This PR introduces a class
EccOpsTablewhich stores individual subtables which can be virtually "prepended" to construct the entries of the corresponding aggregate table as needed.