Server-side Wasm/Wasi Support

[lastmjs]

What is the problem you want to solve and can not with the current version?

I would like to use the TFHE-rs server functionality in a 32 or 64 bit Wasm/Wasi backend environment. This is not possible currently.

Describe the solution you'd like

Please allow the Rust compilation target of wasm32-wasi and wasm64-wasi.

Describe alternatives you've considered

There are no alternatives when the requirement is for the library to compile and run its server-side components in a Wasm/Wasi 32 or 64 bit environment.

Additional context

I come from the ICP ecosystem and I would like to be able to build ICP applications (canisters) using TFHE-rs. For this to be possible we ideally need to be able to compile this library's server-side functionality to wasm32-wasi and soon wasm64-wasi.

[IceTDrinker]

hello @lastmjs

wasm32 is likely the wrong target given the size of the objects we manipulate.

wasm64 looks very experimental at best.

It is not in our current roadmap to support wasm for server side execution, however as we are open source you are welcome to contribute and discuss how to get this done.

Cheers

[Skyfacon]

I encountered the same problem here. I want to know how you solve this problem.

[vladilen11]

I have the same problem. We need build it on wasm32. 🚀

[IceTDrinker]

Basically at the moment wasm32 is generally a no go as some structs can go further than the 32 bits (31 in some cases) memory space, also TFHE-rs was designed on 64 bits targets for 64 bits targets initially, once wasm64 is usable then the story changes dramatically as it is "just" another platform that should be mostly supported by default bar some details regarding entropy generation.

We are open source so if there are contributions that are tested those could be integrated down the line.

We would likely not advertise a full wasm support, a bit like Rust does tiering for its platform supports. So it would likely be a "builds, not all the code is guaranteed to work properly" kind of situation initially as wasm execution is super slow compared to native code in our experience.

[nlok5923]

Hey @IceTDrinker can you elaborate on why wasm64 compilation is slow compare to the native code ?

[IceTDrinker]

Hey @IceTDrinker can you elaborate on why wasm64 compilation is slow compare to the native code ?

Wasm is slower than native code in general one of the reasons is that there is a code generation step that happens with the wasm bytecode after the code already has been transformed and information about the original code was lost, even if those code gen backends are good they have to fight with llvm which is a tall order. An other thing is wasm cannot express certain operations easily with its bytecode, like u64 to u128 widening mul, leading to a bunch of assembly the code gen backend cannot optimize while llvm could emit a single instruction on some platforms