docs(计划): 编译成本面收口 + 未核实项复核 + 按新读数重判 - #167
Merged
Merged
Conversation
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.
这是什么
docs/superpowers/plans/2026-09-23-compile-cost-and-recheck.md(834 行)——编译成本面收口 + 15 条未核实项复核 + 按新读数重判的施工计划。来源:维护者「反正目前来看方向是正确的评估一下工程可行性,例如编译速度等考虑,如果可行的话就写计划」。
它接在
docs/maintainer/proposals/comptime-feasibility.md(可行性评估,1043 行)之后:评估判「现在能做 = 0 项」,而 S0(成本面)是「前置中的前置」。三段结构
S0.0 协议 → S0.1 自证归因 → S0.2 动码 → S0.3 重测,明写禁止跳过 S0.1 直接改码第一等交付物是判据纪律,不是修法
§二 的 P1–P12 测量协议单独成节、排在 S0 之前。理由:计划自己复算出**「修前」读数是分布、且跨会话不可比**(同命令不同会话差 1.68×,先例 =
2026-09-17-spec-grammar.md:360的 25.6 s vs 评估的 15.24 s)——⇒ 没有稳定基线的 A/B 对拍不构成判据。
协议要点:
nice -n 19一律 · 逐采样 clean-cache · 交错采样A,B,A,B· N ≥ 5 · 每采样记loadavg· 报 min/median/max 全分布 · 比值优先于绝对值且分母必须是同会话同语料的check· 单调性闸ccr ≥ cir ≥ check(违反即整批作废,不得解释) · 阴性对照 · 禁止跨会话比绝对值 · 计时判据不进 CI 门。主结论
df_state_finalize()+ 三个「opt_level 0也照跑」的 pass ≈ 30.0 s = 阶段①的 72.7 %;节点 ×1.98 ⇒ 分析面 ×4.71(前端check只 ×2.11)。pa_in_unsafe/is_in_unsafe在逐节点循环内无条件调用 ⇒ 内层迭代 =2 × 169,418 × 7,638 = 2.588 × 10⁹,按 ~2–4 ns/迭代估 5–10 s ⇒ 与「分析面 ≈30 s」同阶但只占 1/3 上下 ⇒ 不许假设一招搞定。提交前的实核(team-lead,从
develop@origin取数,不读检出)tests/selfhost/test_*.py= 78 档jj file list -r develop@origin计数optimize_all零调用pa_in_unsafe(ni)无守卫逐节点调用ptr_analysis.cr:201is_in_unsafe(ni)同上region_check.cr:200已知的测量条件限制(写进计划,不是脚注)
撰写期
loadavg= 10.2–13.4(本机 4 核),比评估期(7–10)更差。追加实测(team-lead,提交后):
loadavg= 18.88,而本仓无任何构建/测试在跑。前几名是 6 个长期运行的会话进程(耗时 10 天 / 7 天 / 3 天)+ 桌面 shell,且kswapd0在跑(内存压力/交换) ⇒负载不是来自本仓的可停进程 ⇒ 计划里「争一个静默窗口(其它代理停跑)」这条补救可能不成立;S0 的负结果预案(退化为「结构性判据 + 同会话比值」)可能才是唯一可行路径,而不是备选。