perf: evaluate algebraic floating point for selected f64 functions #250

Summary

Evaluate Rust 1.99 algebraic floating-point operations for one or two promising existing f64 kernels, targeting v0.5.0. Produce a retained numerical/performance study and a per-function adopt, retain-strict, or defer decision. Adoption is conditional on the evidence; a documented negative result is a valid completion outcome.

Existing APIs remain strict. Any accepted algebraic implementation must have a distinct, explicitly opt-in public contract and preserve the crate's scientific invariants. The release number does not relax the correctness threshold.

Current state and prerequisites

• chore: upgrade to Rust 1.99 and audit numerical/codegen impact #251 is complete: the Rust 1.99 / LLVM 23 migration and strict-f64 audit are recorded in the migration study. This is the toolchain baseline; Rust 1.98 measurements are historical context.
• Coordinate final baseline capture with perf: avoid unnecessary exact elimination for triangular rational systems #246 / PR perf: accelerate triangular rational solves #278 landing. Use the final strict release-candidate implementation and record its source identity. Preliminary candidate analysis can proceed independently.

The evaluation no longer waits for v0.5.0 publication. It belongs to the v0.5.0 milestone; unresolved broader investigation or adoption must not delay that release.

Bounded scope

Select at most two kernels from dot products/reductions, matrix multiplication, matrix-vector multiplication, or squared norms, using existing cost evidence and code inspection to justify the selection. This issue does not promise an exhaustive survey of every operation.

Exclude predicates, interval/certified arithmetic, exact fallbacks, convergence/branch decisions, and error-bound construction. Preserve deliberate mul_add semantics wherever single-rounding FMA is part of the numerical contract. Exact continues to mean exact arithmetic.

Prototype in isolated disposable harnesses outside repository-owned Rust. Existing AGENTS.md and Semgrep prohibitions remain in force; retaining an opt-in implementation requires a reviewed, narrowly scoped policy/rule change.

Evaluation method

1. Capture the strict implementation and experimental source, dependency locks, rustc -Vv/LLVM version, target, features, profile, fixtures, and sampling settings.
2. Assess candidate numerical contracts against Rust's documented algebraic-operator semantics. These permit unspecified precision, nondeterministic results, and unexpected special-value behavior. Passing observed tests cannot establish a portable numerical guarantee that the documented semantics do not provide.
3. Compare with the strict implementation and independent exact/rational or analytical references. Cover cancellation, mixed/extreme magnitudes, signed zero, subnormals, overflow/underflow, and relevant non-finite input/intermediate behavior. Exercise D=2 through D=5 and each selected API's supported dimension boundaries.
4. Check relevant downstream Delaunay scientific/property/regression workloads. A changed geometric classification, predicate, topology decision, or validation outcome is a correctness failure.
5. Benchmark equivalent workloads on the same machine/toolchain/profile/features with correctness checks outside timing and no overlapping benchmark or validation jobs. Report absolute timings, uncertainty, and relative changes; inspect generated code where it explains the result.
6. Validate relevant numerical behavior on supported Linux, macOS, and Windows targets. State the limits of measured performance claims; empirical platform coverage supplements contract analysis.
7. Retain a study under docs/archive/performance/studies/, including raw evidence and source provenance, candidate selection, numerical findings, performance costs, limitations, and adopt/retain-strict/defer decisions. Preserve negative results. Incorporate accepted release results into the generated performance record through its owning workflow.

Adoption and release decision

• Adopt in v0.5.0 only when a candidate demonstrates a repeatable material benefit and a useful numerical contract supported by the documented semantics and correctness analysis. Specify its domain, accuracy guarantees or limitations, special-value/range behavior, and typed failures. A large speedup or absence of observed test failures is insufficient.
• Adoption uses a distinct, explicitly opt-in API. Feature gating may control its availability but must not change existing methods' semantics. Preserve strict defaults, exact/certified guarantees, and existing error provenance.
• Before adoption lands, review the API and scoped guidance/Semgrep changes, retain independent regressions, and complete required repository CI and downstream validation. Refresh the release performance record after the implementation is final.
• Defer adoption if the contract, evidence, API review, or release readiness remains unresolved. Record what was established and link a bounded follow-up issue. Compatible additions may target v0.5.1; changes incompatible with a published v0.5 API require an appropriate later minor release.
• Retain strict arithmetic when no candidate meets the threshold. Record that decision and close the completed evaluation; adopting algebraic operations is not required to close this issue.
• If the bounded evaluation itself cannot finish in the release window, explicitly transfer remaining scope and evidence to follow-up planning. Do not claim an unfinished evaluation or unverified adoption is complete.

Acceptance criteria

• Select and justify at most two candidates, retaining the exclusions above.
• Use the completed chore: upgrade to Rust 1.99 and audit numerical/codegen impact #251 baseline and capture the final strict candidate's source/environment identity.
• Retain independent adversarial numerical checks, relevant native-platform validation, and downstream scientific evidence.
• Retain comparable strict-versus-algebraic timings and a durable per-function findings/decision table.
• Assess whether the proposed contract is supportable under documented compiler semantics; distinguish guarantees from empirical observations.
• If adopting, satisfy the opt-in contract, API/policy review, independent regressions, final CI, and release-evidence requirements before shipping.
• Record a justified adopt, retain-strict, or defer disposition and link any transferred unfinished work. Do not hold v0.5.0 for an unbounded optimization effort.

Non-goals

• Globally enabling fast-math-like semantics or changing existing APIs to algebraic arithmetic.
• Weakening exactness, outward bounds, typed errors, or downstream scientific correctness for benchmark results.
• Duplicating every public operation into strict/algebraic variants.
• Replacing intentional FMA merely to use the algebraic API.