Is that really 6 GiB, not more? On the heap, I generally advise using a maximum of 1 GiB out of the 4, because upgrades become really tricky afterward in my experience. So the gain wouldn’t be massive from that point of view, like 500 MiB more with that logic 
.
6 Likes
Alex, this is great news.
For those of us who use stable-structures, what would be a safe target for a large data structure now? We use it to save user data, like their own canister for data, so knowing how big it can be, and still be able to upgrade the canister is important to me.
For context Satoshi Notes gives each user their own canister, we manage it, but it is not ours, most of the space is used for their data. So I wonder, how much data can we assign safely to the user, and still do upgrades without issues. Assuming we use this new target to wasm64-unknown-unknown.
Thanks,
Joseph Hurtado
Has anyone successfully compiled wasm64 with Rust yet?
I haven’t managed to get it working.
hey @zensh, can you please double check if you follow the steps listed here: examples/rust/backend_wasm64/build.sh at master · dfinity/examples · GitHub
I think you might be missing something like this:
rustup component add rust-src --toolchain nightly
hi Joseph, thanks for reaching out.
I’m not sure I understand your question: are you asking whether you should/could replace stable-structures with some larger data structure that lives on the heap instead of stable memory?
hey @peterparker , yes, that is 6GiB (for now). Unlocking larger heaps will come later (see my initial message about the current limitations).
Another issue from ring 
Apologies, I got confused.
Stable Memory does not relate to this heap RAM you mentioned.
Out of curiosity out of the theoretical 500 GiB, how much is possible to use per Rust Canister? Assuming the subnet has the available space.
hey @josephgranata, thanks for the question.
the 500 GB RAM will not necessarily be a limitation, as not the whole canister memory will need to be really in memory at any point in time. For example, for stable memory we already allow canisters to use up to 500 GB, but not more than 2GB can be “active” during a message execution.
That is the crux of the problem we aim to solve right now – how to deterministically count (and limit) the amount of heap memory that can be touched by a canister during a message execution. Once that is done, we would be able to up the 6 GB to something larger.
However, this larger value will most likely not be a huge value. That’s because for Rust developers would still need to serialize and deserialize state for code upgrades. There is no way to bypass that (unless using stable memory) for Rust (at least for now). Allowing up to 500 GB (for the sake of the argument) is infeasible because one would need to serialize and deserialize huge amounts of data, which could possibly even take longer than a checkpoint interval.
The discussion is obviously different for Motoko. Due to EOP, people don’t need to serialize/deserialize state, solving the above problem.
4 Likes
hey @zensh, sorry, that seems like an issue when building the C code. Probably the toolchain doesn’t set up things correctly.