You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Profile the correctness-preserving checks added or strengthened for v0.4.4 and recover avoidable success-path overhead in LU/LDLT factorization and determinant queries. Keep the work focused on fixed small dimensions and preserve the crate's mathematical invariants, typed diagnostics, public API, stack allocation, const evaluation, and no-unsafe policy.
This is not a target-driven request to beat another crate at one dimension. Optimize only where same-command evidence identifies removable la-stack overhead on equivalent valid inputs.
Current State
The published v0.4.4 comparison against v0.4.3 shows several coherent regressions on the representative vs_linalg inputs:
LDLT factorization regressed most strongly at small dimensions: D=2 2.1 ns → 6.7 ns (+225%), D=3 +97%, D=4 +70%, and D=5 +113%. Combined LDLT factor-and-solve rows regressed by roughly 53–146% over D=2–5, while D=8 and larger often improved. That makes the tiny-dimension factorization/validation path a higher-priority target than Ldlt::solve after factorization.
LU-backed determinant paths regressed across the core range. la_stack_det_via_lu is 34–68% slower for D=2–5, and the D=5 public det row is about 50% slower.
Determinants from precomputed factors also show large regressions at selected dimensions: det_from_lu is about +98% at D=5, +70% at D=8, and +98% at D=32; det_from_ldlt shows a similar pattern. These rows isolate determinant-query overhead from factorization.
Precomputed LU substitution is broadly stable through D=16, whereas combined LU factor-and-solve is +12% at D=8 and +3% at D=16. Do not assume Lu::solve is the primary problem without profiling the combined path and generated code.
The v0.4.4 behavior is the correctness baseline. In particular, balanced-range determinant results from older releases that violate current invariants are not valid performance evidence.
Proposed Changes
Reproduce the affected rows from the published report on one machine using the same benchmark binary, features, inputs, command, and environment for before/after measurements.
Profile or inspect generated code for the success paths before editing. Evaluate, without presuming causality:
the final factor-storage finiteness scan in LuFactors::try_from_computation;
the tiny-dimension LDLT normalization/update split and computed-non-finite checks;
per-factor range_checked_product classification and cold scaled fallback in Lu::det / Ldlt::det;
composition of the D≥5 Matrix::det LU fallback with factor and determinant validation.
Remove only demonstrably redundant work. Prefer a proof-bearing internal representation, cold diagnostic replay, or a cheaper equivalent range proof over skipping checks.
Keep dimension-specific branches only when the algorithm or same-binary evidence justifies them across representative inputs; do not tune a branch solely to rescue one noisy benchmark row.
Use focused bench-vs-linalg filters while iterating, then run the repository's local v0.4.4 comparison before making performance claims.
Correctness and API Guardrails
Preserve exact LaError categories and diagnostic locations for singular, non-finite, asymmetric, and non-positive-definite failures.
Preserve range-safe determinant behavior, including recovery from premature intermediate overflow/underflow and the documented final binary64 result contract.
Preserve partial pivoting, LDLT's exact-symmetry/SPD contract, Tolerance, and public method signatures.
Preserve stack allocation, const-generic dimensions, const fn where currently supported, and unsafe_code = "forbid".
Do not replace checks with debug_assert!, panics, sentinels, unchecked indexing, or benchmark-only fast paths.
Keep Criterion bencher.iter for the complete public-operation comparisons unless a separately justified, symmetric estimand change is proven not to distort the result.
Acceptance Criteria
The v0.4.4 regressions are reproduced or explicitly classified as non-reproducible with recorded same-command evidence.
Profiles or generated-code inspection identify the actual costs before implementation changes.
At least one material, correctness-preserving success-path cost is removed, or the issue records why the remaining cost is required by the v0.4.4 contract.
Before/after results use the same command, features, inputs, benchmark binary, and environment, with Criterion point estimates and intervals recorded.
Targeted LU/LDLT factorization, factor-and-solve, and precomputed determinant rows do not materially regress outside the optimized dimensions.
Known-value, adversarial, overflow/underflow, singularity, symmetry, and non-finite diagnostic tests continue to pass across applicable D=2..=5 coverage.
just ci passes before merge.
Any performance documentation changed by the work is regenerated through the repository's prescribed workflow.
Benefits
Recovers performance in the crate's documented fixed-small-dimension scope without retreating from v0.4.4 correctness.
Separates factorization, substitution, and determinant-query costs so future optimization is evidence-driven.
Establishes which invariant checks are intrinsic and which can be represented more cheaply.
Implementation Notes
Start with just bench-save-baseline v0.4.4-investigation vs_linalg, focused just bench-vs-linalg <filter> runs, and just bench-compare v0.4.4-investigation vs_linalg all-benches for the local edit loop.
Use just performance-local-vs-linalg v0.4.5 v0.4.4 for the PR-ready release-signal comparison once the focused work is stable.
Prioritize D=2..=16. D=32 and D=64 remain useful for detecting algorithmic or code-generation tradeoffs, but should not drive changes that hurt the core scope.
Summary
Profile the correctness-preserving checks added or strengthened for v0.4.4 and recover avoidable success-path overhead in LU/LDLT factorization and determinant queries. Keep the work focused on fixed small dimensions and preserve the crate's mathematical invariants, typed diagnostics, public API, stack allocation, const evaluation, and no-unsafe policy.
This is not a target-driven request to beat another crate at one dimension. Optimize only where same-command evidence identifies removable la-stack overhead on equivalent valid inputs.
Current State
The published v0.4.4 comparison against v0.4.3 shows several coherent regressions on the representative
vs_linalginputs:2.1 ns → 6.7 ns(+225%), D=3 +97%, D=4 +70%, and D=5 +113%. Combined LDLT factor-and-solve rows regressed by roughly 53–146% over D=2–5, while D=8 and larger often improved. That makes the tiny-dimension factorization/validation path a higher-priority target thanLdlt::solveafter factorization.la_stack_det_via_luis 34–68% slower for D=2–5, and the D=5 publicdetrow is about 50% slower.det_from_luis about +98% at D=5, +70% at D=8, and +98% at D=32;det_from_ldltshows a similar pattern. These rows isolate determinant-query overhead from factorization.Lu::solveis the primary problem without profiling the combined path and generated code.The v0.4.4 behavior is the correctness baseline. In particular, balanced-range determinant results from older releases that violate current invariants are not valid performance evidence.
Proposed Changes
LuFactors::try_from_computation;range_checked_productclassification and cold scaled fallback inLu::det/Ldlt::det;Matrix::detLU fallback with factor and determinant validation.bench-vs-linalgfilters while iterating, then run the repository's local v0.4.4 comparison before making performance claims.Correctness and API Guardrails
LaErrorcategories and diagnostic locations for singular, non-finite, asymmetric, and non-positive-definite failures.Tolerance, and public method signatures.const fnwhere currently supported, andunsafe_code = "forbid".debug_assert!, panics, sentinels, unchecked indexing, or benchmark-only fast paths.bencher.iterfor the complete public-operation comparisons unless a separately justified, symmetric estimand change is proven not to distort the result.Acceptance Criteria
just cipasses before merge.Benefits
Implementation Notes
just bench-save-baseline v0.4.4-investigation vs_linalg, focusedjust bench-vs-linalg <filter>runs, andjust bench-compare v0.4.4-investigation vs_linalg all-benchesfor the local edit loop.just performance-local-vs-linalg v0.4.5 v0.4.4for the PR-ready release-signal comparison once the focused work is stable.