Hacker News 中文摘要

RSS订阅

异步Rust与RTOS对决（2022） -- Async Rust vs RTOS showdown (2022)

原文链接 | HN讨论 | 2026-09-03 20:02:32

该文章对比了在STM32F446微控制器上使用Embassy/Rust与FreeRTOS/C运行相同应用程序的表现，从中断延迟、程序大小、内存占用和编程便捷性四个维度进行评估，旨在展示两种方案的常规应用差异。

正文

好的，这是根据您的要求，对原文进行的中文重述，保留了核心细节，并删减了与主题无关的内容。

标题：异步 Rust 对决 RTOS！—— 一场嵌入式领域的性能较量

核心内容： 本文在 STM32F446 微控制器上，将基于 Embassy 框架的异步 Rust 程序与基于 FreeRTOS 的 C 程序进行了正面比较。两个程序执行相同的任务，并从中断延迟、程序大小、内存占用和编程易用性四个维度进行评判。

测试程序： 程序包含三个任务： 1. LED 闪烁任务： 每 200 毫秒闪烁一次 LED（亮 100 毫秒，灭 100 毫秒）。当用户按钮被按下时，LED 不会点亮。 2. 按钮监控任务： 通过 GPIO 中断检测按钮状态变化，并将按钮状态（高/低）存储在一个共享的原子布尔变量中。每次状态变化时，将一条包含按钮状态和触发次数的字符串发送到消息队列。 3. 串口打印任务： 等待消息队列中的新消息，并将其打印到串口。

测量指标与预期： * 性能： 测量 GPIO 中断处理时间和按钮任务从等待到恢复的时间。预期 RTOS 在直接设置标志位方面可能更快。 * 中断（处理）延迟： 测量从中断开始到按钮任务恢复执行的时间。预期 RTOS 对此有更好的优化。 * 程序大小： 测量 .text 段大小。预期 Rust 程序因运行时检查和格式化开销会更大。 * 静态内存使用： 测量 .data + .bss 段大小。预期 Rust 的异步模型因只存储跨 await 点的变量，内存占用更小。 * 编程易用性： 主观评价。预期异步模型（async/await）比线程模型更易用。

实际结果（出乎意料）： 在所有测试项目中，Embassy/Rust 组合均胜出。

| 测试项目 | C (FreeRTOS) | Rust (Embassy) | 差异 | 差异百分比 | | :--- | :--- | :--- | :--- | :--- | | 中断时间 (平均) | 2.962us | 1.450us | -1.512us | -51.0% | | 线程时间 (平均) | 16.19us | 11.64us | -4.55us | -28.1% | | 中断延迟 (平均) | 4.973us | 3.738us | -1.235us | -24.8% | | 程序大小 | 20676b | 14272b | -6404b | -31.0% | | 静态内存大小 | 5480b | 872b | -4608b | -84.1% |

分析： 尽管在纯粹的上下文切换和线程恢复速度上，FreeRTOS 略快（2.011us vs 2.288us），但 Embassy 在中断处理时间上的巨大优势（快 51%）使其整体表现更佳。文章指出，RTOS 代码可以通过将按钮逻辑移至中断内部来优化，但这在 Embassy 中无法直接实现，体现了自由度和开发便利性之间的权衡。

结论： 作者宣布 Embassy/Rust 为本次对决的胜者。不仅在编程体验上更优，所有性能指标也均占优势。

补充说明： * 关于实时性： 虽然异步任务无法被抢占，但 Embassy 允许在中断上下文中运行额外的执行器，并通过中断优先级实现抢占，从而满足实时性要求。 * RTIC 附录： 文章后续补充了与 RTIC（另一个 Rust 嵌入式运行时）的对比测试。结果显示，RTIC 在各项指标上表现更优，这归因于其更轻量的运行时设计。

评论

根据评论内容，总结如下：

主要观点与论据：

  1. 标题误导性（评分：无，作者：CupricTea）：指出异步Rust与RTOS本质不同，RTOS是抢占式多线程，而异步是协作式。建议标题改为“嵌入式异步Rust vs. C RTOS”。

    • 关键引用："Async Rust != RTOS. RTOS's are preemptively multithreaded while async is done cooperatively with yield points."
    • 关键引用："Perhaps 'Embedded async Rust vs. C RTOS'"

  2. 基准测试方法缺陷（评分：无，作者：Animats、thejanus、yxhuvud）：多位评论者批评测试仅关注平均延迟和标准差，忽略最坏情况延迟（硬实时关键指标）。thejanus 指出测试负载不合理（USART打印远慢于按钮响应），且未使用RTOS的协作模式。

    • 关键引用（Animats）："They measured standard deviation, but not worst case... This is the difference between real time and 'near real time' scheduling."
    • 关键引用（yxhuvud）："Comparing RTOS latency with only averages and stddev may be the worst benchmark... Averages can lie by an arbitrary amount."

  3. 时效性与生态变化（评分：无，作者：joshchngs、bfrog）：文章已近5年，嵌入式Rust生态已变；Zephyr RTOS因厂商支持成为主流，Rust支持有限。

    • 关键引用（joshchngs）："This article is almost 5 years old now... I'd be cautious of relying on any details from it."
    • 关键引用（bfrog）："Meanwhile nothing really seems to matter anymore but Zephyr... Rust seems to have modest support in some places."

  4. 其他技术细节（评分：无，作者：IshKebab、potuskushner）：IshKebab 反驳“async在Web胜过线程”的说法，因Web从未支持线程；potuskushner 指出代码实为C++而非C。

平衡性总结：
评论整体对文章方法持批评态度，认为基准测试设计不当（忽略最坏情况延迟、负载不合理），且标题混淆异步与RTOS概念。部分评论强调生态变化（Zephyr崛起、Rust支持有限）和时效性问题。少数评论关注技术细节（如Web线程支持、代码语言误标）。无正面评价。