Repository navigation
docs(worklog): the EVD and SVD factorisation floors are where they belong (DROPPED) - #15
Merged
Merged
Conversation
…long Forcing the tridiag and bidiag latches open costs 1.5-4x at 96x96 to 256x256, and a fully sequential call is within 1% of the shipped floor at every one of those shapes -- the flat eigh and svd_values rows at 128x128 are this library's own floor doing its job, not a dropped hint. Lowering the floor buys nothing at any shape swept; at 512 and 1024 the shipped floor is the best of the swept values and a fully sequential call is 1.5-1.7x worse. A floor above the first column's area wins 5.6% on 256x256 bidiagonalisation and is noise at five other shapes, so it is recorded as an untaken lead rather than moved. No code change. DROPPED, with the numbers that dropped it: docs/worklogs/2026-10-14-evd-svd-floor-sweep.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No code change. This settles the question
2026-10-14-bidiag-parallel-hint.mdleftopen: whether the
192 * 256latch intridiag_in_placeandbidiag_in_placeclosestoo early, which at
128 x 128closes the whole factorisation and makeseighandsvd_valuesflat from 1T to 8T.Forcing the gate open is 1.5-4x worse at every shape measured, and a fully sequential
call is within 1% of the shipped floor at every one of them — the flat rows are this
library's own floor doing its job.
f64, best of 10 calls, smallest over 6interleaved repetitions, four threads, CPUs 0-3, gate-open / shipped / fully-sequential:
At
512/1024the shipped floor is the best swept value and a fully sequential callis 1.5-1.7x worse, so the window it leaves open pays there. Lower floors
(
8192/16384/32768) buy nothing at any shape. Repeating128/256with eightworkers on the same four cores changes the shipped column by under 1%.
One untaken lead is recorded: a floor above the first column's area (
65536) wins 5.6%on
256 x 256bidiagonalisation and is within 0.5% at five other shapes, which is not aconstant this sweep pins.
Record:
docs/worklogs/2026-10-14-evd-svd-floor-sweep.md. Ledger row DROPPED.Limits: four physical cores, so the eight-core crossover is not measured.