[mhk197]

Part of #10159.

Summary

Take now runs as a kernel for FoR arrays with a reference per 1024-element chunk. It takes from the encoded child, then adds each value's reference, looked up from the chunk its index points into. Taken values no longer line up with chunks, so the result is a primitive array rather than a FoR array.

• A null index can hold any value, so its chunk is clamped to a valid one; its value stays null.
• When indices * 8 > len, the kernel declines and the array decodes before taking. This is the threshold BitPacked's take uses (UNPACK_CHUNK_THRESHOLD, now pub(crate)), and the many-reference decode is fused.
• Arrays with a single reference keep the existing kernel, which returns a FoR array.

Benchmarks

Local divan benchmark, not committed: random u32 indices into 128Ki BitPacked u32 values, Apple M5 Max, median.

indices	unblocked_kernel (single reference)	blocked_decode (no kernel)	blocked_kernel (this PR)
drifting, 1Ki	5.4 µs	13.2 µs	5.9 µs
drifting, 16Ki	77.2 µs	21.5 µs	88.4 µs
drifting, 32Ki	27.4 µs	30.4 µs	26.5 µs (declines)
uniform, 1Ki	5.2 µs	12.2 µs	5.5 µs
uniform, 16Ki	75.1 µs	20.2 µs	81.6 µs
uniform, 32Ki	26.8 µs	28.6 µs	25.7 µs (declines)

With few indices, the kernel is ~2.2x faster than decoding and within ~10% of a single reference. At 16Ki indices (exactly len / 8), both kernels are ~4x slower than decoding, because BitPacked's take unpacks random indices one at a time below its threshold. That affects the single-reference kernel too, so this PR leaves it alone.

Checks

• cargo nextest run -p vortex-fastlanes (374 passed)
• cargo clippy -p vortex-fastlanes --all-targets --all-features -- -D warnings
• cargo +nightly-2026-09-10 fmt -p vortex-fastlanes

[codspeed]

Merging this PR will degrade performance by 25.64%

⚠️ 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.

⚠️ 2 benchmarks measured no execution time

Nothing ran under measurement, usually because the compiler removed the code under test. These results are not comparable, so they count as unchanged.

Preventing compiler optimizations

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 1 regressed benchmark
✅ 2100 untouched benchmarks
⏩ 518 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	new_bp_prim_test_between[i64, 2048]	97 µs	130.4 µs	-25.64%
⚠️	Simulation	density_sweep_dense_runs[0.9]	53.1 µs	< 1 ns	N/A
⚠️	Simulation	bench_compare_sliced_dict_primitive[(3333, 10000)]	77.8 µs	< 1 ns	N/A

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing mk/for-kernels-take (ba18a98) with develop (c6e51ba)}

Footnotes

1. 518 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. ↩

[github-actions]

This PR has been marked as stale because it has been open for 14 days with no activity. Please comment or remove the stale label if you wish to keep it active, otherwise it will be closed in 7 days

[github-actions]

This PR was closed because it has been inactive for 7 days since being marked as stale.