Rocはlibdeflateにどこまで迫れるか、中央値でわずか2.6%差
How close can pure functional programming get to C?
Lean 4製のDEFLATEライブラリがRustを上回ったという話題を受け、著者は関数型言語Rocで書かれたroc-deflateを最適化し、C製の高速実装libdeflateとSilesiaコーパスで比較した。まだ0.1.0前の未成熟な言語ながら、非ストリーミングAPIでは中央値でM1 MacBook Pro上2.6%、Ryzen 3900X上8.9%遅いだけという結果に到達した。
roc-deflateはこれらの144ベンチマークで平均してlibdeflateより遅く、中央値ではRyzen 3900Xで8.9%、M1 MacBook Proで2.6%の遅さだった。
HNでの議論
81- jandrewrogers
最適化可能性の違いの多くは、C/C++ではかなり極端なコピー省略が可能であることに起因している。これはメモリ帯域が主要な性能ボトルネックになりがちだから重要だ。
C/C++のコードは、遠く離れた状態の一部に簡単に手を伸ばして直接変更できる。アクセス方法やパターンがどれほど醜くても、コンパイラが文句を言うことはほとんどない。不変条件が保たれることを保証するのはプログラマの責任であり、コンパイラが常にそれを見抜けるわけではない。こうした省略されたコピーは積み重なり、通常は保守性と安全性のコストを伴う。
これは、関数型言語が理論上は大規模並列性に優れた特性を持つにもかかわらず、実際のスーパーコンピューティングでは平凡な結果に終わりがちな理由と関係している。
- VorpalWay
> lean-zip はすべての圧縮レベルで 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/
- gobdovan
こうした最適化をライブラリとして公開し、プログラマが最適化パスを要求し、コンパイラが前提条件をチェックできるようにすることを検討したことはありますか？
というのも、JSがどこまで速くなるかについての記事を準備していて、同じことに気づいたんです。V8を十分にいじめれば、基本的にどんなコードでも最適化されたCコードの10%以内に収まります（ただしSIMDは例外で、明らかな場合でもSIMDに最適化されないV8のバグがあるようです）。これをライブラリに抽出してより効率的に行えることは分かりましたが、手動変換がどの程度一般化できるかは確信が持てません。
また、roc-deflateに取り組む中で、そのモデルに当てはまるような繰り返し現れる変換は見つかりましたか？それともほとんどの改善は圧縮に固有のものでしたか？
- ReDress
Cは確かに関数型言語だ。ほとんどのCプロジェクトは実世界で観察され、その後コンピュータにアップロードされたものだからね。
また、多くの場合で性能が究極の関心事であることも指摘しておきたい。
もし1分間に1000万回特定のメソッドにリクエストを送るサーバーがあるなら、性能の妥協は一切許されない。どんなものでも、絶対に。
高性能計算に関して、RustがC/C++に取って代わることは決してないだろう。
- johnny22
「X回ダウンロードされたクレートを上回る」と言うのは、それが人気だという以外の何も言っていない。もう少し詳細が見たいところだ。