Skip to content

Move the Rust toolchain pin from 1.97.1 to 1.98.0 (#120) - #215

Merged
kurok merged 1 commit into
masterfrom
unpin-rustc-1.98
Aug 27, 2026
Merged

kurok merged 1 commit into
masterfrom
unpin-rustc-1.98

Conversation

@kurok

@kurok kurok commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

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 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 floating stable would put an unmeasured compiler into every published wheel. Keeping a pin makes the compiler a change like any other: proposed, measured with toolchain-ab.yml, reviewed. rust-toolchain.toml now says this and describes the bump procedure; the toolchain-ab.yml baseline 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.
  • CONTRIBUTING prerequisites + Performance intro; CHANGELOG.

Verified locally under 1.98.0 before pushing: cargo fmt --check clean (blocking in CI), clippy unchanged from master, vendored crate's tests pass, 803 tests pass on a 1.98.0-built wheel.

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>
@kurok
kurok merged commit f3f843b into master Aug 27, 2026
15 checks passed
@kurok
kurok deleted the unpin-rustc-1.98 branch August 27, 2026 16:25
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.

Investigate the ~26% slowdown under rustc 1.98.0, then unpin the toolchain

1 participant