core: don't recompute ReduceMax scalar after the SIMD max kernel

[czoli1976]

What

max_t (the f32 ReduceMax reducer in core/src/ops/nn/reduce.rs) called the vectorized max_f32 linalg kernel, discarded its result, then unconditionally recomputed the max with a scalar partial-ord fold over the same slice:

if T::datum_type() == f32::datum_type() && let Some(slice) = v.as_slice() {
    let slice = unsafe { transmute::<&[T], &[f32]>(slice) };
    (tract_linalg::ops().max_f32)().run(slice).unwrap();   // result thrown away
}
v.fold(T::min_value(), |acc, &v| if acc > v { acc } else { v })   // recomputed scalar

So every f32 ReduceMax did the reduction twice and was effectively scalar-bound — the "optimized" path was strictly slower than having no kernel at all.

The fix returns the SIMD kernel's result for the f32 contiguous case, and falls through to the scalar fold only for non-f32 dtypes, non-contiguous (strided) slices, or empty slices.

Benchmark

M-series, f32 max over the trailing (contiguous) axis, via the added core/examples/reduce_max_bench.rs:

shape	before	after	speedup
1024 × 4096	2.44 ms (6.9 GB/s)	0.32 ms (51.8 GB/s)	7.5×
4096 × 1024	2.46 ms (6.8 GB/s)	0.42 ms (40.1 GB/s)	5.9×
256 × 65536	9.44 ms (7.1 GB/s)	1.04 ms (64.9 GB/s)	9.1×

Identical results. Benefits ReduceMax, MaxPool, and the softmax max pre-pass.

Testing

• New unit test reduce_max_f32_contiguous_and_strided covers both branches (contiguous incl. non-multiple-of-SIMD-width tail, strided, single-element).
• Full tract-core suite passes (248).

Files

• core/src/ops/nn/reduce.rs — use the SIMD result; + test
• core/examples/reduce_max_bench.rs — benchmark

🤖 Generated with Claude Code

[kali]

Rebased!