perf: evaluate algebraic floating point for selected f64 functions

[acgetchell]

Summary

Evaluate Rust 1.99 algebraic floating-point operations for selected existing f64 functions in la-stack and determine whether they provide a material performance improvement without unacceptable numerical or downstream correctness changes.

This is an evaluation, not a request to change la-stack's default floating-point semantics. Correctness remains the priority: ordinary f64 operations stay strict by default, existing exact/certified arithmetic remains unchanged, and algebraic floating point should be adopted only for functions where evidence justifies it.

Target this work for v0.4.7 after #251 establishes the final Rust 1.99 / LLVM 23 strict-f64 baseline. This issue must evaluate algebraic floating point against the toolchain and strict implementation that v0.4.7 actually intends to ship.

Prerequisite

• chore: upgrade to Rust 1.99 and audit numerical/codegen impact #251 complete: Rust 1.99 migration, correctness audit, codegen/performance audit, and PERFORMANCE.md baseline established.

Do not use a Rust 1.98 / LLVM 22 result as the acceptance basis for this issue. Historical 1.98 measurements may be retained for context, but the adopt/retain-strict decision must be made under the completed Rust 1.99 baseline.

Motivation

Rust's algebraic floating-point operations can permit reassociation and expose additional vectorization/parallel reduction opportunities. Some existing f64 functions may benefit, but relaxed semantics can change rounding behavior and handling of exceptional values such as NaN, infinities, and signed zero.

Exact should continue to mean exact arithmetic; it should not become the fallback for strict floating-point behavior. Algebraic floating point should therefore be evaluated function-by-function against the current strict Rust 1.99 implementation.

The purpose of this issue is as much correctness evaluation as performance evaluation. If a function cannot preserve an acceptable numerical/public contract under algebraic operations, it remains strict regardless of speedup.

Candidate functions

Start with existing functions where reassociation/vectorization has a plausible payoff and where behavior can be characterized independently, for example:

• dot products and related reductions
• matrix-vector multiplication
• matrix-matrix multiplication
• squared norms or similar reduction-heavy f64 functions

Do not initially apply algebraic operations to predicates, interval/certified arithmetic, exact fallbacks, convergence/branch decisions, error-bound construction, or other functions whose correctness depends on strict evaluation or IEEE-754 exceptional-value behavior.

Preserve deliberate mul_add() use where a single-rounding FMA is part of the intended numerical implementation; algebraic operations are not a replacement for intentional FMA semantics.

Evaluation method

For each candidate function:

1. Use the completed chore: upgrade to Rust 1.99 and audit numerical/codegen impact #251 Rust 1.99 / LLVM 23 strict implementation as the baseline.
2. Implement a disposable or feature-isolated algebraic variant without changing the public API.
3. Compare numerical results across representative and adversarial inputs, including cancellation, mixed magnitudes, signed zero, subnormals, overflow/underflow boundaries, and non-finite values where the public contract permits them.
4. Run existing property/regression tests and relevant exact/certified comparisons.
5. Run representative downstream Delaunay workloads where the function is used; a local numerical change that alters a geometric classification, predicate outcome, topology decision, or validation result is a correctness failure.
6. Benchmark strict versus algebraic implementations using identical Criterion fixtures, profiles, toolchains, and features, with correctness checks outside timed regions.
7. Inspect generated code/vectorization where useful to explain any measured change rather than assuming algebraic operations are faster.
8. Record the evaluated functions, numerical findings, benchmark results, environment/methodology, and final adopt/retain-strict decisions in PERFORMANCE.md, including negative results.

Acceptance criteria

• chore: upgrade to Rust 1.99 and audit numerical/codegen impact #251 is complete and its Rust 1.99 / LLVM 23 strict-f64 baseline is the sole acceptance baseline for this issue.
• Identify candidate existing f64 functions and document why relaxed reassociation is mathematically acceptable or unacceptable for each one.
• Keep ordinary f64 semantics strict by default and leave exact, interval, certified, predicate, and error-bound arithmetic unchanged unless separately justified.
• Add numerical comparisons against the strict implementation and independent/exact references where available; include cancellation, extreme magnitudes, signed zero, subnormals, and exceptional values relevant to each contract.
• Demonstrate that relevant downstream Delaunay scientific/property/regression tests retain their required behavior.
• Benchmark each candidate function against its strict Rust 1.99 implementation on the same machine/toolchain/profile and report both absolute timings and relative changes.
• Record a durable per-function results table and methodology in PERFORMANCE.md: strict baseline, algebraic result, correctness findings, performance delta, and final decision. Record rejected/negative candidates as well as adopted ones.
• Adopt algebraic operations only where the performance improvement is material and the numerical/downstream correctness evidence is acceptable. Small wins do not justify weaker semantics.
• If no candidate clears that bar, retain strict arithmetic and record the negative result so the experiment does not need to be repeated without new compiler/hardware evidence.
• If any function adopts algebraic operations, document its numerical contract and constrain future use through repository guidance/Semgrep so algebraic floating point remains explicitly approved and localized.

Non-goals

• Do not globally enable fast-math-like semantics.
• Do not make algebraic arithmetic the default meaning of f64 in la-stack.
• Do not duplicate every public operation into strict/algebraic variants.
• Do not weaken exact, interval, certified, or downstream geometric correctness guarantees for benchmark results.
• Do not replace intentional FMA usage merely to use the new API.