出来事の日付：2026年10月24日

関数型言語Rocで記述し、徹底的に最適化したDEFLATE実装が、アーキテクチャ固有のSIMD命令で調整された成熟したCライブラリ、libdeflateとの性能差を中央値で1桁％にまで縮めた。この結果は、プログラマーに安全性の保証を回避する抜け道を提供せずに、純粋関数型言語がどれほどの性能を発揮できるかを、限定的ながら具体的に検証したものだ。

開発者のリチャード・フェルドマンは、Silesia圧縮コーパスに基づく144のベンチマークで、roc-deflateとlibdeflateを比較した。roc-deflateはまだストリーミングを実装していないため、比較には非ストリーミングAPIを使い、圧縮結果が同一になることを確認した。AMD Ryzen 9 3900Xを搭載したシステムでは、roc-deflateは中央値で8.9％遅かった。2021年モデルのM1 MacBook Proでは、その差は中央値で2.6％に縮まった。

ただし、この中央値がすべての処理負荷を表しているわけではない。Rocの実装は、最も不得意な入力では最大18％遅く、最も得意な入力では18％をわずかに超える速さを示した。フェルドマンは、これがRocがCを上回ったことを意味するわけではないと注意を促した。両者の実装は異なり、C側に同等の最適化を施せば、現在Rocが先行しているケースでも差が埋まる可能性がある。Rocは低レベルのコードなら省ける検査や実行時の保証を維持するため、Cが全般的に到達し得る性能の上限は依然として高い。

Rocは自動参照カウントを使用し、境界検査を行い、Rustのようなunsafeモードを提供していない。型システムは純粋関数もサポートしており、副作用を制限して挙動を推論しやすくしている。そのため、この圧縮パッケージは、理論上の最高性能の一部と引き換えに、メモリ安全性の問題や予測しにくい挙動を減らすための保証を得ている。

この結果を支えた最適化には、ループ内の不要な処理を減らすなど、言語を問わずよく知られた手法がいくつか含まれる。一方で、Rocの設計に依存するものもある。条件が整った場合に値を破壊的に更新する仕組みにより、コンパイラーは関数型のプログラミングモデルを保ちながら、単独で所有されている値をその場で更新できる。また、開発者がコードの構造を工夫し、ループに入る前に境界検査が通ることをコンパイラーに証明させれば、繰り返される検査を取り除ける。

正しさに関する要件も重要だ。選択したコーパスに対し、両実装は同一の出力を生成する必要があった。これにより、速くても挙動の異なる圧縮処理を同等の結果として数えることを防ぎ、同じ処理を行うという条件の下で速度を比較できる。

このベンチマークは、あらゆる関数型プログラムが最適化されたCに迫れることを示す証拠ではない。Rocはまだ成熟途上にあり、roc-deflateには例外的に集中的な最適化が施され、テストは2台のマシン上の1つのアルゴリズム系統に限られている。ストリーミング性能も含まれていない。それでも、この実験は、安全性と関数型の純粋性が、システム寄りのあらゆる処理に自動的に大きな実行時負荷を課すわけではないことを示している。この結果がDEFLATE以外にも当てはまるかどうかは、成熟したパッケージを対象とする、より幅広いテストで明らかになる。