Provide SSSE3, AVX2, and AVX512 optimized Reed-Solomon functions

[cgutman]

Description

I spun this out of #2803 when it became evident that the simple solution of just adding -mssse3 wouldn't work.

This implementation uses GCC support for function targets to compile the Reed-Solomon code multiple times for SSSE3, AVX2, AVX512, and the default ISA flags. It provides a faster implementation than just hardcoding -mssse3 while also not breaking non-x86 architectures or older x86 CPUs without SSSE3. It's definitely more complex than a compiler flag, but I think the performance gain is worth it and the complexity is pretty compartmentalized to rswrapper.h/c.

On my Ryzen 5950X, AVX2 is about 2x faster than SSSE3 which is about 4x faster than the C variant.

Samples: 3K of event 'cycles:P', 4000 Hz, Event count (approx.): 1243747209 lost: 0/0 drop: 0/0
Overhead  Shared Object                  Symbol
   7.28%  sunshine-0.0.0.29410c64.dirty  [.] obl_axpy_avx2.part.0

Samples: 9K of event 'cycles:P', 4000 Hz, Event count (approx.): 3392272030 lost: 0/0 drop: 0/0
Overhead  Shared Object                  Symbol
  14.14%  sunshine-0.0.0.29410c64.dirty  [.] reed_solomon_encode_ssse3

Samples: 5K of event 'cycles:P', 4000 Hz, Event count (approx.): 3762589726 lost: 0/0 drop: 0/0
Overhead  Shared Object                  Symbol
  59.20%  sunshine-0.0.0.29410c64.dirty  [.] reed_solomon_encode_def

Screenshot

Issues Fixed or Closed

Fixes #2543

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[codecov]

Codecov Report

Attention: Patch coverage is 46.15385% with 14 lines in your changes missing coverage. Please review.

Project coverage is 9.04%. Comparing base (6607a28) to head (a0d6f26).
Report is 136 commits behind head on master.

Files with missing lines	Patch %	Lines
src/rswrapper.c	48.00%	11 Missing and 2 partials ⚠️
src/stream.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #2828      +/-   ##
=========================================
+ Coverage    8.99%   9.04%   +0.05%     
=========================================
  Files          95      96       +1     
  Lines       17312   17437     +125     
  Branches     8236    8276      +40     
=========================================
+ Hits         1557    1578      +21     
- Misses      12890   12968      +78     
- Partials     2865    2891      +26     

Flag	Coverage Δ
Linux	6.80% <24.00%> (-0.01%)	⬇️
Windows	4.25% <26.92%> (+0.09%)	⬆️
macOS-12	10.06% <24.00%> (-0.04%)	⬇️
macOS-13	9.97% <24.00%> (-0.04%)	⬇️
macOS-14	10.29% <85.71%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/stream.cpp	0.86% <0.00%> (-0.06%)	⬇️
src/rswrapper.c	48.00% <48.00%> (ø)

... and 4 files with indirect coverage changes

[moi952]

Hi, I did some research and this ticket helps optimize network encoding and transmission latency?
Thanks

[sleepybishop]

Nice work on the runtime detection. There are better ways to implement axpy in AVX512 with GFNI but I have not done much error correcting work lately. I'm eager to revisit it soon as there's many advancements I'd like to read up on in greater detail.

Would you happen to have any metrics around shard counts ? Eg. A histogram of data and repair shards counts.