Skip to content

Batching vs speculation: Bar B's cost row is unwinnable as written #472

Description

@phall1

Derived result: Bar B's "non-negotiable" cost row is unwinnable with speculation and comfortably winnable with batching — and no invariant forbids batching.

Law 3: cost per landed PR is governed by PRs-per-validation, not by speculation efficiency. Speculation validates one atom per candidate; a batch validates g. This also means M4 (cache) and M5 (affected targets) cannot help — they reduce cost per validation, which applies to the baseline equally, so they cannot move a ratio.

A batch of unrelated atoms replayed as one linear chain is structurally identical to a stack-as-atom: one candidate, one tree, one validation, one CAS, one commit per PR preserved. Invariant 1 satisfied identically. Invariant 2 untouched. The design already implements this — it is the THUNDERDOME cohort — but confines it to an emergency regime and sizes it ~5x wrong (max_atoms: 100 vs n* ~ 1/p ~ 20 at p=5%; at 100 and p=5% it lands 0.59 atoms/run, worse than serial).

The stated reason for rejecting batching (README:25, on Mergify) is factually wrong against Mergify's own documentation — they speculate via max_parallel_checks and bisect on batch failure.

Actions

  • Name the invariant that forbids batching unrelated atoms in normal flow. If none exists, make batch size a first-class normal-flow scheduler dial alongside speculation width
  • Size it from measured p (n* ~ 1/p single-shot, ~1.4/p with split recovery), bounded by the attribution probe budget
  • Replace cohort.max_atoms: 100 with that derived quantity
  • Restate Bar B's cost row as Pareto dominance over GitHub's 2-D operating surface — at every latency GitHub achieves, we achieve it at no greater CI cost — recording group_size, build_concurrency, the only-merge-non-failing toggle, and the stack-depth mix

Contested, do not quote yet: four lenses computed the multiple as 5x, 3.0x, 1.43x and ~1.0x because they modelled four different GitHub merge queues. The ordering (batching cheaper per landed PR) is robust; the multiple is not. E3/E5 settle it.

See docs/INVESTIGATION.md §2 Law 3, §6 Q2, §7 R2, §10.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions