Implement concurrency where it is beneficial

[c0dearm]

It seems having some threading concurrency could be beneficial, especially for large secrets, where it could be possible to compute multiple parallel Lagrange interpolation roots, one for each secret chunk.

Maybe in some other parts is also valuable, but it needs investigation.

Tasks:

• Investigate which parts of the code could benefit from concurrency
• Implement threading where necessary
• Implement unit tests for the threading
• Implement benchmark tests for the threading
• Check threading doesn't add much overhead for short secrets and that is very beneficial for large secrets
• Make the number of threads a configurable parameter, with default option "auto".

[zer0x64]

It would be good to make sure you don't break compatibility with it. The crate currently builds in WASM(didn't test if it works though), so that means that it probably builds on any platform right now, but adding threading/SIMD/etc. should be done conditionnally to make sure it doesn't break anything.

[c0dearm]

I am fairly new to Rust and even more to Web Assembly, in which way threading could break compatibility with other platforms?

[zer0x64]

Some platform doesn't or barely support threading(WebAssembly is a prime example, along with some bare metal targets) and a really nice feature of Rust is that it allows for extremely portable code, so people tend to use these methods conditionnally(using #[cfg(...)] annontations).

A great example is the RustCrypto project, which, AFAIK, every crate works on every platform while still using threads, SIMD and AES-NI when possible but falling back on pure platform-agnostic code when they can't.

I got some experience with it so I can help if you need it! Also, we can still modify the CI to add specific targets (WASM is a great way to test portable code as it lacks a whole lot of platform feature and is pretty easy to build). I could also write the WASM bindings which would only build when building for WASM.

[c0dearm]

Indeed, if threading is going to break compatibility in different targets we should target its compilation and usage with the #[cfg] attribute. I really want this to work, especially on mobile and web.

So yeah, I think it is better if first we make this library work for WASM, which your help will be very welcome for. Once we have it working for WASM we can start with the threading, so that we can check that we don't break it while we implement it. I will create another issue to track the WASM progress.

[c0dearm]

Depends on #7

[zer0x64]

#7 is done on the other repo! Now we just need to make sure an update here doesn't break the WASM version.

[c0dearm]

Yes! I wonder if it is possible to trigger sharks-wasm pipeline from here. Will investigate tomorrow.