[connortsui20]

Tracking Issue: #10701

Stacked on #10990, which adds the copy_to_canonical_width benchmark first so that CodSpeed measures this change.

Summary

copy_to_canonical_width widens decimal values whenever a path needs the canonical array, such as the Arrow and DuckDB imports and interleave. Once DecimalByteParts decodes to a decimal Widen (#10946, #10905), every export of a narrow column to DuckDB, or to Arrow above precision 18, pays for this copy. Its loop left some widths scalar, and i64 to i128 is now about 1.75x faster on Apple M4.

Changes

widen_values collected through BufferMut::extend_iter, whose write loop has two exits (the reserved count and the end of the iterator), and its checked cast added a panic edge. LLVM still vectorized i32 to i64, but left other widths scalar, such as i64 to i128. The loop now builds the buffer with Buffer::from_trusted_len_iter and falls back to zero on a failed cast, which can't happen when the target is at least as wide as the source, so it has one exit and no panic edge. widened_buffer now calls widen_values instead of its own copy of the loop.

A runtime assert! checks the width order, and folds away because both sides are constants. A const assert doesn't compile here: the callers dispatch with if const, and rustc still evaluates the inline constants of every function that the disabled branches name.

Widening into i256 got 1.24x (i128 to i256) to 1.7x (i32 to i256) slower on Apple M4, and the cause is not known. That only happens at precision 39 to 76, and most such columns will decode to a decimal Widen once #10946 and #10905 land, so one loop for every width is the simpler trade.

test_widen_values_sign_extends checks all 15 widening pairs against a per-value cast, with enough values to run both a vector body and a scalar tail.

The CodSpeed simulation run (x86 with AVX2) showed no change in any case, so #10990 now runs the benchmark on the walltime CPU-feature legs, where the NEON leg is the one that matches the M4 result.

Benchmark results (Apple M4)

cargo bench -p vortex-array --bench copy_to_canonical_width, 16,384 values with no nulls. Before is the benchmark commit (#10990) and after is the tip of this PR, so the comparison isolates this layer. Each number is the median of three alternating runs of each binary, with 300 samples per run. These numbers come from the earlier version of the benchmark, which also had half-null cases with the same ratios.

case	before (ns)	after (ns)	before / after
i32_to_i64	1103	1083	1.02
i64_to_i128	4624	2624	1.76
i128_to_i256	6749	8332	0.81
same_width_i64 (control)	1176	1177	1.00

API Changes

None.

[codspeed]

Merging this PR will regress 3 benchmarks

1 warning

⚠️ Walltime results may be unreliable

Some benchmarks used the Walltime instrument outside CodSpeed Macro Runners, which can make the results inconsistent.

Learn more about Macro Runners

See affected benchmarks

⚡ 5 improved benchmarks
❌ 3 regressed benchmarks
✅ 2310 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	CPU Simulation	missing_stats[16]	67.2 µs	85.1 µs	-20.99%
❌	CPU Simulation	encode_primitives[u8, (2000, 4)]	134.8 µs	163.7 µs	-17.67%
❌	CPU Simulation	random_i8[0.01]	99 µs	113.2 µs	-12.55%
⚡	CPU Simulation	filter_powerlaw_by_random[10000]	1,125.5 ns	583.5 ns	+92.87%
⚡	Walltime	i128_to_i256_neon	14.4 µs	10.5 µs	+37.35%
⚡	Walltime	i64_to_i128_neon	13.5 µs	10.3 µs	+30.78%
⚡	CPU Simulation	take_filter_primitive_small_uncached_random_mask_random_indices[4096, 10]	24.5 µs	20.9 µs	+17.22%
⚡	CPU Simulation	max_f64	312.9 µs	283.2 µs	+10.48%

Tip

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

---

_{Comparing ct/decimal-widen-copy (0da7340) with develop (1850cab)}

[robert3005]

I would check the lanezip (and related) these are written so they simd better. I think from_trusted_len_iter cannot quite avoid bounds check

[connortsui20]

initial test shows that the lanezip is slower for i32->i64 on M4, am spinning up some EC2 instances to double check (and also ask why)

[connortsui20]

Keeping the current loop in this PR: the bounds-check concern does not reproduce, and map_into introduces large regressions on ARM and AVX-512. The follow-up is to improve map_into's tiling separately, since a diagnostic larger-tile run removes the ARM regression.

Benchmark results and diagnostic experiment

Baseline is this PR at d09193ef532c. The candidate replaces the trusted-iterator construction in widen_values with the related unary map_into helper, keeping the cast and output allocation. Rust 1.99.1, LLVM 23.1.1, bench profile, 16 CGUs, no LTO, MiMalloc, 16,384 non-null values. Each result is the median paired candidate/baseline ratio from seven alternating pairs, with 300 samples and a 0.3-second minimum per case. Higher is slower. EC2 runs were pinned to CPU 2, with its SMT sibling disabled on C7i. The M4 runs were unpinned.

Case	M4 Max	Graviton3, NEON	C7i, AVX2	C7i, AVX-512
i32 -> i64	1.82x	1.80x	1.01x	1.00x
i64 -> i128	0.95x	0.47x	1.03x	1.03x
i128 -> i256	1.00x	0.83x	1.00x	1.55x
Same-width copy control	1.00x	1.00x	1.00x	1.00x

The C7i runs use the AVX2 and full AVX-512 feature sets from CI on the same Xeon Platinum 8488C. Graviton3 uses +neon without SVE.

For the i32 -> i64 diagnostic, separate interleaved three-way runs gave:

Machine	Current loop	map_into, 64-row tiles	map_into, 1024-row tiles
M4 Max	1.166 us	2.124 us	1.165 us
Graviton3	1.788 us	3.251 us	1.786 us

The 64-row body uses narrower loads and individual stores. A 128-row experiment restored wider paired operations but recovered only part of the slowdown. The 1024-row version restores a compact rolled vector loop with the same inner instruction sequence as the current implementation. Allocation and conversion work are unchanged. This isolates a lane-tiling/code-generation sensitivity, while the exact hardware bottleneck remains unresolved. A separate prototype keeps map_into unchanged by default and adds an explicit widening opt-in: retain the tiled loop up to 128 values, then use one untiled loop. In six alternating pairs at 16,384 values, this reduces time against stock map_into by about 48% on M4 and 44% on Graviton3 for i32 -> i64, and 35% on C7i AVX-512 for i128 -> i256. AVX2 is roughly unchanged. Some short integer cases still cost about 1 ns more, floating-point results are mixed, and unchanged controls show placement sensitivity. That supports a selective follow-up, rather than replacing every map loop.

[connortsui20]

im going to merge this but I think we can potentially speed up map_into as well, would be a followup PR