Investigate issue with data section addressing limits. #3161
Comments
otrho
added
bug
|
I'd really like to repro this with |
|
On commit This should give you a repro. |
|
You should be able to repro with new-amm now |
|
I've been looking at this today and I'll share some insights. If I force I was a bit confused initially when looking at this because the data section for actual const values used by the program is only about 2KB in size, which obviously shouldn't be a problem. But in the final binary we add over 19,500 new entries, purely for the dynamic jumps as mentioned above. This is crazy. I was also looking at it and realised that I'm pretty sure there's a bug in that code from #3109 because it never tries to adjust the offsets to be relative to Fixing this problem will be non-trivial now too because loading from the data section will be 1, 2 or 4 (or 5?) instructions depending on where in the data section the value is and what type it is. This has to be known before the address realisation stage and complicates things there. |
|
I will point out that 3.7MB is actually an improvement from the once 5MB binary that was the size on the previous compiler. How could I force compile for now to gather initial data like gas usage for swaps? |
|
I forced it to compile by generating bogus const data, so the binary I have is structurally valid but corrupt and wouldn't run, sorry. |
|
@otrho so are we basically lowering the priority of this for the time being? If so, we should change the label |
|
Yeah, the code relocation has made the likelihood of data section overflow much rarer but it's still possible so we can't close this one yet. Until we actual see it happening in the real world |
otrho
added
P: medium
and removed
P: critical
|
edit: tested on Was trying to do nested match statements in a while loop. Note that the input is of length 2500 because there are 2500 lines in the actual AoC input: pub fn part_1(input: [(u64, u64); 2500]) -> u64 {
let mut result: u64 = 0;
// TODO: Write your solution here
let mut i = 0;
while i < 2500 {
let opp_move = input[i].0;
let my_move = input[i].1;
let score = match opp_move {
65 => match my_move {
88 => 4,
89 => 8,
90 => 3,
_ => 0,
},
66 => match my_move {
88 => 4,
89 => 8,
90 => 3,
_ => 0,
},
67 => match my_move {
88 => 4,
89 => 8,
90 => 3,
_ => 0,
},
_ => 0,
};
result += score;
i += 1;
}
return result;
}I tried shrinking this down, and this also fails: pub fn part_1(input: [(u64, u64); 2500]) -> u64 {
let mut result: u64 = 0;
// TODO: Write your solution here
let mut i = 0;
while i < 2500 {
let opp_move = input[i].0;
let my_move = input[i].1;
let score = match (opp_move, my_move) {
(65, 88) => 4,
_ => 0,
};
result += score;
i += 1;
}
return result;
}I removed the while loop and this finally built/tested: pub fn part_1() -> u64 {
let input = [(65, 88)];
let mut result: u64 = 0;
// TODO: Write your solution here
let mut i = 0;
let opp_move = input[i].0;
let my_move = input[i].1;
let score = match (opp_move, my_move) {
(65, 88) => 4,
_ => 0,
};
result += score;
i += 1;
return result;
}Not sure if this is helpful since perhaps we aren't meant to do so many iterations using Sway? EDIT: I dug more into this and seems like the problem was with assignment within the while loop. This fails for example: let mut result = 0;
let mut i = 0;
while i < 2 {
let score = opp_move[i] + my_move[i];
result += score;
i += 1;
} |
|
How are you getting the input into the script? Are you actually compiling it as a const array of values? Because this will definitely blow out the data section as it can only have around 16KB of data. Adding this much constant data isn't typical for blockchain contracts. |
|
I am indeed compiling the input... What's an alternative to get a long input into a contract/script? |
|
Good question! Sending each line in one at a time via contract args and using storage to maintain state between calls? |
@vaivaswatha mentioned that while implementing
mem2reghe was testing against https://github.com/sway-libs/amm (which has become the de facto gargantuan library for testing Sway performance) and it failed:The data section uses a single register as a base and indexes elements using
lw, which has a 12-bit index immediate. If the data section gets too large then this won't work any more.We should look at both allowing a large DS and also optimising the DS for size by removing any redundancy.
$zeroand$one.MOVI.The text was updated successfully, but these errors were encountered: