Skip to content

ci(ci): Add a candidate clock to the Strength workflow for time odds matches - #382

Draft
aywrite wants to merge 1 commit into
masterfrom
ci/candidate-clock
Draft

aywrite wants to merge 1 commit into
masterfrom
ci/candidate-clock

Conversation

@aywrite

@aywrite aywrite commented Oct 8, 2026

Copy link
Copy Markdown
Owner

Adds candidate_time_control to the Strength workflow. When it is set, the candidate plays that clock and the baseline plays time_control. When it is empty, the match is the symmetric one it was before.

This is for time odds matches, where the same build plays itself with one side given more time. The elo per doubling figure was last read that way at v0.4.3, using a per-side clock that never reached master.

The manifest records both clocks, and the summary line reads "X against Y", so a time odds run is not mistaken for an ordinary one.

This is a draft because play-shard is pinned to an unreleased mache commit (aywrite/mache#35). Once that change is released, the pin moves to the release and this can merge.

Checks: actionlint and pre-commit are clean on both workflow files.

🤖 Generated with Claude Code

https://claude.ai/code/session_013vnTSb5N6JEKfqkQHAgevq


Generated by Claude Code

…matches

A time odds match plays the same build on both sides with one given more
of the clock, so it prices the time rather than a change. The elo per
doubling that every speed price leans on was read that way at v0.4.3,
with a per side clock that never reached master. The Strength workflow
has one time_control, which reaches both engines.

candidate_time_control gives the candidate its own clock and leaves the
baseline on time_control. Empty, the match is the symmetric one it was.
The manifest records both clocks and the summary line names both, so a
time odds run cannot be read as an ordinary one.

play-shard is pinned to the mache commit that takes the new input. It
moves to that change's release before this merges.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013vnTSb5N6JEKfqkQHAgevq
@github-actions

github-actions Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

Speed against 621ecab0

Measured on AMD EPYC 9V45 96-Core Processor.
Both sides built with rustc 1.99.0 (b940084d7 2026-09-28).

Both sides built and run on this runner in this job, the way
scripts/speed.sh measures a perf commit. Each round runs
both sides on a layout of its own, the same compiled code with
its code and data shuffled and moved, so the 95% interval carries
where the code landed as well as the run. The verdict holds the
interval against a 1% threshold. The default layout, the one a
release ships, is measured after as a diagnostic. The node
counts are the search's: they move when the search does, and a
speed change leaves them alone.

round     base nps  candidate nps  change
    1      8198367        7779222   -5.1%
    2      8101545        7634775   -5.8%
    3      7521830        7822205   +4.0%
    4      7965824        7902434   -0.8%
    5      8055143        8118161   +0.8%
    6      7984600        8139407   +1.9%
    7      8193112        8207187   +0.2%
    8      7843524        7972642   +1.6%
    9      8133548        8204107   +0.9%
   10      7892209        8159596   +3.4%
   11      7888396        8030226   +1.8%
   12      8154974        8227436   +0.9%
   13      8117927        8110723   -0.1%
   14      8198731        8163439   -0.4%
   15      7946451        7866855   -1.0%
   16      8127240        8029588   -1.2%
   17      8191358        8035250   -1.9%
   18      8136909        8087427   -0.6%
   19      8162730        8033671   -1.6%
   20      8003465        7869861   -1.7%
   21      8120364        8159509   +0.5%
   22      8007210        8110059   +1.3%
   23      7865908        8085730   +2.8%
   24      8107898        8071228   -0.5%
   25      8290211        8295360   +0.1%
   26      8206357        8195820   -0.1%
   27      8145423        8158502   +0.2%
   28      7969759        7830394   -1.7%
   29      8208395        8108205   -1.2%
   30      8131633        7846742   -3.5%
   31      8076097        8188052   +1.4%
   32      7949801        8077534   +1.6%
   33      7356990        7281688   -1.0%
   34      7490396        7436024   -0.7%
   35      7939572        8230028   +3.7%
   36      8109016        8192924   +1.0%
   37      8255757        8237395   -0.2%
   38      7619243        7888582   +3.5%
   39      8007618        8141684   +1.7%
   40      7943964        8140892   +2.5%

             nodes    time  median nps  faster half
base       5355551  0.66 s     8088821      8164575
candidate  5355551  0.66 s     8097816      8174424
change                           +0.1%        +0.1%

paired change +0.2%, 95% interval -0.4% to +0.9%
diagnostic, on the default layout alone -0.1%, 95% interval -1.5% to +0.2%, 13 rounds

no change beyond ±1.0%: the whole interval is inside it

Speed: +0.2% (bench nps, 95% interval -0.4% to +0.9%, 40 interleaved rounds over shuffled layouts vs 621ecab0)

The instructions each side's bench executed, counted under
cachegrind. The count repeats to within a few hundred
instructions, so a small change here is a real one, but it
prices instructions only: cache misses, mispredicted branches
and where the code lands are the speed's to show.

instructions against 621ecab0, one cachegrind run a side, bench

            instructions    nodes  per node
base       8,049,005,695  5355551    1502.9
candidate  8,049,005,724  5355551    1502.9
change            +0.00%             +0.00%

within ±0.7%, as far as edits not made for speed have moved the count

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.

2 participants