Repository navigation
docs(bench): stop advertising RAYON_NUM_THREADS as thread pinning (#351) - #352
Merged
Merged
Conversation
The workspace has no Rayon dependency (#349, #350), but two current sites still presented RAYON_NUM_THREADS as the thread control: - docs/design/runtime-simd-dispatch.md: the baseline-vs-native command set RAYON_NUM_THREADS=1 for the kernel bench, which runs every measured call on Exec::serial() and prints context=serial, and the prose called the runs 'pinned threads'. The variable is removed, the campaign wording now names the controls that exist (boost/frequency scaling off, one run at a time, quiet cores), and the section states that neither harness reads an ambient thread variable: the fused harness builds its own Pool at the widths 1 and 4 and asserts the budget. - strided-fused/benches/fused_chunked_replay.rs: the module comment ran the bench with RAYON_NUM_THREADS=8 although thread_counts() is fixed at [1, 4]. The command drops the variable and the comment says the harness owns the width. Dated worklogs and plans keep their historical commands.
Repository rules reviewRepository rules review (801887a77e94ded3a2cea46ce28d82b53d047da3...fbd9c12bbb537270a6b390109ebb3e626bcce0d4) Verdict: pass Findings: - [warn] llm-skipped (External LLM Review) <unknown>: External LLM review was skipped External LLM review is permanently disabled; deterministic checks only. |
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.
Closes #351.
#350 fixed the sites #349 enumerated, but it did not touch the design note that
AGENTS.mdlinks as the current SIMD reference, or the fused bench module comment. Both still told a maintainer thatRAYON_NUM_THREADSpins the run, which it does not: the workspace has no Rayon dependency.What changed (2 files, prose and comments only)
docs/design/runtime-simd-dispatch.md: the baseline-vs-native command no longer setsRAYON_NUM_THREADS=1forerased_uninit_elementwise. The prose no longer says "pinned threads"; it names the controls that exist (boost and frequency scaling off, one run at a time, quiet measured cores). A new paragraph records why no pin is needed: the kernel harness runs every measured call onExec::serial()and printscontext=serialin itsCONFIGline, and the fused harness builds its ownPoolat the fixed widths 1 and 4 and asserts the effective budget on each row. With no Rayon dependency the variable would select nothing even if it were set.strided-fused/benches/fused_chunked_replay.rs: the module comment ranRAYON_NUM_THREADS=8 cargo bench ...althoughthread_counts()is fixed at[1, 4]. The command drops the variable and the comment states that the harness owns the width and there is nothing to pin from the shell.No Rust code, no API, no measurement.
Not fixed here
the
docs/permutation-optimization.mdsection on the source-order copy still describes acopy_strided_src_order_parvariant that falls back whenRAYON_NUM_THREADS=1; the function no longer exists, and the rootCargo.tomlstill declaresrayon = "1.10". Both belong to the open cleanup issue #339, not to this site, so they are left untouched and reported.Dated
docs/worklogs/anddocs/plans/keep their historical commands.Checks
cargo fmt --all -- --checkpython3 scripts/repository-rules-review.py --base origin/main --worktree --dry-run(pass, no findings)