availability-recovery: run CPU intensive work on separate thread

[sandreim]

Currently reconstructed_data_matches_root and reconstruct_v1 burn up to 1s of CPU time in the context of recovery-task: https://github.com/paritytech/polkadot/blob/master/node/network/availability-recovery/src/lib.rs#L956 .

We should investigate why this takes so much time for only 2.5MB data. Also we need to move this CPU intensive work in a separate thread (spawn blocking/rayon/spawn thread).

First image is reconstructed_data_matches_root + reconstruct_v1, second is just reconstructed_data_matches_root

[burdges]

Also, kagome C implementation of our erasure coding is faster than our Rust implementation.

[ordian]

These numbers don't match what I observed on https://github.com/paritytech/polkadot/blob/master/erasure-coding/benches/README.md, but that was on a faster CPU perhaps. Perhaps an easy (?) win would be refactoring the code: https://github.com/paritytech/reed-solomon-novelpoly/ to be autovectorizing-friendly (SIMD).

[sandreim]

Yes, it might be a slower CPU since we are running this on n2d GCP instances.

[koute]

Perhaps an easy (?) win would be refactoring the code: https://github.com/paritytech/reed-solomon-novelpoly/ to be autovectorizing-friendly (SIMD).

What might be worth testing is to try to compile with -C target-cpu=native and see if that makes a difference, since the baseline won't use more recent SIMD instructions (which can provide quite a bit of a speedup).

[vstakhov]

I doubt that auto-vectorization with just a compiler will speed GF^2 operations significantly. It might be interesting to try avx-512 GFNI instructions as they are designed exactly for that purposes.