-
Notifications
You must be signed in to change notification settings - Fork 258
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
chore: fix array access issue - nuclear edition #4814
Conversation
subrepo: subdir: "noir" merged: "c44ef1484" upstream: origin: "https://github.com/noir-lang/noir" branch: "master" commit: "c44ef1484" git-subrepo: version: "0.4.6" origin: "???" commit: "???"
ba50564
to
ef9a36c
Compare
Changes to circuit sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
bd0d25e
to
ba7c7df
Compare
ba7c7df
to
800b9e3
Compare
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Values are compared against data from master at commit L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every circuit run across all benchmarks.
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contracts are deployed in the tx.
Transaction processing duration by data writes.
|
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) #4814 --------- Co-authored-by: sirasistant <[email protected]>
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](AztecProtocol/aztec-packages#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) AztecProtocol/aztec-packages#4814 --------- Co-authored-by: sirasistant <[email protected]>
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) #4814 --------- Co-authored-by: sirasistant <[email protected]>
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](AztecProtocol/aztec-packages#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) AztecProtocol/aztec-packages#4814 --------- Co-authored-by: sirasistant <[email protected]>
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](AztecProtocol/aztec-packages#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) AztecProtocol/aztec-packages#4814 --------- Co-authored-by: sirasistant <[email protected]>
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](AztecProtocol/aztec-packages#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) AztecProtocol/aztec-packages#4814 --------- Co-authored-by: sirasistant <[email protected]>
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](AztecProtocol/aztec-packages#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) AztecProtocol/aztec-packages#4814 --------- Co-authored-by: sirasistant <[email protected]>
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](AztecProtocol/aztec-packages#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) AztecProtocol/aztec-packages#4814 --------- Co-authored-by: sirasistant <[email protected]>
closing as stale, can be reopened when this discussion resurfaces |
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](AztecProtocol/aztec-packages#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) AztecProtocol/aztec-packages#4814 --------- Co-authored-by: sirasistant <[email protected]>
## Overview Works around brillig blowup issue by altering the read and write opcodes to take in arrays of data. This is potentially just a short term fix. - Reading and writing to storage now take in arrays, code will not compile without this change, due to an ssa issue ->[ ISSUE ](AztecProtocol/aztec-packages#4979) - Tag checks on memory now just make sure the tag is LESS than uint64, rather than asserting that the memory tag is uint32, this should be fine. - We had to blow up the memory space of the avm to u64 as the entire noir compiler works with u64s. Arrays will not work unless we either - Make the avm 64 bit addressable ( probably fine ) - Make noir 32 bit addressable ( requires alot of buy in ) AztecProtocol/aztec-packages#4814 --------- Co-authored-by: sirasistant <[email protected]>
changes the default word size in noir to be u32, as this is the default word size of the avm.