docs: root README benchmark table from ONE run, both languages, n=3

原来那张表是**三次不同的跑拼起来的**(守卫只能硬编三个文件名),而且 n=1,
中英两份结构还不一样 —— 英文有 schedule 列,中文把它塞在脚注里。现在两份都由
`report.py --headline [--lang zh]` 从**同一份报告**生成:
`bench/results/standard-20260814-linux-x86_64/gcc-mcpp-2026.8.11.3.json`,25/25 ok,
所有大于 1s 的中位数 min/max 都在 ±4% 内。

## 数据本身换了个结论

新表有了 old-vs-new 列,于是最显眼的那个 200x **不再是「一直如此的默认行为」**:

    touch-hub     已发布 2026.8.11.3: 81.72s   本分支: 0.42s   cmake: 83.21s
    edit-comment  已发布 2026.8.11.3: 79.11s   本分支: 0.40s   cmake: 83.21s

也就是说级联抑制**以前并没有生效**,是这个分支让它真正工作的。旧文案写的是
「这是默认行为,不需要设任何键」,读起来像是它一直都在 —— 现在把话说准了。

`edit-body` 仍是对照组(1.1x 而不是 200x,级联是欠着的),`bmi_schedule` 明确写
「opt-in 且默认关闭」。

## 列序

`engine_order` 改成:被测默认 → 它自己的 opt-in 臂 → 已发布参照 → 其他引擎。
原来按字符串排,把参照插在了默认和 opt-in 中间,两个要对比的列永远隔着一列。

## 守卫

§5 重写:一份来源、两种语言、引擎名**从表头读**而不是在守卫里再列一遍
(加一条臂不会留下没被检查的列)。现在核 **50 个中位数**(5 行 × 5 引擎 × 2 语言),
原来是 20 个。另外 `-` 也被检查:标成「未测」的格子,数据里**必须真的没有** ——
否则 `-` 就成了藏数字的地方。

Author: speak-agent

README.md

@@ -307,42 +307,38 @@ import mcpplibs.cmdline;
 ## Benchmark
 
 Building **mcpp itself** — 137 module interface units, 57k lines, every one of
-them `import std;` — with three engines given the **same compiler binary**.
-Each cell is the median wall-clock and how many times faster it is than cmake.
-
-| scenario | what changed | **mcpp** `bmi_schedule=on` | mcpp default | cmake | xmake |
-|---|---|---|---|---|---|
-| `cold` | nothing built yet | **36.36s** · 2.5x | 79.54s · 1.2x | 92.33s · 1.0x | 90.30s · 1.0x |
-| `noop` | nothing at all | **0.16s** · 1.8x | 0.16s · 1.8x | 0.28s · 1.0x | 0.38s · 0.7x |
-| `touch-hub` | mtime on a widely-imported interface, content unchanged | 0.44s · 189.5x | **0.40s** · 207.9x | 83.39s · 1.0x | 82.08s · 1.0x |
-| `edit-body` | a real edit inside a function body | **30.48s** · 2.8x | 76.24s · 1.1x | 85.64s · 1.0x | 84.61s · 1.0x |
-| `edit-comment` | a comment added to a widely-imported interface | 0.44s · 188.5x | **0.38s** · 217.2x | 82.96s · 1.0x | 82.73s · 1.0x |
-
-<sub>Linux x86_64 · i9-13900K · gcc 16.1.0 · n=1 · pinned workload `a749e9f`.
-**Both mcpp columns are shown because either alone misleads**: the default is
-what you get today, `bmi_schedule = "on"` is one opt-in manifest key that helps
-only where a cascade is genuinely owed — on the two rows where mcpp already
-skips the cascade it costs a little rather than saving any.
-`bmi_schedule` remains opt-in: it is new, and a scheduling change that is wrong
-is wrong silently.
-The `bmi_schedule=on` column was re-measured on 2026-08-14 after a defect was
-found in it — the earlier `touch-hub 0.22s` / `edit-comment 0.18s` were
-measuring a build that had not finished, because the object edge was being
-cleaned by the very restat that suppresses the cascade and ninja exited while
-the compiler was still running. See [`bench/README.md`](bench/README.md) §8b.</sub>
-
-* **`touch-hub` and `edit-comment` are where the day goes.** cmake and xmake
-  decide by timestamp and rebuild everything downstream; mcpp compares the BMI
-  the compiler just produced against the previous one, and when the interface
-  did not change it skips the cascade entirely. This is the DEFAULT behaviour —
-  no key to set — and it is why those two rows read 200x.
+them `import std;` — with four engines handed the **same compiler binary**.
+Each cell is the median of **3 samples** and how many times faster it is than
+cmake. Every column comes from **one run**, [`bench/results/standard-20260814-linux-x86_64/gcc-mcpp-2026.8.11.3.json`](bench/results/standard-20260814-linux-x86_64/gcc-mcpp-2026.8.11.3.json).
+
+| scenario | what changed | `mcpp@2026.8.13.1` | `mcpp@2026.8.13.1+schedule=on` | `mcpp@2026.8.11.3` | `cmake` | `xmake` |
+|---|---|---|---|---|---|---|
+| `cold` | nothing built yet | 86.69s · 1.1x | **35.73s · 2.6x** | 86.75s · 1.1x | 91.74s · 1.0x | 90.54s · 1.0x |
+| `noop` | nothing at all | **0.16s · 2.0x** | 0.18s · 1.8x | 0.24s · 1.3x | 0.32s · 1.0x | 0.38s · 0.8x |
+| `touch-hub` | mtime on a widely-imported interface, content unchanged | **0.42s · 197.7x** | 0.42s · 197.2x | 81.72s · 1.0x | 83.21s · 1.0x | 82.48s · 1.0x |
+| `edit-body` | a real edit inside a function body | 80.87s · 1.1x | **29.83s · 2.9x** | 81.19s · 1.1x | 85.30s · 1.0x | 84.33s · 1.0x |
+| `edit-comment` | a comment added to a widely-imported interface | **0.40s · 207.0x** | **0.40s · 207.0x** | 79.11s · 1.1x | 83.21s · 1.0x | 82.15s · 1.0x |
+
+<sub>Linux x86_64 · i9-13900K · gcc 16.1.0 · n=3 · pinned workload `a749e9f` ·
+cmake 4.4.2 / xmake 3.1.0. `-` would mean not measured; there is none here.
+Min/max sit within 4% of every median above 1s.</sub>
+
+* **`touch-hub` and `edit-comment` are where the day goes — and that is new.**
+  cmake and xmake decide by timestamp and rebuild everything downstream. mcpp
+  compares the BMI the compiler just produced against the previous one and, when
+  the interface did not change, skips the cascade. The released **2026.8.11.3
+  column shows this was not working before**: 81.72s, level with cmake. It is
+  0.42s here. Default behaviour, no key to set.
 * **`edit-body` is the control.** There the interface really did change, so the
-  cascade is owed — mcpp is 1.1x rather than 200x, and an engine that were
-  faster would have skipped work it owed. `bmi_schedule=on` does not skip it
-  either; it does the same owed work 2.5x faster.
-* **Cold builds** come down to one 26-deep chain of module interfaces. `mcpp`
-  publishes each BMI as soon as it exists and moves code generation off the
-  critical path; without that setting it is 79.5s, i.e. level with the others.
+  cascade is owed — mcpp is 1.1x, not 200x. An engine that were faster on this
+  row would be skipping work it owed. `bmi_schedule=on` does not skip it either;
+  it does the same owed work 2.9x faster.
+* **`bmi_schedule` is opt-in and OFF by default** (`auto` resolves to off). It
+  moves code generation off the critical path, which is why it only helps where
+  a cascade is genuinely owed: `cold` 86.69s → 35.73s and `edit-body` 80.87s →
+  29.83s, while on the two rows mcpp already skips the cascade it buys nothing.
+  A scheduling change that is wrong is wrong *silently*, so it does not become
+  the default on the strength of one machine.
 
 📊 **[Methodology, pinned versions, and the full data →
 `bench/README.md`](bench/README.md)** · [简体中文](bench/README.zh-CN.md)

README.zh-CN.md

@@ -302,37 +302,37 @@ import mcpplibs.cmdline;
 
 ## 性能对比
 
-用**同一个编译器二进制**、三个构建引擎构建 **mcpp 自己** —— 137 个模块接口单元、
-57k 行,每一个都 `import std;`。中位墙钟时间,越低越好。
-
-| 场景 | 改了什么 | **mcpp** | cmake | xmake |
-|---|---|---|---|---|
-| `cold` | 什么都还没构建 | **79.54s** · 1.2x | 92.33s · 1.0x | 90.30s · 1.0x |
-| `noop` | 什么都没改 | **0.16s** · 1.8x | 0.28s · 1.0x | 0.38s · 0.7x |
-| `touch-hub` | 给被大量 import 的接口改 mtime | **0.40s** · 208x | 83.39s · 1.0x | 82.08s · 1.0x |
-| `edit-body` | 函数体内部一处真实修改 | **76.24s** · 1.1x | 85.64s · 1.0x | 84.61s · 1.0x |
-| `edit-comment` | 给被大量 import 的接口加一条注释 | **0.38s** · 218x | 82.96s · 1.0x | 82.73s · 1.0x |
-
-* **冷构建三家都在 15% 以内** —— 依赖图是一条 26 层深的模块接口链,没有可供调度
-  的余地,任何引擎都缩短不了一条链。
-* **`touch-hub` 才是一天里真正花掉的时间。** cmake 和 xmake 按时间戳判断,下游
-  全量重建;mcpp 把编译器刚产出的 BMI 和上一份比对,接口没变就不级联 ——
-  **0.40s 对 83s**。
-* **`edit-body` 是对照组。** 那里接口确实变了,任何引擎都不该快,也确实都不快。
-
-📊 **[测量方法、钉住的版本与完整数据 → `bench/README.zh-CN.md`](bench/README.zh-CN.md)**
- · [English](bench/README.md)
-
-<sub>mcpp 为**默认配置**。Linux x86_64 · i9-13900K · gcc 16.1.0 · n=1 ·
-钉住的工作负载 `a749e9f`。opt-in 的 `[build] bmi_schedule = "on"` 能把 `cold`
-降到 36.4s、`edit-body` 降到 30.5s,但它**只在级联确实欠着的时候有用**:上表
-`touch-hub` / `edit-comment` 两行 mcpp 本来就跳过了级联,开了它反而略慢
-(0.44s 对 0.40s / 0.38s)。该键仍为 opt-in。
-它此前有一个增量正确性缺陷,已于 2026-08-14 修复;修复也推翻了那一列原先的
-`touch-hub 0.22s` / `edit-comment 0.18s` —— 那两个数量的是**没跑完的构建**。
-经过与修正后的数据见 `bench/README.zh-CN.md` §8b。
-套件还测量了第二个独立工程(xlings)的两种代码风格;那份对比、已声明的不对称、
-以及「什么时候一个格子**不能**拿来比较」的规则,都在 `bench/README.md`。</sub>
+用**四个构建引擎**编译 **mcpp 自己** —— 137 个模块接口单元、57k 行、每一个都
+`import std;` —— 并且**给它们同一个编译器二进制**。每格是 **3 轮的中位数**,以及
+相对 cmake 的倍率。所有列出自**同一次跑**,数据在
+[`bench/results/standard-20260814-linux-x86_64/gcc-mcpp-2026.8.11.3.json`](bench/results/standard-20260814-linux-x86_64/gcc-mcpp-2026.8.11.3.json)。
+
+| 场景 | 改了什么 | `mcpp@2026.8.13.1` | `mcpp@2026.8.13.1+schedule=on` | `mcpp@2026.8.11.3` | `cmake` | `xmake` |
+|---|---|---|---|---|---|---|
+| `cold` | 还没编过 | 86.69s · 1.1x | **35.73s · 2.6x** | 86.75s · 1.1x | 91.74s · 1.0x | 90.54s · 1.0x |
+| `noop` | 什么都没改 | **0.16s · 2.0x** | 0.18s · 1.8x | 0.24s · 1.3x | 0.32s · 1.0x | 0.38s · 0.8x |
+| `touch-hub` | 碰一下被大量导入的接口的 mtime,内容不变 | **0.42s · 197.7x** | 0.42s · 197.2x | 81.72s · 1.0x | 83.21s · 1.0x | 82.48s · 1.0x |
+| `edit-body` | 真的改了一个函数体 | 80.87s · 1.1x | **29.83s · 2.9x** | 81.19s · 1.1x | 85.30s · 1.0x | 84.33s · 1.0x |
+| `edit-comment` | 在被大量导入的接口里加一行注释 | **0.40s · 207.0x** | **0.40s · 207.0x** | 79.11s · 1.1x | 83.21s · 1.0x | 82.15s · 1.0x |
+
+<sub>Linux x86_64 · i9-13900K · gcc 16.1.0 · n=3 · 钉住的工作负载 `a749e9f` ·
+cmake 4.4.2 / xmake 3.1.0。`-` 表示未测,本表没有。所有大于 1s 的中位数,
+min/max 都在 ±4% 以内。</sub>
+
+* **`touch-hub` 与 `edit-comment` 是一天时间的去处 —— 而且这是新的。**
+  cmake 和 xmake 按时间戳判断,把下游全部重编;mcpp 拿编译器刚产出的 BMI 与上一份
+  比较,接口没变就**不级联**。已发布的 **2026.8.11.3 那一列说明它以前并没有生效**:
+  81.72s,和 cmake 一个量级;这里是 0.42s。这是**默认行为**,不需要设任何键。
+* **`edit-body` 是对照组。** 那里接口是真的变了,级联是**欠着的** —— mcpp 是 1.1x
+  而不是 200x。在这一行更快的引擎,是漏掉了它该做的活。`bmi_schedule=on` 也不跳过它,
+  只是把同样欠着的活做快了 2.9 倍。
+* **`bmi_schedule` 是 opt-in,默认关闭**(`auto` 解析为 off)。它把代码生成移出关键
+  路径,所以只在级联**确实欠着**时有用:`cold` 86.69s → 35.73s、`edit-body`
+  80.87s → 29.83s;而在 mcpp 本来就跳过级联的那两行,它买不到任何东西。
+  调度改错是**无声**的,所以不靠一台机器的数据就变成默认值。
+
+📊 **[方法、钉住的版本、完整数据 → `bench/README.zh-CN.md`](bench/README.zh-CN.md)** ·
+[English](bench/README.md)
 
 ## 平台支持
 

bench/tools/report.py

@@ -184,11 +184,27 @@ def render(cells, baseline):
 
 
 def engine_order(engines):
-    """mcpp arms first (opt-in, then default, then the released reference)."""
+    """mcpp arms first, newest version first, each default before its opt-in arm.
+
+    Reading order matters more than it looks: the build under test and its
+    `+schedule=on` arm answer one question ("what does the key buy?") and the
+    released reference answers a different one ("did this get faster?"). Sorting
+    the raw strings interleaved them — reference, opt-in, default — so neither
+    pair sat together and every comparison was two columns apart.
+    """
+    def version_key(e):
+        head = e.split("+", 1)[0]
+        ver = head.split("@", 1)[1] if "@" in head else ""
+        parts = []
+        for piece in ver.split("."):
+            parts.append(int(piece) if piece.isdigit() else 0)
+        return parts + [0] * (4 - len(parts))
+
     def key(e):
         if not e.startswith("mcpp@"):
-            return (2, e)
-        return (0 if "+" in e else 1, e)
+            return (1, [], 0, e)          # other engines after every mcpp arm
+        # negated version → newest first; base arm before its own option arm
+        return (0, [-p for p in version_key(e)], 1 if "+" in e else 0, e)
     return sorted(engines, key=key)