[mkleen]

Which issue does this PR close?

• Follow-up refactor: Centralize float normalization #26595

Rationale for this change

normalize_floats runs on every float key column before it is compared, hashed or grouped. It first scans the column for values that need rewriting. When there are none, which is the common case, it returns the input unchanged, so that scan is the whole cost.

The scan used an early-exit iter().any(). Because the loop can stop at any value, the compiler checks one value at a time and doesn't vectorize it.

Results from the float_normalization benchmark on 8192 values from my local machine (Apple M1 Max):

┌─────────────────────┬─────────┬─────────┬────────────────┐
│        Case         │  main   │   PR    │     Change     │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f64, clean          │ 2.62 µs │ 0.71 µs │ −73% (3.7x)    │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f32, clean          │ 2.63 µs │ 0.34 µs │ −87% (7.7x)    │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f16, clean          │ 2.62 µs │ 0.18 µs │ −93% (14.7x)   │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f64, -0.0 first row │ 1.66 µs │ 1.75 µs │ +5%            │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f32, -0.0 first row │ 0.74 µs │ 0.79 µs │ +7%            │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f16, -0.0 first row │ 0.31 µs │ 0.33 µs │ +7–14% (noisy) │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f64, -0.0 last row  │ 4.23 µs │ 2.35 µs │ −44%           │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f32, -0.0 last row  │ 3.35 µs │ 1.09 µs │ −68%           │
├─────────────────────┼─────────┼─────────┼────────────────┤
│ f16, -0.0 last row  │ 2.98 µs │ 0.51 µs │ −83%           │
└─────────────────────┴─────────┴─────────┴────────────────┘

What changes are included in this PR?

• The scan in normalize_primitive now checks the values in chunks of 1024. Inside a chunk it folds over every value with no early exit, so the compiler turns it into a SIMD OR-reduction. It stops after the first chunk that finds a value to rewrite.
• When a -0.0 is near the start, the whole first chunk is still checked before the scan stops. That adds 20–90 ns, and the column is copied right after anyway.
• A new float_normalization benchmark covers f64, f32 and f16, with nothing to rewrite, a -0.0 in the first row, and a -0.0 in the last row.

What is the testing strategy for this PR?

The behavior is unchanged. The existing normalize_floats unit tests in float_semantics.rs and the float sqllogictests cover both the case with nothing to normalize and the rewrite path.

Are there any user-facing changes?

No.

LLM-generated code disclosure

This PR includes LLM-generated code and comments. All LLM-generated content has been manually reviewed.

[jayzhan211]

Benchmarks are available #26954 and must be merged first

I think given the complexity we don't need to split PRs that much

[mkleen]

Benchmarks are available #26954 and must be merged first

I think given the complexity we don't need to split PRs that much

fair point :-)

[kumarUjjawal]

Thank you @mkleen

Left few comments please take a look

[kumarUjjawal]

The fold now always reads the whole column, even when a -0.0 is in the first row. Folding in fixed chunks (e.g. 512 values) and stopping after the first chunk that finds one would keep the SIMD speedup and still exit early.

[mkleen]

Thanks for the review @kumarUjjawal!

I addressed your feedback:

• Early exit (float_semantics.rs)
• -0.0 near the start, and Float16 (float_normalization.rs) for the benchmarks.

I updated the benchmark run in the pr description.
We actually have a small regression with the cases you pointed out when -0.0 is the first row.