We are happy to announce a status update on the Wasm64 feature. In short, Wasm64 allows canisters to use 64 bit addresses for Wasm heap memory. This allows the protocol to enable heaps larger than 4 GiB in size. Over the summer, we have worked hard on an implementation that allows this. We have now reached a stage where we can propose to release the feature as a beta. What this beta release proposal effectively means is that:
For testing purposes, even though addresses are 64 bit now, the Wasm memory heap will still be limited to 4 GiB until the feature is stable in terms of both functionality and performance. Subsequent increases to 6 GiB and 8 GiB are planned in the near future.
Certain system APIs have changed signatures in Wasm64 mode, please read the interface spec pull request.
For now, the Wasm64 canisters will effectively be available only for Motoko. For the Rust CDK, technical shortcomings outside of the ICP ecosystem will only allow a Rust Wasm64 release at a later time (e.g., late Wasmtime support for table64). We are optimistic that this will not take more than 2 months. Since other CDKs like Azle and Kybra also depend on the Rust CDK, their support is also delayed with a similar time frame. Wasm64 for wasi targets is not supported at the moment, we will investigate this problem further.
The Wasm64 platform is a more resource-intensive platform compared to its 32-bit counterpart, which leads to challenges in both code execution and canister scheduling. This will have to be treated by increases in instruction and dirty pages weights of 2X. This increase will not be proportional to overall cycle cost of messages since instructions are not the only cycle consumer for canisters. For example, the average mainnet message size in terms of instructions is approximately 1M (million) instructions. For messages this size, a cost increase of at most 6% is expected. The reasons for the proposed changes in instruction metering are as follows:
Several memory-related instructions (e.g., load/store) are more resource-intensive (because in 64-bit mode extra bound checks need to be made).
Since canisters will have more Wasm memory heap space, they will be able to execute more instructions, leading to challenges in scheduling and with regard to fairness.
Through benchmarking and following mainnet data, we have concluded that Wasm32 instruction costs for certain workloads are misaligned to actual machine resource usage. We propose to align these more accurately for the Wasm64 canisters.
While in beta, there might be additional changes to instruction costs and overall metering, stay tuned for our announcements. As a note, we propose to start with higher costs now as increasing price post-factum is more challenging. Should the system become more performant in the future, decreasing cost is always an option.
Is this targeting the wasm64-unknown-unknown target for Rust? For Azle and Kybra we will need a wasm64-wasi target of some kind, Wasi is integral to both Azle and Kybra.
Using Wasm64 and enhanced orthogonal persistence in Motoko, is an opt-in feature during the beta testing and initial roll-out phase. Users can select this by the compiler option --enhanced-orthogonal-persistence. The migrations happens automatically. Please note that reverse migration from 64-bit to 32-bit is not supported. You may find some useful information in the following post: Beta Testing Motoko’s Enhanced Orthogonal Persistence (EOP)
I am happy to provide more information and answer questions on Motoko persistence. Just let me know.
hey @lastmjs, I wasn’t aware Azle and Kybra were building to wasi. My message was indeed about wasm64-unknown-unknown. I’m not aware of any work to make wasm64-wasi happen at the moment. I guess we need to think some whether there’s any way to make Wasm64 happen for Azle and Kybra.
hey @icpp, unfortunately this does not apply to C++. For now we can’t have wasm64-wasi targets as far as I’m aware of.
(The issue with the Rust CDK was that the rust compiler was generating wasm64-unknown-unknown code using table64, which was not supported by Wasmtime. Now, thanks to @lwshang, this works and we could make use of it in the coming months, but also as an early beta/experimental version.)
@alex-df it seems there is a lack of information sharing about non-DFINITY CDKs, as the JavaScript, Python, and C++ CDKs all now rely on Wasi (Azle and Kybra have had this requirement for around 1 year now).
Is it possible for the non-DFINITY CDKs to meet with you or your team? I’m not sure why these requirements didn’t reach you.
Also I believe that Wasi should be the standard for all canisters on ICP. With it for example we get a filesystem (std::fs in Rust works for example) and we set ourselves up well for future socket capabilities.
The ic-wasi-polyfill has been excellent and I hope to see that polyfill pulled into the CDKs or replica officially.
Thank you for your message! We will make a more official announcement soon. On the replica side, the beta is ready and can be used in Motoko opaquely through the EAP feature, but for the Rust CDK there have been issues outside our control (for example, some rust toolchain issues when compiling to Wasm64).