Skip to content

docs: the bidiagonalisation parallel hint is not dropped (DROPPED experiment) - #11

Merged
shinaoka merged 2 commits into
mainfrom
perf/bidiag-par
Oct 14, 2026
Merged

shinaoka merged 2 commits into
mainfrom
perf/bidiag-par

Conversation

@shinaoka

Copy link
Copy Markdown
Member

Closes the lead left unverified in docs/worklogs/2026-10-14-compact-factor-region-floor.md:
that bidiag_in_place_scratch's _ = par; _ = params; and an unread
BidiagParams::par_threshold make the bidiagonalisation sequential however the
caller calls it. Only the scratch-size function ignores the hint, and correctly
(the workspace is shape-sized, not thread-sized). The worker bidiag_in_place
reads the threshold on every column and forwards par into the trailing update.

No code change. Measured, and the two candidates that lost with their numbers:

  • Removing the gate costs 2.50x (f64) / 1.77x (c64) on bidiag_in_place at
    128x128, 1.44x at 256x256, 1.08-1.12x at 512x512; end to end 1.81x
    (svd_values) / 1.52x (svd_thin) at 128x128.
  • Keeping the caller's hint for the two trailing upgrade_householder_factor
    calls that the latch starves moves no row by more than 6%.

Isolation: bidiag_in_place and linalg::svd::svd, f64/c64, 128/256/512 square
plus 1024x64 and 4096x256, CPUs 0-3 (the four free cores), RAYON_NUM_THREADS=8,
best of 7, interleaved A/B.

Record: docs/worklogs/2026-10-14-bidiag-parallel-hint.md. Ledger row
Bidiagonalisation parallel hint (DROPPED).

Gate: cargo test -p t4a-faer --lib — 203 passed, 0 failed, 2 ignored.
sparse::linalg::qr::tests::test_numeric_simplicial_qr_1_transpose passes here
(five reruns), so the failure recorded in the earlier worklog did not reproduce on
9de95f7.

…eriment

The lead the compact-factor region-floor record left unverified was that
`bidiag_in_place_scratch` discards its hint (`_ = par; _ = params;`) and that
`BidiagParams::par_threshold` is never read, so the bidiagonalisation is
sequential however the caller calls it. Only the scratch-size function ignores
the hint, and correctly -- the workspace is shape-sized, not thread-sized. The
worker, `bidiag_in_place`, reads the threshold on every column and forwards
`par` into the trailing update.

Isolation, `bidiag_in_place` at f64/c64, CPUs 0-3, best of 7, interleaved A/B:
the floor makes 128x128 fully sequential (Seq and rayon(8) both 0.319 ms f64),
threading 256x256 is 4.7% slower (2.223 -> 2.328), and only 512x512 pays. It is
load-bearing: removing the gate costs 2.50x (f64) / 1.77x (c64) at 128x128 and
1.44x at 256x256. Keeping the caller's hint for the two trailing
`upgrade_householder_factor` calls, which the latch starves, moves no row by
more than 6%.

No code change. The ledger row is DROPPED and the record carries the numbers that
dropped both candidates.
The same re-reading that closed the bidiagonalisation lead applies to `evd/tridiag.rs`:
the scratch function's ignored hint is workspace sizing, and `tridiag_in_place` reads
`params.par_threshold` and latches to `Par::Seq` below it, which at 128x128 closes the
whole factorisation. The flat `eigh` reading is this library's floor, not a missing
hint; whether the floor is set where it should be is a measurement, not a reading.
@shinaoka
shinaoka merged commit a76158c into main Oct 14, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant