一个叫 libbeef 的项目最近出现在 GitHub 上：它是把 Fabrice Bellard 那个著名的任意精度浮点库 libbf 整个搬到 Rust 里的成果，命名很直白——“Beeg Float”。有意思的不是又多了一个大数库，而是它选的路：不追求比 GMP/MPFR 更快，而是要在纯 Rust、no_std、WASM、MIT 许可这几件事上补一个生态里长期缺的位置。
Bellard 是谁不用多解释，QEMU、FFmpeg、TinyCC 都是他的作品，风格一贯是“代码极简、算法渐近最优”。libbf 就是这种风格的产物：乘法用数论变换（NTT），除法和开方走牛顿迭代，超越函数用 AGM 或二进制展开，复杂度在理论上都是同类算法里最优的一档。libbeef 照搬了整套算法骨架，加上完整 IEEE 754 语义——次正规数、五种舍入模式、五种状态标志都齐全，还带十进制的 BigDecimal 类型。
数字好看，但对照对象要看清楚
作者给出的 benchmark 里，最能说明问题的是乘法曲线：从 256 位到 30000 位再到 300000 位，理论上二次算法每跨一个量级应该涨约 10 倍，但 libbeef 只涨了 4.2 倍再到 1.2 倍——这正是 O(n log n) 的 NTT 曲线形状，和 C 原版一致。到 300000 位时，libbeef 大约是 C 版 libbf 的 2 倍耗时、GMP（通过 rug 调用）的 1.3 倍。
这组数字容易让人觉得“Rust 版已经很接近 GMP 了”。但 Bellard 本人在 libbf 官方 benchmark 页面早就说清楚：libbf 在 1M 位以下通常慢于 MPFR/GMP，只有在超大数值时才能反超 GMP 约 1.2 倍，原因是 libbf 没有实现 Karatsuba、Toom-Cook 这类中间规模优化算法。GMP 的乘法是按操作数大小分级切换算法的一整套体系，从 basecase 到 Karatsuba 到 Toom-Cook，最后才上 FFT。libbeef 报告的“差距在大规模才缩小”，不是移植带来的新问题，是从 C 原版继承的老问题。
渐近最优不等于全程最优，libbf 系算法只在极端规模才占便宜。
这些数字目前只有一个来源
检索不到任何第三方对 libbeef 的评测、讨论或引用。所有性能数据——包括上面这张对照——目前只存在于项目自己的仓库里，没有独立复现。这不代表数据是假的，但意味着读者应该把它当作“作者自述”而不是“行业共识”来看。一个刚发布、单人维护的项目，benchmark 脚本是否可复现、测试机型和编译选项是否透明，都还没有答案。
- 提醒.libbeef 目前唯一的性能证据来自作者自己的仓库，尚无外部复现。
谁会真的换成它
真正会关心 libbeef 的，是那批被 rug 卡住的开发者：想在 WASM 或嵌入式环境里跑高精度浮点，又不想背 GMP/MPFR 的 C 编译器和系统库依赖。二进制体积上，libbeef 打包出来是 482 KiB，比只支持整数的 malachite（658 KiB）和把 GMP+MPFR 都静态链接进去的 rug（680 KiB）都小——换句话说，它用比对手做“纯整数”还小的体积，做到了完整浮点加三角函数。对于因为 LGPL 需要走法务审查的企业团队，libbeef 的 MIT 许可也是实打实的省事。
但换库不是没有代价。libbeef 的十进制路径目前还是绕道二进制转换，没有原生 base-10 内核，性能没调优；中等规模的乘除法，比起调优多年的 GMP/MPFR，差距依然摆在那——这不是 Rust 移植引入的新短板，是 libbf 算法本身的老问题。愿不愿意为可移植性和许可证让出这段性能，是每个团队自己要算的账，libbeef 目前给出的只是一个新选项，不是一个已经验证过的答案。