Rust CGU 分片陷阱与 Tokio 协作预算

本期检索说明

先读取 content/collections/deep-radar 截至 2026-09-12 的全部原文链接，并按 URL、标题与问题语义去重。最近 24 小时内，rustc 的泛型 CGU 分片实验同时给出了局部 benchmark、官方 rustc-perf 反证、完整源码差异与失败测试；Tokio 的 copy_buf 修复则用 60 秒未完成的确定性饥饿复现、对照实现和回归测试闭合了协作调度问题。两项都处于尚未合入状态，本文讨论的是实验和工程方法，不把它们写成已经发布的能力。

Java/JVM、Kotlin、Zig 与 Linux 的新候选没有同时满足“实测数据、源码或汇编证据、原理剖析”三项标准。OpenJDK 的 RISC-V Ztso fence 消除和 Linux RSEQ operations 都有扎实的 ABI/源码论证，但没有随补丁公开 benchmark；因此不以推测补位。本期只收录 2 篇。

01 · rustc：局部增量构建变快，不代表 CGU 分片策略全局成立

原文与日期： Trigodil，2026-09-13 00:05（中原标准时间）；rust-lang/rust PR #162692，交叉验证为该提交的官方 rustc-perf 对比。截稿时 PR 仍是 Draft，并带有 perf-regression 与等待作者处理标签。

为什么值得读： 这是一个比“优化成功”更有价值的完整实验：作者准确找到了泛型单态化的过度失效域，用有界 hash shard 在 polars-core 上取得正向结果；随后 rustc 的全量基准揭示它对大量真实 crate 的编译指令、内存和二进制大小造成严重回退。局部 workload、实现细节与全局反证同时公开，正适合研究编译器缓存粒度和 benchmark 外推边界。

核心技术结论： 现有 partitioner 将同一模块中泛型函数的所有单态化实例放进以 (module_def_id, volatile) 命名的单个 volatile CGU。只要某个实例对应的函数体改变，整桶都会在下一次增量构建中重新 codegen，即使其他实例没有经过这条代码路径。

实验增加 -Z fine-grained-generic-cgus：以每个实例完整 mangled symbol 的 hash 把 volatile 桶拆成有限 shard，使一次编辑理论上只拖入约 1 / shard_count 的无关实例。shard 数从 -C codegen-units 推导，以主机并行度为下限，并夹在 4–128。关键约束是不能无限拆成“一实例一 CGU”：增量模式有意跳过 merge_codegen_units，数百个微小 object 会把成本从 codegen 转移到链接器。

现行： module.volatile
       ├─ generic::<u32>
       ├─ generic::<u64>
       └─ generic::<&str>
       任一代码路径改变 → 整桶重编

实验： module.volatile.shard000 ... shard127
       symbol_hash(instance) → 有界 shard
       降低误失效，但增加 object、链接与优化边界成本

最有价值的实验、源码与 benchmark 细节： polars-core 的 ChunkedArray<T> 能制造高单态化量。以 baseline 为 1.000x，无限拆分让 cold build 变成约 3.06x、增量构建变成约 20.95x；有界 hash shard 则为 cold 0.988x、增量 0.961x。叠加 -Z threads=4 后是 0.657x / 0.852x；Cranelift、16 CGU 与 4 threads 的增量结果最好，为 0.521x。作者还说明必须改函数体：尾部注释不会触发，因为 rustc fingerprint 依据 item 内容而非文件字节。按调用拓扑聚类也做过实验，但由于可聚类 callee 太少，输给 hash。

真正决定结论的是官方 try-perf。临时实验版本将分片强制应用于 volatile CGU 后，104 个 primary 样本中 100 个发生指令回退，回退均值 +70.7%、范围 +0.1% 到 +1726.1%；计入 4 个改善样本后，全体 primary 仍为 +68.0%。Max RSS 的 primary 总体为 +2.4%，binary size 总体为 +32.7%；bootstrap 反而从 497.802 s 降到 494.017 s（-0.76%），说明单看 bootstrap 也会误判。首次 CI 还因预期 CGU 名为 .volatile、实际变成 .volatile.shardNNN 而失败，修正实验后 try build 通过，但性能标签保留。

这组结果不能简单归因为“想法无效”：Polars 局部数据证明降低失效域确有收益，官方矩阵则证明 shard 数、启用范围、链接成本与跨 CGU 优化的控制还没有收敛。工程上应把 CGU count/object count、链接时间、codegen 指令、RSS 和最终 binary size 作为共同目标，而不是只优化一次 body edit 的墙钟时间。

适合的工程师背景： 熟悉 rustc monomorphization、增量查询、LLVM/Cranelift codegen，或在大型泛型 Rust 项目里排查 rebuild 与链接瓶颈的编译器工程师。

预计阅读收益： 约 70–100 分钟；可得到一套验证缓存分片的完整框架：局部命中率、碎片化上限、全量 workload、资源指标与负向结果必须一起看，并能识别“单样本改善、全局灾难”的 benchmark 外推风险。

02 · Tokio：始终 Ready 的 I/O 也必须消耗协作预算

原文与日期： Dev-next-gen，2026-09-13 07:44（中原标准时间）；tokio-rs/tokio PR #8459。源码交叉验证可直接查看 2 个文件、57 行新增与 2 行删除。截稿时仅 1 个提交，尚无 reviewer，不应视为 Tokio 已发布行为。

为什么值得读： 异步 I/O 通常通过 Pending 把控制权还给 executor，但内存 reader/writer 可以一直 Ready。copy_buf 内部若持续 poll_fill_buf → poll_write，业务代码每次又立刻创建下一次复制，就能绕过 Tokio 的 task budget，让同一 worker 上的其他 future 永远没有机会运行。这是“API 是 async，所以自然公平”的典型反例，且修复能迁移到任何手写 Future 的内部循环。

核心技术结论： io::copy 自 2024 年的修复起已在 CopyBuffer::poll_copy 调用 coop::poll_proceed(cx)，但 copy_buf 的独立实现没有同步这一约束。补丁在一次 poll 开头领取一个 coop token；reader 返回数据或错误时调用 made_progress()，预算耗尽则由 runtime 返回 Pending 并安排再次唤醒。它不是每复制一个字节收费，也不是在每次 writer write 后收费，而是按外层 poll 记一次进展，从而与现有 copy 的语义保持一致。

let coop = ready!(crate::task::coop::poll_proceed(cx));

match Pin::new(&mut *reader).poll_fill_buf(cx) {
    Poll::Ready(Ok(buffer)) => {
        coop.made_progress();
        // 继续写入；预算用尽时下一次 poll 让出执行权
    }
    Poll::Ready(Err(err)) => {
        coop.made_progress();
        return Poll::Ready(Err(err));
    }
    Poll::Pending => { /* 保留现有 flush/deadlock 处理 */ }
}

最有价值的实验、源码与 benchmark 细节： 回归测试在一个 biased tokio::select! 中让第一分支无限执行 copy_buf(&mut &[u8], &mut Vec<u8>)，第二分支只调用 yield_now()。reader 和 writer 都永远 Ready，因此旧实现不会自然触发 Pending。作者把现有 copy_is_cooperative 测试替换为 copy_buf 后，当前 master 运行 60 秒仍不结束，只能手动杀掉；相同二进制中的 copy 对照立即通过。补丁新增的 copy_buf_is_cooperative 也立即通过。

源码变更同时覆盖只启用 io-util 的 feature 组合，保持无 runtime feature 时可编译；作者运行了完整 io_* 测试、--no-default-features --features io-util check、fmt 与 clippy，均通过。这里的实测是确定性的 liveness/fairness 结果，不是吞吐 benchmark；PR 尚未给出 coop 检查对大块内存复制吞吐的成本，所以本文只确认“饥饿被消除”，不宣称性能无损。

适合的工程师背景： 编写 Tokio 自定义 Future、代理/存储复制路径，或正在定位单 worker runtime 中任务饥饿、尾延迟尖峰的 Rust 异步工程师。

预计阅读收益： 约 35–55 分钟；能学会审查 Future 内部循环是否存在永远 Ready 的路径，区分进展、唤醒与公平性，并用一个必然可复现的对照测试证明 scheduler 重新获得控制权。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-08-15 至 2026-09-13，单位人民币。六类硬件继续固定同一 SKU。9 月 13 日实际打开 GPU 固定样本页，页面仍显示亚马逊中国最低 ¥4,464.34，因此新增一个当日采集点；CPU、主板、DRAM、HDD、SSD 的既有入口未能同时返回同型号、同渠道、可当日核验的报价，不新增点，也不把旧值复制成今日行情。折线只连接 JSON 中真实采样日，其他类别的空白尾段表示证据缺失而不是横盘。

价格来源： 9800X3D、MSI RTX 5070 VENTUS 3X、ASUS TUF B850M-PLUS WIFI7、Kingston FURY DDR5-6000 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。GPU 供给判断继续参考 2026-07-27 的中国区 RTX 50 系列渠道调价记录。

判断依据

CPU 和主板的最后有效点已经形成台阶下降，但新鲜度分别停在 9 月 9 日与 9 月 8 日，适合作为目标价而非今日成交承诺。GPU 获得新的同价采样，能确认固定样本仍未下行；HDD 与 DRAM 没有新的趋势证据。SSD 的聚合最低价与历史及其他渠道差异过大，不能把它外推为全市场跌幅。当前建议主要基于可观测价格轨迹与已记录的渠道变化，不对不可见库存和未来产能作猜测。

其它你可能关心的

• OpenJDK RISC-V：Ztso 下消除 C++ atomic 包装层的冗余 fence
• Linux：为 TCMalloc 迁移到 RSEQ v2 提议每线程 operations 列表
• LWN：TCMalloc 回归、RSEQ operations 与用户态 ABI 边界

本期结论

两篇材料共同提醒：低层优化最危险的地方不是“没有效果”，而是只在局部模型里成立。CGU 分片降低了误失效，却把成本搬到 object 数量、链接和跨单元优化；copy_buf 完成了每次复制，却绕过 executor 的公平性。可迁移的做法是把系统级反证纳入验收：编译器优化必须跑全量 workload 和资源指标，异步循环必须在始终 Ready 的输入上证明仍会交还调度权。