Rust vs C/C++ 在 FFmpeg-级编解码里的 5 % 性能差距究竟从哪来？

Rust vs C/C++ 在 FFmpeg-级编解码里的 5 % 性能差距究竟从哪来？

FFmpeg的一些主要编解码算法在社区有人进行了rust重写，但是最终的结果是 无论怎么优化，rust版本和C/C++语言版本依然有5%左右的性能差距，这导致目前rust版本完全无法被社区接受，本文将讨论：

1. 为什么这种性能差距无法被优化？rust语言的性能极限为何无法追平C/C++？
2. 为什么社区对仅仅5%的性能差距却带来显著的可维护性和内存安全性，依然完全无法接受？（为什么这 5 % 依旧是社区的“生死线”）

---

1. 先讲结论

1. 差距主要出在极端的“最后一公里”优化——手写 SIMD/汇编、指令调度、cache 微调、异常少见路径裁剪等。
2. Rust 理论上能做到同速，实践上难以全部复刻：
   • 生态里对汇编、多架构 SIMD、profile-guided hack 的支持还没 C 成熟。
   • LLVM 目前对 Rust 的前端产物在 register-allocation、instruction-selection 上仍落后 GCC + 手写汇编的组合。
3. 5 % 在音视频世界并非“小数点”：
   • 实时直播延迟、移动端续航、CDN 机房电费、硬解码 fallback 触发率都会被这 5 % 放大。
   • FFmpeg 是底座，任何上游应用的 CPU 占用线性叠加——全球范围内能省上万台服务器。
4. “内存安全与可维护性”≠ 立刻省钱。已有 C 代码已被 fuzz/ASAN/Valgrind“淬火”二十年，风险已货币化；而性能损失却是每天在烧电费。

---