Great, thanks for providing your dfx version. To ensure we can address this issue effectively, I suggest we track it on GitHub.
1 Like
We have an approved design which weāve started implementing. It should be done sometime this quarter: mid Nov at the latest (bar unforeseen developments).
7 Likes
Sounds amazing, good luck!
2 Likes
such a relief.
Godspeed crew!
god knows we need itā¦
Is this implemented yet (iām facing same issue with c++ icpp application)?
2 Likes
AFAIK the replica implementation is done and maybe even released already. The implementation in dfx is scheduled for this month, but Iād rather not make any promises about a release date
2 Likes
Quick update on the status on support for installing large Wasms (<tl;dr> weāre almost done).
- the code on the replica side is essentially complete. It is on master but gated by a flag.
- work on SDK support is ongoing
- weāre also doing an internal security review
We plan to enable the feature as soon as possible, but not before the security review.
6 Likes
Will we have to do anything special to use a wasm > 2MB, or will it just be handled behind the scenes?
Thanks for all your work on this!
1 Like
For dfx it should be transparent to users/devs; for SNS/NNS more work needs to be done since that requires interaction via proposals and the amount of interaction needs to be minimized. We have a design on how that could be done, but we havenāt officially started work in that direction.
1 Like
I should add some clarification here. Itās not that youāll be able to deploy any Wasm binary once this fix is deployed. There are still limits on the code and data sections of the Wasm binary, and the full uncompressed size. I donāt remember the exact numbers, can someone explain here what the limits will be?
Full uncompressed size: ?
Code section: 10 MiB?
Data section: 30 MiB?
Weāre just looking for a better orchestration method to handle deploying all the canisters. So one canister that can create all the other canisters on the fly and keep track of cycles, addresses etc.
Weāve got this working with player_hub ā player, which is 1.6 megs. If I try and have a ārootā canister that deploys player_hub and our content database however, then itās 2.3. Weāre not going to be a whole lot over the limit.
The limits weāre currently going for (subject to change following the security review) are 100MB for the Wasm (compressed) with 10MB code section.
1 Like
So 100MiB fully uncompressed max, 10MiB code section max, 100MiB more or less max data section.
Whatās the outlook for making the code section bigger? 50MiB, 100MiB a possibility in the future?
There is a multi-round compilation feature in progress. The first MR is in the code review, but the actual size increase will probably come in Jan-Febā¦
1 Like
Oh awesome, can you give me some kind of intuition on the expected size increase come Jan-Feb and the theoretical practical increase we could expect in the long term?
The MR in review is to move the compilation into a separate process on IC. There will be still some communication overhead, and some risksā¦ 50MiB sounds very doable, but itās too early to be sure. We need to benchmark it.
Also, I guess it would make sense to increase the limits gradually, starting from 2-round compilation, i.e. increasing the limits ~2x. Ultimately, once everything is done and all the risks are addressed, the hard limits are CUP interval and available memoryā¦
1 Like
Sounds great, thank you for the info.
1 Like
Is āheap out of bounds, error code Some(āIC0502ā)ā related to those limitations (iām getting this running c++ physics sample, which happens after a few rounds of the simulation (its a very simple simulation with a single object which runs fine on native mode)? If itās a different issue, i can open a new thread for it!
Those bounds do not yet apply since the feature is not yet enabled. Also, the bounds are only relevant for installing code, so not for normal operations as I think is the case youāre mentioning.
Itās worth opening a new thread.