本期检索说明

先读取 content/collections/deep-radar 截至 2026-09-17 的全部原文链接，并按 URL、标题与实现机制去重。最近 24 小时内，Rust core::num::bignum 的 limb 加宽补丁给出了 8 组微基准、完整源码差异和 32/64 位目标分流；Kotlin/JS 的 boxed Long 重构则在 9 月 17 日正式合入，原始算法可追溯到 ARITH 2026 论文与 Scala.js 证明，Kotlin 维护者也补做了 boxed/BigInt 两种模式的 benchmark。两项均满足量化实验、源码证据、原理剖析与工程迁移价值四项要求。

OpenJDK 当日候选主要是正确性修复或尚未公开 benchmark 的 Shenandoah 动态并发线程实验；Zig 已迁移到 Codeberg，公开新材料中没有形成三项证据闭环；Linux 新提交也没有找到同时提供可复现实测和源码级机制说明的候选，因此不凑数。Rust 补丁仍处于开放评审；Kotlin 补丁虽于本周期合入，但原始 PR 创建于 6 月 29 日，本文明确区分“算法首次公开”和“正式合入”日期。

主题 原始发布日期 一手来源与交叉验证 截稿状态 推荐强度
Rust Big32x40 → Big64x20 2026-09-17 10:18（中原标准时间） rust-lang/rust PR #162879 / core 源码与 coretests / 8 组微基准 Open，等待 libs team 评审 必读
Kotlin/JS boxed Long 算法重构 PR 2026-06-30 04:45；合入 2026-09-18 03:26（中原标准时间） JetBrains/kotlin PR #6450 / ARITH 2026 论文 / Scala.js 源码证明 / Kotlin 补充 benchmark 已合入 master 推荐

01 · Rust：用 20 个 u64 limb 替代 40 个 u32 limb，让 64 位机器少跑一半循环

原文与日期： kiana1kaslana，2026-09-17 10:18（中原标准时间）；rust-lang/rust PR #162879。截稿时补丁修改 4 个文件，增加 67 行、删除 17 行，仍在等待 libs team 评审。

为什么值得读： Rust core 的浮点转十进制 Dragon 路径需要一个不分配堆内存的定长大整数。旧的 Big32x40 用 40 个 u32 保存 1,280 位，恰好覆盖所有有限 f64 的 round-trip；但在 64 位 CPU 上，加法、乘除和移位仍按 32 位 limb 迭代，浪费了原生寄存器与 u128 中间结果。这个补丁保持容量和栈占用不变，只改变 limb 宽度与预计算常数布局，是典型的“数据表示决定热循环成本”案例。

核心技术结论： 64 位目标改用 Big64x20：20 × 64 位仍是 1,280 位、160 字节栈空间，却把多数逐 limb 循环的迭代次数减半。宏中 u64 运算早已有 u128 乘除中间类型，因此单 limb 乘法仍能完整保存高低半部；32 位目标继续保留 Big32x40，避免在没有高效 64/128 位算术的平台上反向拖慢。

Rust
#[cfg(target_pointer_width = "32")]
pub type Big = Big32x40;

#[cfg(target_pointer_width = "64")]
pub type Big = Big64x20;

变化不只是在类型别名。SMALL_POW5 为 u64 新增 5^27 = 7_450_580_596_923_828_125，而 u32 一次最多装下 5^13；mul_pow5 因此能以更大的幂块推进。Dragon 路径中 5^(2^n) 的预计算数组也重新按 64 位 limb 打包，例如 5^128 从 10 个 u32 变成 5 个 u64。from_u64 的右移改成 checked_shr(...).unwrap_or(0)，避免当 limb 本身就是 64 位时执行“右移 64”触发非法移位。

最有价值的实验、源码与 benchmark 细节： 作者在同一台 PC 上运行 library/coretests 的 bignum 与 flt2dec benchmark。大数路径全部明显受益：

Benchmark 40×u32 20×u64 变化
bench_big_exact_inf 33,568 ns ~21,700 ns 1.55×
bench_big_shortest 2,913 ns ~1,880 ns 1.55×
bench_big_exact_12 1,680 ns ~1,030 ns 1.63×
bench_big_exact_3 878 ns ~585 ns 1.50×
bench_small_exact_12 277 ns ~220 ns 1.26×
bench_small_exact_3 170 ns ~134 ns 1.27×
bench_small_shortest 320 ns ~275 ns 1.16×

负向数据不能省略：bench_small_exact_inf 从 1,353 ns 变成约 1,425 ns，实际慢约 5.3%，PR 表中把它概括为“约 1.0×”。这说明“limb 数减半”主要帮助真正进入多 limb 算术的输入；小值路径可能被固定开销、分支或测量噪声主导。当前结果也只来自一台未披露 CPU/OS 的机器，尚无 rustc-perf、跨架构或置信区间，因此合理结论是“局部微基准显示最高 1.63×，值得继续验证”，不是 Rust 格式化整体提速 63%。

适合的工程师背景： 熟悉 Rust core、浮点格式化、Dragon/Dragon4 或定长大整数，希望理解 limb 宽度、预计算幂表与目标字长如何共同影响性能的库和编译器工程师。

预计阅读收益： 约 45–70 分钟；可以掌握在不改变数值范围和内存占用的前提下切换 limb 宽度的方法，也能看到为什么边界移位、32 位兼容和负向小样本必须与主结果一起评估。

02 · Kotlin/JS：把 boxed Long 算法换成有证明的 Scala.js 实现

原文与日期： Sébastien Doeraene，PR 首次公开于 2026-06-30 04:45，2026-09-18 03:26 合入（中原标准时间）；JetBrains/kotlin PR #6450、ARITH 2026 论文 与 Scala.js Long 源码。

为什么值得读： JavaScript Number 只有 53 位整数精度，Kotlin/JS 在不使用 BigInt 的兼容模式里必须用两个 32 位整数表示一个 Long。旧实现混合了 Guava 风格无符号除法、较长的手写分支与若干重复转换；新实现把 Scala.js 已发表、已证明的 64 位算法移植进 Kotlin，同时让 compiler lowering 直接把 ULong 除法、余数、转字符串和数值转换指向专用 runtime helper。

核心技术结论： boxed Long 仍保留 low: Int 与 high: Int 两个 word，不改变 ABI。改动集中在算术：加减法通过无符号 low-word 比较传播 carry/borrow；乘法把操作数拆成更适合 JS 精确整数范围的块；除法与余数使用 ARITH 2026 中针对 JavaScript 双精度数设计的算法，减少昂贵的 64 位模拟基本操作。三个移位和 number 转换不在论文覆盖范围内，源码直接链接到 Scala.js 的机械证明，避免把“经验上能跑”当作正确性证据。

Kotlin
internal fun Long.toNumber(): Double =
    high.toDouble() * 4294967296.0 + uintToDouble(low)

private inline fun fromUnsignedSafeDouble(x: Double): Long =
    Long(jsToInt32(x), jsToInt32(x / 4294967296.0))

BigInt 模式也补齐 ULong 的显式无符号语义：先用 BigInt.asUintN(64, value) 转成 0 到 2^64-1，再做除法、余数或转字符串，最后以 asIntN(64, ...) 放回 Kotlin Long 的位模式。这样不再让通用 ULong 算法在 boxed 与 BigInt 表示之间兜圈。

最有价值的实验、源码与 benchmark 细节： 原论文把 Kotlin 旧除法同源算法作为 J2CL 基线；作者在评审中指出，新除法通常快 2–3×、最高约 5×。Kotlin 维护者随后把 PrimitiveLongTest 与 ULongTest 的新用例改成 benchmark，分别验证 boxed Long、boxed ULong 与 BigInt ULong 均有提升；同时发现 BigInt Long 中一些未被改动的操作存在小而稳定的差异，因此没有把图片结果简化成一个虚假的统一倍数。

可直接从仓库复核的另一项量化结果是最小产物体积：helloWorld 的 JS IR DCE 期望输出从 36,064B 降至 18,319B，缩小 49.2%；ES6 版本从 19,269B 降至 18,078B，缩小 6.2%。两者差距说明前者包含了较多旧 helper 与死代码被清除的收益，不能把 49.2% 外推到真实应用。补丁总计修改 29 个文件、增加 3,237 行、删除 396 行，其中约 2,656 行是 Long/ULong 边界测试；这比只看 runtime 的 420+/286- 更能说明迁移成本主要花在语义覆盖，而不是算法正文。

适合的工程师背景： 维护 Kotlin/JS、Scala.js、J2CL、Wasm/JS 互操作或需要在双精度 Number 上模拟 64 位整数的编译器与运行时工程师。

预计阅读收益： 约 75–110 分钟；可以理解两 word Long 的 carry、无符号转换与除法约束，学会把论文算法移植、compiler lowering、产物大小和跨表示测试组织成一条完整证据链。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-08-20 至 2026-09-18，单位人民币，六类硬件继续固定同一 SKU。9 月 18 日实际请求六个固定样本页时全部超时；搜索索引只能确认 DRAM 的常卖价与 8 月历史低价，不能证明今日可购报价，因此本期不新增 JSON 数据点，也不复制旧值冒充今日行情。折线尾部空白表示证据缺失，不代表横盘。

中国大陆六类 PC 硬件公开价格事件

类别 固定样本与最后可复核价 30 日窗口内真实走势 建议
CPU Ryzen 7 9800X3D，最后可核验 9/17 ¥2,619 8/21 ¥2,609 → 9/9 ¥2,449 → 9/14 ¥2,639 → 9/15、9/17 ¥2,619 观望；当前仍比窗口低点高 6.94%，下单前重核渠道价
GPU MSI RTX 5070 VENTUS 3X 12G，最后可核验 9/13 ¥4,464.34 8/29–9/13 六个真实点均为 ¥4,464.34，之后无新点 继续观望；样本已有 5 天延迟，不能把空白尾段视为稳定
主板 ASUS TUF B850M-PLUS WIFI7，最后可核验 9/8 ¥1,299 8/31 ¥1,449 → 9/2–9/8 ¥1,299 刚需可关注 ¥1,299；确认 WIFI7 版本、供电与售后
DRAM Kingston FURY Beast DDR5-6000 32GB，最后可核验 9/9 ¥3,900 9/2 ¥3,900 → 9/5 ¥3,860 → 9/6–9/9 ¥3,900 观望；索引中的常卖价仍为 ¥3,900，但不是今日实时成交价
HDD IronWolf Pro 8TB ST8000NE001，最后可核验 9/10 ¥1,849 9/1–9/10 五个真实点均为 ¥1,849 按容量刚需购买；优先比较五年保修和数据恢复服务
SSD ZHITAI Ti600 2TB，最后可核验 9/10 页面最低 ¥749 9/2 ¥1,919 → 9/5–9/10 ¥749；同页渠道价差异常大 仅在确认 2TB 规格、颗粒、商家与保修后考虑

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

判断依据

今天没有新增同口径价格事实，因此不更新涨跌结论。CPU 最新真实点仍高于 9 月 9 日低点；GPU、主板、DRAM、HDD 与 SSD 的末点已延迟 5–10 天，只适合作为历史参照。SSD 的 ¥749 继续视为需要核验规格和渠道的异常事件，不能外推为 2TB SSD 全市场价格。

其它你可能关心的

本期结论

两项优化都不是更换外部 API，而是让内部表示贴近宿主机器。Rust 在 64 位 CPU 上把 limb 宽度提升到寄存器宽度，Kotlin/JS 则接受 Number 只有 53 位精度的事实，用经过证明的双 word 算法减少模拟成本。共同的工程方法是：先保持范围、ABI 与语义不变，再用预计算常数、目标分流和大批边界测试替换热路径；同时保留小输入回退、未改代码的 benchmark 波动与单机测量局限。