PysolateExplained
打开文档导航
本科生解释查看 Markdown 源文件

如何阅读 Pysolate 的证据

一句话

先确认一条陈述属于源码合同、真实运行观察、历史 artifact、解释框架还是未实现方向，再检查 producer target、原始样本和复现级别；“文件在当前仓库里”不等于“当前 HEAD 产生了里面的数字”。

先看一个例子

仓库中有一份 JSON 报告写着某个 fixture 加速约 1.9 倍。它还带有 source commit、artifact digest 和几行 timing。

这至少可能表示四件不同的事：

  1. 当前代码仍有读取这份报告的 validator；
  2. 旧版本 runtime 曾在一个固定 fixture 上观察到这些 timing；
  3. 当前 checkout 可以从报告 rows 重算 median；
  4. 当前 checkout 能重新构建 Guest、运行同一实验并得到新 raw rows。

前 3 项都不自动推出第 4 项，更不推出生产 workload 也会加速 1.9 倍。

真实机制

Pysolate Explained 使用这些状态词：

  • Current：命名 target 中能从源码、contract 或 test 验证的机制。它不表示默认启用或生产就绪。
  • Observed：命名平台、fixture、artifact 和样本中真实记录过的结果。结论只覆盖该 denominator。
  • Historical：结果由较早 commit、Guest 或 harness 产生；即使 JSON 后来被提交到当前 tree，也不能把当前 HEAD 写成 producer。
  • Framing：由有限实现和证据支持的研究解释，例如“安全调度机会”；不是新运行观察。
  • Deferred：明确尚未实现、尚未运行或因 gate 未进入的方向。
  • Unsupported：当前证据不能支持的推论。

复现强度也分四级：

级别当前能做什么不能冒充什么
A重跑当前 tree 的 unit/contract/结构 gatereal Guest campaign 或性能复现
B加入固定 Guest、artifact、toolchain 后跑 current E2E/producer历史 artifact 的同一 producer
C从历史 raw 或 checked-in canonical rows 重算当前 target 重新运行了旧实验
D用 component 字段和公式得到 schedule modelobserved interval trace

例如，go test ./runtime/semantic ... 通过可以证明当前 negative-control invariant 没坏，但不证明远端 provider timing。Real-Guest E2E 能证明一个固定 artifact 上的执行路径，不证明 arbitrary Python。Canonical JSON 有完整 rows 时可重算 median；只有 summary digest 而没有 raw JSONL 时，不能重放 trial。

Digest 的证据范围也要收窄。SHA-256 能证明手中的 canonical bytes 是否相等；它不证明 bytes 的语义正确、作者可信、远端 effect 最终发生，或对应私有 raw 文件仍然存在。

当前更新提供了两个适合练习这套读法的例子。Prepared Family 有 Current contract/tests 和 checked-in deterministic fixture declaration，Runtime 文档还记录 exact Linux artifact-backed acceptance passed；但公开 tree 没有完整 Host-test run report，因此不能补写性能或独立 raw replay。两个 scalar source pass 有 exact-Guest correctness JSON 与 raw timing rows，可以重算 median；它们的 treatment 分别慢 14.61% 和 4.49%，所以证据支持 pass extensibility/correctness，明确不支持 speedup。

读 benchmark 数字前的检查清单

  1. Claim 指向哪个 exact mechanism，状态是 Current 还是 Observed？
  2. Runtime target、producer commit、Guest artifact、harness 和 checker 是否分别记录？
  3. Workload、平台、样本量、对照和 denominator 是什么？
  4. Raw rows 是否在场，还是只有 digest/aggregate？
  5. Timing 是真实 start/end interval，还是 component + 公式的 projection？
  6. Negative control 是否保留 branch、exception、mismatch、cancel 和 replay？
  7. Result/effect/workspace parity 与 logical/physical count 是否分开？
  8. 文档明确禁止了哪些外推？

为什么重要

技术上： 这套分层防止旧 benchmark、当前实现和论文 framing 相互“借证据”。修复代码不会自动重跑历史 campaign，测试通过也不会补出缺失 raw trace。

产品和业务上： 决策者可以区分“机制可验证”“固定场景观察到收益”和“尚无生产经济证据”。这避免根据漂亮但不可复现的数字提前承诺成本或延迟。

不能推出什么

  • Host receipt/evidence 不是 external-world oracle，尤其在 timeout/ambiguous 情况下。
  • Non-empty artifact/source digest 不等于 artifact bundle、raw log 和 producer 仍可用。
  • 单个 real-Guest fixture 不证明安全、兼容性或性能覆盖任意 Python。
  • No-go/negative result 不能被删掉，也不能泛化成所有未来 workload 都无机会。

术语卡

  • Producer target：真正生成一份 artifact 或数字的源码与 harness 版本。
  • Target-bound：producer、Guest、harness、checker 和 artifact 与审查 target 完整绑定。
  • Canonical recompute：从已提交结构化 rows 重新计算摘要。
  • Raw replay：使用原始样本、artifact 和环境重新执行或重建实验。
  • Denominator：结论实际覆盖的样本全集。

继续阅读