本期检索说明
先读取 content/collections/deep-radar 截至 2026-09-25 的全部原文链接，并按 URL、标题和实现机制去重。最近 24 小时有两项同时给出实测、源码级差异、原理解释与可迁移工程结论：Tokio AnyDelimiterCodec 的扫描热路径优化，以及 Kotlin/Wasm 通过去掉不必要 checked cast 改善 DCE 的产物裁剪。Java/JVM、Rust、Zig 与 Linux 的新候选没有同时满足三项证据红线，因此不为领域配额凑数。
Tokio 另有一项 LLC/NUMA 感知调度器给出大量 benchmark，但开放评审已指出最后一个 worker 离开分区时任务可能滞留、批量溢出可能绕过显式 placement，以及用进程而非当前线程 affinity 探测 CPU 的问题。本期只把它列入“其它你可能关心的”，不把尚有调度正确性风险的巨大加速数字当成可迁移结论。
| 主题 | 原始发布日期 | 一手来源与交叉验证 | 截稿状态 | 推荐强度 |
|---|---|---|---|---|
Tokio AnyDelimiterCodec 用 memchr 与 256 项查表扫描 |
2026-09-25 21:33（中原标准时间） | Tokio PR #8512 / 完整 patch / 8 MiB benchmark / 回归测试 | 开放评审 | 推荐，重点看分支特化与空间换时间 |
| Kotlin/Wasm 消除运行时 helper 的隐式 checked cast | 2026-09-25 16:33（中原标准时间） | Kotlin PR #8425 / 完整 patch / 六组 size test / JS 互操作回归测试 | 开放评审 | 推荐，重点看 DCE root 与类型收窄成本 |
01 · Rust/Tokio：单分隔符走 memchr，多分隔符改为 O(1) 字节查表
原文与日期： Emmanuel Bartlett，2026-09-25 21:33（中原标准时间）；Tokio PR #8512、完整源码 patch 与 AnyDelimiterCodec 源码。
为什么值得读： 旧实现对输入中的每个字节调用 seek_delimiters.contains(b)。当分隔符集合有 k 个元素时，扫描 8 MiB 输入不仅要读完整 haystack，还会在热循环中做最多 k 次线性比较。补丁没有改变 frame、max_length 或丢弃状态机，而是按分隔符数量特化：恰好一个分隔符时复用 LinesCodec 已采用的 memchr；多个或零个分隔符时，在构造阶段建立按 byte 值索引的 256 项布尔表。
核心技术结论： 这是一个很干净的“把集合成员测试移出热循环”案例。单值搜索交给 libc/平台优化的 memchr，多值搜索则把 Vec::contains 的 O(k) 比较降为一次索引读取。代价是每个 codec 实例增加 256 bytes；作者也试过 32-byte 的 u64 bitset，但小 frame 更慢，因此保留直接查表。工程上不能只比较大 buffer 峰值，还要同时检查小 frame 与对象体积。
let haystack = &buf[self.next_index..read_to];
let new_chunk_offset = match self.seek_delimiters[..] {
[delimiter] => crate::util::memchr::memchr(delimiter, haystack),
_ => haystack
.iter()
.position(|&b| self.delimiter_table[b as usize]),
};最有价值的实验、源码与 benchmark 细节： 在 Ryzen 9 5900X 上扫描 8 MiB 输入：单分隔符、1 KiB frame 从 1.77 提升到 3.37 GB/s，吞吐增加 90.4%，即 1.90 倍；四分隔符、256 B frame 从 0.67 提升到 1.51 GB/s，增加 125.4%，即 2.25 倍。2–4 byte 小 frame 保持不变，说明扫描成本不再占主导时没有可见收益。新增测试覆盖单分隔符、空分隔符、高位字节 0x80/0xff、最大长度和 Debug 输出；手写 Debug 刻意隐藏派生缓存，维持公开格式。
证据边界也很明确：数字只有一台 Zen 3 机器、单次作者报告，没有 Criterion 原始分布、不同 libc/架构或 codec 构造频率数据；256-byte 增量在大量短生命周期 codec 场景可能影响 cache footprint。复测应把分隔符数量、命中位置、frame 长度、构造/复用比例与 x86/AArch64 分开扫描。
适合的工程师背景： 维护网络协议解析、Tokio codec、字节扫描器，或需要在 SIMD/libc primitive、查表和 bitset 之间做热路径权衡的 Rust 工程师。
预计阅读收益： 约 25–40 分钟；能掌握按 cardinality 特化搜索、把派生索引放到构造阶段，以及同时审视吞吐、对象尺寸与小输入边界的方法。
02 · Kotlin/Wasm：一个 checked cast 为什么会把异常 helper 带进所有程序
原文与日期： Kotlin/Wasm 团队，2026-09-25 16:33（中原标准时间）；Kotlin PR #8425、完整源码 patch 与 Wasm stdlib 运行时代码。
为什么值得读： getKotlinException 是 JS 互操作的 DCE root。旧代码从 JS error 取回 kotlinException 后直接收窄成 Throwable；小整数/布尔装箱 helper 也把编译器 intrinsic 的泛型返回值再次收窄。虽然这些路径在源码里很短，checked cast 会引用带详细信息的 THROW_CCE_WITH_INFO，于是任何最小程序都无法把整套异常 helper 消掉。这篇补丁把“产物为什么凭空多出十几 KB”追到类型收窄和 DCE 可达图，而不是只压缩生成文本。
核心技术结论： JS 侧属性并不保证真是 Throwable，因此恢复异常时应先以 JsReference<Any>? 接收，再用安全转换；失败就包装为 JsException。装箱 intrinsic 的调用者只把结果存为 Any?，返回类型也改为 Any?，避免为一个并不需要的静态窄类型生成运行时检查。两处修改都削掉了从 DCE root 到 CCE helper 的边。
val kotlinException: JsReference<Any>? = (v as? JsError)?.kotlinException
return kotlinException?.get() as? Throwable ?: JsException(v)
internal fun <T> createBoxIntrinsic(x: T): Any? =
TODO("Make intrinsic after bootstap")最有价值的实验、源码与 benchmark 细节： 六组 size test 的 DCE Wasm 分别从 33,556→28,061、33,881→28,391、33,955→28,463、38,783→33,360、33,613→28,117、34,473→28,957 bytes，缩小 13.98%–16.38%。对应 .mjs 大多减少约 351–399 bytes。helloWorldPromise.kt 的 wasm-opt 输出从 3,562 降至 1,769 bytes，缩小 50.34%；其余极小 wasm-opt 样本只变化 0–3 bytes，说明收益取决于被整块裁掉的 helper 是否仍有其他引用。
补丁同时加入 JS→Kotlin 异常回归：真正的 Kotlin exception 必须保留对象身份，伪造的 kotlinException 属性若指向非 Throwable，必须回退成 JsException。限制在于这里测的是静态大小而非下载、解析或启动时间；PR 仍在开放评审，且另一项并行改动正在把装箱 intrinsic 返回类型改为非空 Any。工程复测应同时比较 gzip/Brotli 后大小和浏览器实例化时间。
适合的工程师背景： 熟悉 Kotlin/Wasm、JS interop、IR/DCE 或正在追踪“一个类型检查为何让最小 Wasm 包膨胀”的编译器与前端基础设施工程师。
预计阅读收益： 约 30–45 分钟；能理解 DCE root、运行时 helper 可达性、checked cast 与安全转换的代码尺寸差异，以及如何用 size test 固化最小产物预算。
中国大陆 ToC 硬件价格观察
数据口径
窗口为 2026-08-27 至 2026-09-26，单位人民币，六类硬件固定同一 SKU。今天通过公开比价页的实时渲染结果复核到 CPU、GPU、主板、HDD、SSD 五类报价；DRAM 页面仍明确显示“暂无报价”，因此不新增点。重复价格作为真实采样保留，用来区分“已复核横盘”和“未取得数据”。SSD 只采用当前 2TB 规格的全网比价栏，不采用跨容量聚合的“¥819 起”。
| 类别 | 9 月 26 日可复核价 | 30 日窗口内真实走势 | 建议 |
|---|---|---|---|
| CPU | Ryzen 7 9800X3D，京东 ¥2,619 | 9/3 ¥2,599 → 9/9 ¥2,449 → 9/23–24 ¥2,579 → 9/25–26 ¥2,619 | 观望或接近前低时入手；比窗口低点高 6.94%，连续两日横盘 |
| GPU | MSI RTX 5070 VENTUS 3X 12G，亚马逊中国 ¥4,464.34 | 8/29–9/26 十二个真实点均为 ¥4,464.34 | 刚需可比价后入手；该渠道横盘，但与国内自营售后口径不可等同 |
| 主板 | ASUS TUF B850M-PLUS WIFI7，天猫 ¥1,299 | 8/31 ¥1,449 → 9/2–9/26 ¥1,299 | 刚需可入；较窗口首点低 10.35%，多次复核横盘 |
| DRAM | 暂无报价；最后可复核 9/9 ¥3,900 | 9/2 ¥3,900 → 9/5 ¥3,860 → 9/6–9/9 ¥3,900 | 观望；固定 SKU 缺价，不用其他容量、颗粒或时序替代 |
| HDD | IronWolf Pro 8TB ST8000NE001，i百联 ¥1,849 | 9/1–9/26 十一个真实点均为 ¥1,849 | 容量刚需可买；先核对型号、五年保修与数据恢复服务 |
| SSD | ZHITAI Ti600 2TB，京东 ¥1,799 | 9/2 ¥1,919 → 9/23–26 ¥1,799 | 观望；可比价下降 6.25%，但近期公开爆料为 ¥1,889，需核对实际可下单价 |
价格来源： 9800X3D、MSI RTX 5070 VENTUS 3X、ASUS TUF B850M-PLUS WIFI7、Kingston FURY DDR5-6000 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。
判断依据
五个可报价 SKU 今天均与昨日持平，没有新的连续下跌信号。CPU 仍高于 9 月 9 日低点；GPU 是亚马逊中国渠道价，主板与 HDD 长时间横盘；SSD 的 2TB 比价栏为 ¥1,799，但同页 39 分钟前的京东爆料为 ¥1,889，说明聚合栏与实际活动价可能存在时差。DRAM 固定 SKU 继续缺价。基于这些证据，本期不把横盘解释成全市场稳定，也不预测继续下跌。
其它你可能关心的
- Tokio：LLC/NUMA 感知多线程调度器——benchmark 很完整，但开放评审已指出任务滞留、placement 失效和 per-thread affinity 三项正确性问题，暂不入选。
- rustc：缓存 improper_ctypes 的 FFI-safe 判定——源码机制合理，尚无公开 rustc-perf 或 wall-clock 数据。
- Kotlin/Native：为 Random 与 @ThreadLocal 增加 benchmark——基准基础设施有价值，但该 PR 本身还没有优化前后结果。
本期结论
两项改动都在处理“隐藏在抽象背后的固定成本”。Tokio 把每字节的线性集合搜索变成 memchr 或一次查表，在长扫描上达到 1.90–2.25 倍吞吐；Kotlin/Wasm 则去掉 DCE root 上不必要的类型收窄，让完整异常 helper 从最小程序的可达图中消失，DCE Wasm 缩小约 13%–16%。前者提醒先按集合基数选择 primitive，后者提醒静态类型的便利可能转化为运行时依赖。