perf: vectorize small u8 table take with NEON

[joseph-isaacs]

Rationale

Low-cardinality dictionaries with u8 codes and one-byte values can decode through an in-register NEON table instead of arbitrary scalar lookups.

Stacked on benchmark baseline #9566. The x86 implementation is intentionally split into the next PR.

Changes

• Use NEON TBL on little-endian AArch64.
• Apply the path to u8 codes, at most 16 one-byte values, and at least 64 rows.
• Retain bounds checks and the existing fallback.
• Add correctness and out-of-bounds tests.

CodSpeed wall-time results

Medians over 1,000 samples on Graviton3 metal, compared with #9566:

Rows	Baseline	NEON	Speedup	Time reduction
1M	552.4 µs	51.06 µs	10.82×	90.8%
16M	8.786 ms	799.7 µs	10.99×	90.9%

Runs: baseline, optimized.

Checks

• focused small-table correctness and bounds tests
• targeted Clippy with warnings denied
• cargo +nightly fmt --all --check
• git diff --check

[codspeed-hq]

Merging this PR will improve performance by ×3

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 5 improved benchmarks
✅ 2188 untouched benchmarks
⏩ 218 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	WallTime	dict_canonicalize_gt_u8_neon[16000000]	9,349.5 µs	778.3 µs	×12
⚡	WallTime	dict_canonicalize_gt_u8_neon[1000000]	559.9 µs	50.6 µs	×11
⚡	WallTime	arrow_checked_add_u32_neon[16384]	20.4 µs	13.3 µs	+53.36%
⚡	WallTime	words_gather_scalar_avx2[65536]	9.4 µs	8.3 µs	+13.45%
⚡	WallTime	words_gather_dispatch_avx512[1024]	9 ns	8 ns	+12.5%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ji/small-u8-table-take-neon (a5329ec) with develop (2a5b1a7)²}

Footnotes

1. 218 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on develop (9d1b103) during the generation of this report, so 2a5b1a7 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩