base64 AVX2 - Use half avx2 to smooth the performance cliffs on small payloads when encoding - #1041

Short title (summary):

Smooth AVX2 Base64 encoding ramp-up with 12/24-byte tails

Description

Add 12-byte and 24-byte AVX2 encoding paths that reuse the existing AVX2 packing and alphabet-translation pipeline. This avoids falling back entirely to scalar encoding for inputs and tails that are too short for the regular AVX2 loop, substantially reducing the performance cliffs at 28-byte intervals.

This is very similar to what is already being done in the tail handling of src/icelake/icelake_base64.inl.cpp using AVX-512.

NEON also does this partially (src/arm64/arm_base64.cpp) but not fully - we could add a custom 12 byte tail handling there as well. I'll submit it later if I can find the time.

• Related PR: base64 scalar - Improve performance of scalar base64 decoder and encoder #1037 but can be merged independently

Type of change

• Bug fix
• Optimization
• New feature
• Refactor / cleanup
• Documentation / tests
• Other (please describe):

How to verify / test

• Add additional tests to verify bugs or new features.
• If you claim performance gains, you should provide benchmark numbers using high quality benchmarking code.

Checklist before submitting

• I added/updated tests covering my change (if applicable)
• Code builds locally and passes my check
• Documentation / README updated if needed
• Commits are atomic and messages are clear
• I linked the related issue (if applicable)

Final notes

This PR address the performance cliff observed on small payloads as AVX2 improvements are degraded by tails until another AVX2 window can be used. The strategy is to run AVX2 against a partial vector. There is a point where the overhead of a partial vector balances the overhead of the tail - this is where it is interesting to switch.

The effect compounds with #1037 as shown below.

Notice the gap in performance on byte 28 in master - this is when we introduce the first AVX2 block processing - and then we have another ramp up:

Here we have another performance cliff, followed by another ramp up:

And another here.

So the approach significantly reduces the cliffs. It can be further improved with SSE (i.e. transitioning from scalar -> partial SSE -> full SSE -> partial AVX2 -> full AVX2 -> full AVX2 + scalar -> ...

going to partial AVX 512 would also be interesting

But adding SSE substeps would have increased the complexity here and the gains are not as important. If interested, I am happy to provide it as another PR.