纯函数式编程能逼近 C 语言吗？

How close can pure functional programming get to C?

▲ 256stmonty88 HN 评论区

Lean 4 编写的 DEFLATE 压缩库 lean-zip 曾击败 Rust 的 miniz_oxide，但在 C 语言实现的 libdeflate 面前仍显逊色。为了探索纯函数式编程的性能极限，我转向了主打“快速、友好、函数式”的 Roc 语言。尽管 Roc 尚处于早期版本，生态优化有限，但我对其进行了深度调优，重点优化了 roc-deflate 包的性能。在 M1 MacBook Pro 和 AMD Ryzen 9 3900X 上的基准测试显示，roc-deflate 在大多数场景下仅比 libdeflate 慢 2.6% 到 8.9%。这一结果证明，通过精心的编译器优化和语言设计，纯函数式语言在特定领域已能无限逼近 C 语言的性能表现。

roc-deflate 在 Ryzen 3900X 上的中位运行速度比 libdeflate 慢 8.9%，而在 M1 MacBook Pro 上仅慢了 2.6%。
阅读原文 →HN 评论区RSS

HN 评论区

88
  1. jandrewrogers

    可优化性的差异很大程度上在于 C/C++ 允许进行相当极端的拷贝省略（copy elision）。这很重要，因为内存带宽往往是主要的性能瓶颈。

    C/C++ 代码可以轻易地深入某个远程状态位并直接修改它。无论访问方法或模式多么丑陋，编译器通常都不会提出异议。确保不变量（invariants）成立是程序员的职责，而编译器并不总能看穿这一切。尽管这些被省略的拷贝累积起来效果显著，但通常会付出可维护性和安全性的代价。

    这也解释了为什么函数式语言尽管在理论上具有大规模并行化的优良特性，但在实践中往往难以胜任超级计算任务。

  2. VorpalWay

    > lean-zip beats every single compression level miniz_oxide

    miniz_oxide 是一个故意保持简单的实现。更公平的比较对象应该是较新的 zlib-rs[1]，它甚至跑赢了 zlib-ng（C 语言中最快的实现）[2]。

    [1]: https://lib.rs/crates/zlib-rs

    [2]: https://trifectatech.org/blog/zlib-rs-is-faster-than-c/

  3. WalterBright

    D 语言有一个不错的特性：函数可以被标注为 `pure`，编译器会检查该函数是否真的是纯函数。

    尝试重新组织代码以通过 `pure` 检查的过程还挺有趣的。

  4. andai

    > Roc is not a mature language (it's still weeks away from its first numbered release, 0.1.0)

    然后文章链接到一个视频，里面一位顾问提到已经在生产环境中使用了（似乎已经用了好几年？），这让我很困惑。

    你怎么能理直气壮地在客户项目中采用不成熟的技术呢？还是说，当它出问题时，你不得不去修复，这反而成了额外的福利？

    我是真的很好奇，也许情况没我想象的那么糟。但我以前用过不成熟的托管平台，结果对我而言简直是一场灾难！

  5. gobdovan

    你有没有考虑过通过库来暴露这些优化手段，让程序员可以请求特定的优化步骤，并由编译器检查前置条件？

    问这个是因为我正在准备一篇关于 JS 能有多快的文章，发现了类似的情况：只要把 V8 折磨得够狠，基本上任何代码都能达到优化后 C 代码 10% 的性能（SIMD 除外，那里似乎有个 V8 的 bug，即使情况再明显也不优化到 SIMD）。我琢磨着能不能把它提取成一个库，做得更流畅，但不确定手动转换能否很好地泛化。

    另外，在开发 roc-deflate 时，你有没有发现符合这种模型的重复变换模式，还是说大部分改进都特定于压缩算法？

同日更多故事

2026-10-24