sepehr
3808e0f11b
Some checks failed
CI / check (push) Has been cancelled
Checkpoint incomplete calibration work (cond SDT green, evap SST failing) plus related solver/UI changes so the next pass can fix and extend safely. Co-authored-by: Cursor <cursoragent@cursor.com>
22 lines
1.6 KiB
Markdown
22 lines
1.6 KiB
Markdown
# faer vs nalgebra dense LU — comparative report (Story 1.5, 2026-07-19)
|
||
|
||
Environment: Windows 11 x64, rustc 1.89 (stable, pinned), release profile, criterion 0.5.
|
||
Backends: `NalgebraLuSolver` (nalgebra 0.33 LU) vs `FaerLuSolver` (faer 0.24.4 partial-pivot LU), both behind the `LinearSolver` trait with identical Ruiz equilibration and zero-alloc solve.
|
||
|
||
| Benchmark | nalgebra | faer | ratio (faer/nalgebra) |
|
||
|---|---|---|---|
|
||
| factor 9×9 (mock cycle Jacobian) | 308 ns | 1.23 µs | **4.0× slower** |
|
||
| solve-per-RHS 9×9 | 83 ns | 245 ns | 3.0× slower |
|
||
| factor 50×50 (synthetic dense) | 19.4 µs | 20.4 µs | 1.05× slower |
|
||
| solve-per-RHS 50×50 | 589 ns | 1.11 µs | 1.9× slower |
|
||
|
||
## Verdict
|
||
|
||
At Entropyk's current system sizes (n ≤ ~100), **faer is NOT faster than nalgebra** — the assembled-matrix conversion (nalgebra → faer column-major Mat) costs at factor time on small n, and faer's threading edge only materializes at larger n. faer stays an **opt-in** alternative (`solver.linear_backend = "faer"` / `ENTROPYK_LINEAR_BACKEND=faer`); **nalgebra remains the default** — the strangler data does not justify retirement, and none was planned in this story.
|
||
|
||
Revisit when: (a) block-dense/Schur systems push n into the hundreds (Epic 2 / Story 1.8), (b) faer-sparse becomes relevant, (c) batch/parallel solves can exploit faer's rayon threading (Epic 4).
|
||
|
||
Parity (AC#3): reference cycles A/B/C converge identically within 1e-6 relative on both backends; full solver corpus green on both paths (38/38 test binaries, 0 FAILED).
|
||
|
||
Reproduce: `cargo bench -p entropyk-solver --bench lu_backends`
|