chore!: ToRadixLE -> ToRadixBE in Brillig and AVM#9340
chore!: ToRadixLE -> ToRadixBE in Brillig and AVM#9340
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
7e4e236 to
0b4aef7
Compare
Changes to public function bytecode sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
0b4aef7 to
3a26a38
Compare
fcarreiro
left a comment
There was a problem hiding this comment.
I'm surprised this doesn't give us bytecode gains. @sirasistant I thought Brillig was needing some conversions LE -> BE because it was expecting to do ToRadixBE?
I thought the same @fcarreiro! @sirasistant's response was "should not save much in bytecode size, but it'd have better runtime" |
Reversals are deduplicated via a procedure call so it shouldn't be noticeable. However I think we might be using little endianness more than I thought given the measurement changes |
|
Ah I see, card game uses to_le_bytes for packing and Field comparisons in the stdlib are using little endian (probably because before this PR little endian was cheaper) |
|
Maybe we can switch the compute_lt and the card game to use be and see what the results are |
Hmm, does this mean that we should drop this PR? or change the stdlib? |
3a26a38 to
ba884c0
Compare
|
Does seem to reduce gas costs for some e2e tests by a bit! Not a massive improvement. |
ba884c0 to
8401d97
Compare
2961ee0 to
281fd75
Compare
8401d97 to
7c86e37
Compare
|
Replaced by #9471 |

No description provided.