[C++] Explore SIMD optimization for base64_decode

[Reranko05]

Describe the enhancement requested

The current base64_decode implementation processes input byte-by-byte using scalar operations.

This came up while working on a recent change to improve validation performance (PR #49660), where replacing find() with a lookup table highlighted that decoding itself is still done sequentially.

Since base64 decoding follows a regular pattern (4 chars → 3 bytes), it seems like it could benefit from SIMD/vectorized approaches (e.g., AVX2), especially for larger inputs.

I wanted to check:

• Is exploring a SIMD-based decoding path something that would be in scope for Arrow?
• Have there been any prior attempts or discussions around this?
• Would a CPU-dispatched approach (SIMD + scalar fallback) be acceptable here?

I haven’t explored SIMD in this area yet, but happy to prototype something or run comparisons if this aligns with project direction.

Component(s)

C++

[Reranko05]

@kou @dmitry-chirkov-dremio I’d appreciate your thoughts here since this came up while working on PR #49660.

[dmitry-chirkov-dremio]

What sort of input are you looking for and what research have you done so far? Did you look at the repo history to find if/how similar work was tackled in the past?

[Reranko05]

Hi @dmitry-chirkov-dremio, this was mainly for larger inputs, where processing each byte starts to add up.

On the research side, I traced the history back to #5493, where the current base64 implementation was introduced as a vendored version of cpp-base64. From what I can see, it has mostly remained unchanged apart from API updates and recent correctness fixes.

I also looked through the repo history and didn’t find any prior work on vectorizing this decode path. The earlier improvements like the LUT are still within the scalar approach.

So this was more of an initial observation I can dig further if there’s actually meaningful benefit.

[kou]

Let's sort out our use cases of base64 as the first step. We can discuss what inputs should we optimized and whether we should optimize these inputs or not based on our use cases.

[Reranko05]

@kou That makes sense.

From what I checked, base64_decode is mainly used in Parquet-related paths (schema, keys), which look like metadata and likely involve relatively small inputs. There is also usage in Gandiva (base64_decode_utf8), which could have larger inputs, but I haven’t fully traced its usage yet. The Gandiva implementation processes the full input buffer and allocates output accordingly, so it can handle larger inputs in principle, but it’s still unclear what typical sizes or call frequency look like in practice.

Does Gandiva sound like the right place to focus for potential larger inputs, or are there other use cases I should look into?

[pitrou]

I think this is the wrong approach. One should first start profiling Flight or Parquet workloads and find out whether base64 decoding is a performance hotspot in those cases (I doubt it is). If it is, then we can talk about optimizing base64 decoding.

[Reranko05]

That makes sense @pitrou, I can start by adding lightweight instrumentation around base64_decode (call frequency, input sizes, time spent) in Parquet/Flight paths to see if it shows up in practice.

If there’s an existing profiling setup or representative workload in Arrow I should use, I can align with that.

[dmitry-chirkov-dremio]

I do not have concerns about base64's performance for Gandiva use cases at this point.

If there's a passion for such low-level work I'd suggest you look at current issues and open pull request and assist with those.
(GH-40031? GH-47769? GH-48160 was an interesting miss that was not captured by CI.)

[Reranko05]

Thanks @dmitry-chirkov-dremio for the clarification I’ll close this for now.
I’ll take a look at the suggested issues and focus on those instead.