[C++][Parquet] Rewrite BYTE_STREAM_SPLIT optimizations using xsimd

[pitrou]

Describe the enhancement requested

Currently, there are BYTE_STREAM_SPLIT optimizations using hand-written x86 intrinsics (for SSE4.2, AVX2 and AVX512), selected at compile-time.

We should rewrite those using the xsimd library so as to provide support for non-x86 ISA extensions such as Arm Neon (most importantly) and SVE.

More precisely:

• rewrite the SSE4.2 acceleration for generic 128-bit SIMD
• rewrite the AVX2 acceleration for generic 256-bit SIMD
• either rewrite the AVX512 acceleration, leave it alone, or remove it (the benefits are probably minor)

Component(s)

C++, Parquet

[pitrou]

cc @cyb70289 @mapleFU

[mapleFU]

IMO, Parquet itself has so many hand-written AVX2(mostly in Levels handling, some are in decode etc). So, for parquet, mixing AVX512 and AVX2 may causing performance loss. But if user just want to use this encoder, AVX512 might be useful(Also, AVX10 is coming now...)

[pitrou]

mixing AVX512 and AVX2 may causing performance loss

This sounds like an urban legend at this point.

But if user just want to use this encoder, AVX512 might be useful

The user doesn't want "an encoding", they want space spavings. BYTE_STREAM_SPLIT is only useful in conjunction with a (de)compressor, so the main objective is to be fast compared to (de)compression.

[mapleFU]

This sounds like an urban legend at this point.

Before Icelake optimization [1] [2], AVX512 might cause de-freq when using it [3]

[1] https://www.hc32.hotchips.org/assets/program/conference/day1/HotChips2020_Server_Processors_Intel_Irma_ICX-CPU-final3.pdf
[2] https://travisdowns.github.io/blog/2020/08/19/icl-avx512-freq.html
[3] https://lemire.me/blog/2018/08/15/the-dangers-of-avx-512-throttling-a-3-impact/

[pitrou]

Ok, but 1) those are relatively old CPUs 2) the performance loss is not caused by mixing AVX2 and AVX512, but simply by using AVX512 ;-)

[pitrou]

FTR, AVX512 variants were removed in #40127

[pitrou]

After grepping through the xsimd include files, it seems that:

• the 128 bit (currently SSE4.2) variants can probably be migrated to arch-agnostic xsimd code
• the 256 bit (currently AVX2) variants use _mm256_unpack{lo,hi}_epi8 and permutations in a non-trivial way that may be difficult to reproduce using xsimd

This means to we could at least migrate the 128 bit paths to xsimd, which may get us NEON acceleration.

[mapleFU]

Nice analysis, I can have a try on migrating this, but I'm a SIMD newbie, some help is need

[pitrou]

Or perhaps @cyb70289 wants to take it up :-)

[cyb70289]

I may not have bandwidth recently. I believe @mapleFU can do it well. Ping me if you need help.

[pitrou]

Issue resolved by pull request 40335
#40335