浏览器里直接跑 Barnes-Hut t-SNE：Rust/WASM 把 7 万点可视化推到实时交互区间

这条项目的传播力也很强：作者把 Barnes-Hut t-SNE 这类原本经常伴随 Python/C++ 依赖、CUDA 或长时间等待的高维降维工具，直接推进到了 浏览器本地实时运行 的方向。核心底层是他持续优化的 bhtsne，作者称现在整体速度相比之前大约已经提升到 20 倍级，并且成功编译到了 WASM。

更妙的是，这不是“能跑就算完”。作者明确利用了浏览器现在可用的多线程能力，再配合 wasm-bindgen-rayon 把并行池带进去，所以整个体验变成了：把数据集拖进一个 Dioxus Web App，直接看 t-SNE 在页面里算出来，甚至还能导出短 WebM 视频。按作者描述，示例里展示的是 MNIST 7 万点 在先做 PCA 降到 20 维后的实时可视化，这已经不只是技术演示，而是开始具备“拿来探索数据”的味道了。

对 Rust 生态来说，这条线有两层价值。第一，它说明 Rust + WASM + 多线程浏览器 现在已经足以承载不止是小玩具，而是严肃一些的数据计算工作负载；第二，它把以往安装门槛很高的数据探索工具，压成了“开网页就能试”的形态。作者后面还打算继续给 bhtsne 补各种自定义索引和 ANN/LSH 路线。如果这条链继续打磨，Rust 做浏览器端科学计算演示的说服力会越来越强。

Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uiva30/barneshut_tsne_localized_entirely_within_your/ Web App：http://tsne.luca.phd/ 项目仓库：https://github.com/LucaCappelletti94/dioxus-tsne 底层仓库：http://github.com/frjnn/bhtsne

原文链接：https://old.reddit.com/r/rust/comments/1uiva30/barneshut_tsne_localized_entirely_within_your/

spmc-waker：比 AtomicWaker 更快，还把同步策略做成了可定制组件

spmc-waker 是作者刚发布的新 crate，目标非常明确：做一个面向 SPMC / 单注册者、多唤醒者 场景的 AtomicWaker 替代品，把 Rust 异步底层里那块“不起眼但经常在热路径上挨打”的唤醒原语重新打磨一遍。作者直说自己原先也以为 AtomicWaker 已经足够 lock-free，真正深入后才发现并不是这么回事，于是干脆自己做了一版。

这个 crate 的几个关键卖点放在一起看，挺有意思：更少的原子 RMW、更好的内联、更激进的 waker 缓存，以及把同步保证抽成泛型参数 Synchronization。也就是说，如果你的 wake 条件本身已经由更强的原子序或 RMW 操作兜住了，spmc-waker 内部就可以放松同步强度，把 wake 热路径在“没有注册 waker”的常见情况下进一步压轻。作者给出的 benchmark 里，单把 Tokio mpsc 内部的 AtomicWaker 替换成它，在一些场景里就能带来 10% 到 20%+ 的改进。

更难得的是，这项目不是靠“拍脑袋说更快”。作者把 loom、miri、汇编稳定性检查、甚至“逐个降低 memory ordering 看测试是否失败”的脚本都做了，说明它不是单纯拿 unsafe 换性能，而是真的在认真抠并发语义。代价也有：因为算法假定的是 SPMC，注册相关方法需要 unsafe 来保证不会并发调用。但对于本来就常出现在 lock-free channel 这类底层 unsafe 代码里的场景，这个交换其实挺合理。对做异步运行时、channel、调度原语的人来说，这个项目值得重点看看。

Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uj0hid/spmcwaker_a_faster_customizable_atomicwaker/ 项目仓库：https://github.com/wyfo/spmc-waker crates.io：https://crates.io/crates/spmc-waker 文档：https://docs.rs/spmc-waker

原文链接：https://old.reddit.com/r/rust/comments/1uj0hid/spmcwaker_a_faster_customizable_atomicwaker/

Ratatui 跑上 UEFI 裸机：TUI 直接进固件层，物理机还比 QEMU 更快

这条演示最抓眼球的地方很直接：Ratatui 居然已经被作者硬接到了 UEFI 环境里。也就是说，这不是“在 Linux 终端里跑个 TUI”，而是把界面直接推进到无操作系统、仅靠固件启动的层面。作者在 Reddit 里提到，靠 uefi crate 很快就拼出了一个能工作的后端，目前主要先把渲染打通，输入还没展开做。

仓库名就叫 ratatuefi，路线也说得很坦白：现在更像一个 hardcoded example，而不是现成库，但已经能在 QEMU 里跟着 uefi-rs 教程跑起来，也已经在真实机器上试过。更有意思的是，作者专门补充了一句：物理机上的效果明显比 QEMU 更快。这件事本身就挺说明问题——当 Rust TUI 生态往固件 / 裸机环境延伸时，性能瓶颈并不一定在框架本身，而常常出在当前渲染路径和虚拟化环境。

从 README 看，现阶段它还在用相当朴素的逐字符绘制方式，所以作者自己也承认“画起来慢得离谱”，后面可能会往缓冲、整行渲染，甚至更底层的 VGA 图形路径继续挖。但仅仅是把 Ratatui 成功搬到 UEFI，就已经足够说明：Rust 终端 UI 这条栈不只是做桌面小工具，它已经开始碰真正的系统边界了。

Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uiyqe5/ratatui_app_running_baremetal_uefi_application/ 项目仓库：https://github.com/sermuns/ratatuefi 配套 crate：https://crates.io/crates/uefi

原文链接：https://old.reddit.com/r/rust/comments/1uiyqe5/ratatui_app_running_baremetal_uefi_application/

rustc_codegen_gcc 第 42 期进展：Rust CI 覆盖冲到 80%，proc-macro 兼容问题已修正

rustc_codegen_gcc 是把 GCC 接到 rustc 前端后面的 AOT 代码生成后端，核心价值一直很明确：让 Rust 有机会跑到 LLVM 还没很好覆盖的平台上，同时复用 GCC 已有的优化和架构支持。这期进展里最值得看的不是单个 PR，而是整个项目和主线 Rust CI 的接合面明显更稳了——作者提到，之前一直在推进“把更多测试放进 Rust 仓库 CI”这件事，现在结果已经从上次的约 60% 覆盖提升到 80%。

具体变化也很扎实：最近几个月项目陆续补了 LTO 序列化处理、asm goto 输出操作数支持、alloc 测试、stdarch-tests 命令，以及多次从上游 Rust 同步；更关键的是，此前用 LLVM 编出来的 std 与 GCC 后端之间 ABI 配合导致的 proc-macro 使用问题，现在看起来已经修好，这让通过 rustup 分发的版本实用性往前走了一大步。

作者也没有把话说满。当前 Rust 仓库 CI 里仍有几块没有完全纳入，比如 LTO、stdarch、m68k 和非原生整数路径，其中 stdarch 依然是维护成本最高的一块，因为 LLVM intrinsic 和 GCC builtin 之间的映射经常要跟着上游变化一起修。接下来作者准备重新回到 m68k 可用 rustc 这条线继续推进。对整个 Rust 编译器生态来说，这种“不是另写前端，而是给现有 rustc 换一个 GCC 后端”的长期路线，含金量还是很高。

文章原文：https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-42 项目仓库：https://github.com/rust-lang/rustc_codegen_gcc Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uiytom/rustc_codegen_gcc_progress_report_42/

原文链接：https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-42