Move the Rust toolchain pin from 1.97.1 to 1.98.0 (#120) - #215
Merged
Merged
Conversation
The pin was a holding action against a measured 15-30% slowdown under 1.98.0. The cause was never the compiler's codegen. Two byte-at-a-time loops in mailparse ran at half speed when the linker placed them across a 64-byte boundary on the runners' CPUs, and a new rustc moved them -- so did a version bump. Their x86-64 instruction streams were byte-identical under both compilers; only their addresses differed. With both loops replaced (vendor/mailparse, #213 and #214) the toolchain A/B on the CPU that showed the worst of it reads 1.98.0 within +/-0.5% of 1.97.1 on every parse path, and the same source under both compilers on an M4 is within 0.9%. So the pin moves. It stays a pin rather than floating to stable. The benchmark gate builds a revision and its base with the same toolchain, so a compiler change is the one regression it cannot see -- both sides move together. A pin makes the compiler a change like any other: proposed, measured with toolchain-ab.yml, reviewed. The toolchain file now describes that procedure instead of quoting a ~26% figure that turned out to be a measurement artifact and a 7.0x floor the gate no longer has. Every workflow that names the version follows, because components have to be installed for the toolchain cargo actually uses; the A/B workflow's baseline default follows the pin. Signed-off-by: kurok <22548029+kurok@users.noreply.github.com>
This was referenced Aug 27, 2026
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 #120.
Why the pin can move
The pin was a holding action against a measured 15–30% slowdown under rustc 1.98.0. The cause turned out not to be the compiler's codegen: two byte-at-a-time loops in mailparse ran at half speed when the linker placed them across a 64-byte boundary on the runners' Zen CPUs, and a new rustc — like a version bump, #204 — moved them. Their x86-64 instruction streams were byte-identical under both compilers (
find_from_u8_line_prefix: 88 = 88;decode_base64: 147 = 147).With both loops replaced (#213, #214), the toolchain A/B on the CPU that showed the worst of it — the EPYC 9V74, +96% this morning, +22% after #213 alone — now reads 1.98.0 within ±0.5% of 1.97.1 on every parse path (run 33092063031, noise floor 4.0%, worst +2.3% on a metadata batch). Locally on an M4, same source under both compilers: worst +0.9%.
Why it stays a pin rather than floating to
stableThe benchmark gate builds a revision and its base with the same toolchain, so a compiler change is the one regression it cannot see — both sides move together. A floating
stablewould put an unmeasured compiler into every published wheel. Keeping a pin makes the compiler a change like any other: proposed, measured withtoolchain-ab.yml, reviewed.rust-toolchain.tomlnow says this and describes the bump procedure; thetoolchain-ab.ymlbaseline default follows the pin.What changed
rust-toolchain.toml:1.97.1→1.98.0; comment rewritten (the old one quoted the ~26% figure Investigate the ~26% slowdown under rustc 1.98.0, then unpin the toolchain #120 later showed to be a measurement artifact, and a 7.0x floor the gate no longer has).test.yml(3 dtolnay inputs + maturin-action),publish.yml(4 maturin-action inputs):1.98.0, because components must be installed for the toolchain cargo actually uses (precedence note in the toolchain file).toolchain-ab.yml: baseline default and history comment.Verified locally under 1.98.0 before pushing:
cargo fmt --checkclean (blocking in CI), clippy unchanged from master, vendored crate's tests pass, 803 tests pass on a 1.98.0-built wheel.