rustc 元数据稀疏编码与类型子句内联边界

本期检索说明

先读取 content/collections/deep-radar 截至 2026-10-17 的全部原文链接，并按 URL、标题与实现机制去重。最近 24 小时内，Rust 编译器出现两项同时具备源码 diff、可复核实测与原理证据的新工作：一项为 .rmeta 表在 dense/sparse 两种布局之间按成本自适应选择，另一项以 #[inline(always)] 消除 Binder::map_bound 热路径的函数边界。两者均未在既往报告出现。

Java/JVM 当天的 C2 unloaded-signature 修复有完整源码与测试矩阵，但没有公开性能实测；Kotlin、Zig 与 Linux 也没有新的材料同时满足“实测 + 源码/汇编 + 原理”三项标准。因此本期只收录 2 篇 Rust 一手材料，并把元数据方案的全局指令回退、artifact 增长，以及内联方案的 cycles 回退一并保留。

01 · rustc 元数据表：64 项 bitmap、popcount 与自适应成本判定

原文与日期： TaKO8Ki，2026-10-18 02:30（中原标准时间）；Rust PR #164484、原始提交与完整 diff 和 rustc-perf 对比。

为什么值得读： 这项工作没有假设稀疏格式永远更小，而是在序列化时计算索引开销、非默认值数量与 dense 大小，只有真实字节成本更低才切换格式。它还展示了一个典型编译器权衡：输出元数据与峰值内存显著缩小，却因为额外扫描、bitmap 解码和分支让最可靠的全局指令指标回退。与只报压缩率的文章相比，这组正负数据更适合工程决策。

核心技术结论： 表被分成每块 64 项。稀疏索引为每块保存 8 字节 bitmap 与 4 字节 base，共 12 字节；只有 index_bytes + non_defaults * width < len * width 且非默认项能装入 u32 时才采用 sparse。编码端只写非默认项；解码端先用 bitmap 判断目标项是否存在，再通过 base + popcount(bitmap & (bit - 1)) 算出压缩数组下标。width_and_sparse 的最低位保存布局标志，其余位保存元素宽度，元数据格式版本同步从 11 升到 12。

const SPARSE_BLOCK_LEN: usize = 64;
const SPARSE_INDEX_BYTES: usize = 12;

let sparse = u32::try_from(non_defaults).is_ok()
    && index_bytes + non_defaults * width < len * width;

index = base as usize + (bitmap & (bit - 1)).count_ones() as usize;

最有价值的实验、源码与 benchmark 细节： 作者本地测量的 .rmeta 体积在四个 crate、两种构建模式下全部下降：

官方 rustc-perf 则揭示成本：primary 的 97 个指令数样本平均回退 0.4%，范围 +0.1% 至 +2.6%；secondary 的 87 个样本平均回退 1.0%。与此同时，最大 RSS 在 primary 230 个样本平均改善 3.8%（-7.2% 至 -0.7%），secondary 225 个样本平均改善 4.2%；四个 linked binary 样本平均缩小 0.6%。但 bootstrap 489.187 → 489.990 秒（+0.16%），整套 artifact 406.93 → 409.04 MiB（+0.52%）。因此它证明了布局有效，却尚未证明当前实现的编译时间代价可接受。

适合的工程师背景： 熟悉序列化格式、编译器元数据、bitmap/rank 查询，或正在为稀疏索引在空间、随机访问与构建成本之间取舍的工程师。

预计阅读收益： 约 45–60 分钟；能掌握按实际字节数动态选择 dense/sparse、用 bitmap + prefix base 实现 O(1) 定位的方法，并学会同时审阅局部文件体积和全局编译器性能。

02 · rustc 类型 IR：给 Binder::map_bound 热路径强制内联

原文与日期： scrabsha，2026-10-17 17:33（中原标准时间）；Rust PR #164463、原始提交与完整 diff、源码上下文 和 rustc-perf 对比。

为什么值得读： 补丁只有两行属性，却作用在 trait 求解和类型变换会频繁穿过的通用 Binder 抽象上。它是验证“零成本抽象”不能只看源码形态的好样本：函数体只是拆包 Binder、执行 FnOnce、可选验证 bound vars、再封包；当编译器没有跨越该边界内联时，小成本会在 Diesel 这类泛型密集工程中累积。

核心技术结论： map_bound 与跳过 debug 验证的 map_bound_no_validate_bound_vars 都新增 #[inline(always)]。内联后，调用点可以直接看到 Binder { value, bound_vars } 的拆装、闭包调用与 cfg!(debug_assertions) 分支，为后续标量替换、闭包消除和死代码删除创造条件。该补丁没有删除验证逻辑，也没有把所有 Binder 方法一律强制内联，范围被限制在已有性能证据的两个热函数。

#[inline(always)]
pub fn map_bound<F, U: TypeVisitable<I>>(self, f: F) -> Binder<I, U> {
    let Binder { value, bound_vars } = self;
    let value = f(value);
    if cfg!(debug_assertions) {
        let mut validator = ValidateBoundVars::new(bound_vars);
        let _ = value.visit_with(&mut validator);
    }
    Binder { value, bound_vars }
}

最有价值的实验、源码与 benchmark 细节： 作者机器上，Diesel 全部 benchmark 的指令数平均下降约 1.10%，其他样本也有收益，ucd 除外。官方 rustc-perf 的结论更保守：9 个 secondary 指令数样本平均改善 0.3%，范围 -0.5% 至接近 0；primary 没有达到报告阈值的变化。bootstrap 从 491.611 → 490.603 秒，改善 0.21%，artifact 408.96 → 409.07 MiB，增加 0.03%。cycles 的两个 secondary 样本反而平均回退 2.4%（+2.0% 至 +2.7%），且没有相关 RSS 结果。这里最有价值的不是“加 inline 就会更快”，而是同一补丁在 instruction、cycles、体积三个维度的信号并不一致，必须以大样本和后续复测约束结论。

适合的工程师背景： 熟悉 rustc 类型系统、trait solver、泛型单态化，或正在评估 Rust/C++ 编译器内部 always_inline 使用边界的工程师。

预计阅读收益： 约 25–40 分钟；能理解热路径上的抽象边界如何妨碍后续优化，以及如何用指令数、cycles、bootstrap 与 artifact size 共同判断两行性能补丁。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-09-19 至 2026-10-18，单位人民币，六类硬件固定同一 SKU。今天通过公开比价页实时渲染结果复核 CPU、GPU、主板、HDD、SSD 五类报价；DRAM 页面仍显示“暂无报价”，因此不新增点。重复价格作为真实采样保留，用来区分“已复核横盘”和“未取得数据”。SSD 只记录固定 2TB 规格全网比价 ¥1,799，不采用跨容量 819 元起；主板继续采用当前规格全网比价 ¥1,298，不采用系列 1,169 元起。

价格来源： 9800X3D、MSI RTX 5070 VENTUS 3X、ASUS TUF B850M-PLUS WIFI7、Kingston FURY DDR5-6000 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。

判断依据

CPU、GPU、主板、HDD 与 SSD 今日都与昨日同口径报价一致。Ti600 2TB 连续两日为 ¥1,799，页面顶部 ¥819 仍是跨容量系列起价，不能作为 2TB 行情；HDD 固定 8TB SKU 连续三日为 ¥3,550，仍只说明原 ¥1,849 低价渠道退出后的可见报价变化。DRAM 固定 SKU 继续缺价，走势图保留真实空白尾段。本期没有加入未经核实的新品或原厂产能消息。

其它你可能关心的

• OpenJDK：C2 允许已知 null 参数绕过 unloaded signature class 的内联阻断

本期结论

两项工作分别触碰编译器的空间与时间边界：自适应稀疏表用 bitmap 与 popcount 换取元数据体积和峰值内存，却暴露了全局指令成本；Binder 强制内联以两行属性消除热抽象边界，指令数有小幅、可复核的改善，但 cycles 并未同步。工程上可迁移的共同方法是同时设计布局/优化规则和拒绝条件，并让负向指标决定补丁是否真正成熟。