日本語翻訳:

核心となる発見は、軽量な DEFLATE ライブラリがスピードと圧縮サイズの両面で Rust の同等物よりも優れているにもかかわらず、アーキテクチャ固有の SIMD 命令を用いた既存の C コードの方が依然として高速であるという点です。安全性を高めかつ unsafe コードブロックなしで決定論的な振る舞いを重視する新しいプログラミング言語 Roc は、現状では最適化された C インプリメンテーションに対し、平均ハードウェア環境において 2.6% から 8.9% の遅れを示しており、ベストケース（わずかに高速）とワーストケース入力（18% の低速）の間でパフォーマンスは大きく変動します。M1 MacBook および AMD Ryzen チップでのベンチマークは、libdeflate などの C ライブラリに対する Roc の現状の差が、raw speed への最適化ではなく安全性機能に重点を置いていることに起因することを確認しました。境界チェックのホイスティングやコンパイル時ルックアップテーブルといった特定の最適化にもかかわらずです。Roc の開発サイクルが長く、次期 0.1.0 リリースに向けていることを考慮すると、チームは次に「低めの実果」（low-hanging fruit）を対象とした最適化を行う予定です。その結果、最大のスピードを求める開発者は C または Rust を继续使用する可能性が高く、一方でサプライチェーンセキュリティを優先する者たちは、さらなる最適化が適用された後、Roc を有効な代替案として見出すでしょう。

なぜ Lean は Rust よりも高速なのか？そして Roc が C との壁を越えようとしている

2026 年 10 月 22 日付の記事「Why Lean is Faster Than Rust」において、著者が関数型プログラミング言語かつ証明支援系である Lean 4 を用いて記述した DEFLATE 圧縮ライブラリ

lean-zip

の驚異的な成果を共有しています。

Lean のパフォーマンス実績

Rust の主流パッケージを上回るパフォーマンスを発揮した

lean-zip

の詳細は以下の通りです。

miniz_oxide の凌駕: Rust の
```
miniz_oxide
```
が提供するすべての圧縮レベルを超越しています。
- 同等の圧縮率を保ちつつ、より高いスループットを提供可能。
- 高速設定では処理速度が +15%、かつ出力サイズが -8.8% に改善。
C のライブラリとの対比:
- ```
lean-zip
```
  は Rust の実装を凌駕しましたが、DEFLATE パフォーマンスの最高峰である C ライブラリ
```
libdeflate
```
  には敵いませんでした。
- ```
libdeflate
```
  はアーキテクチャ固有の SIMD を極めて慎重にチューニングした実装であり、Lean ではそのレベルまで踏み込めないため、完全に圧倒されています。

Roc の挑戦：C と対抗する関数型言語

この状況下で登場するのが、定理証明系ではなく実行時パフォーマンスを明確な目標に掲げる関数型言語 Roc です。

基本理念:
- キャッチフレーズは "Fast, Friendly, Functional"（高速・親しみやすさ・機能性）。
- 「Fast」が最優先であり、コンパイルと実行の両面で高速化が中核目標。
現状と課題:
- 初の本格的リリース（0.1.0）まで数週間待ちの新規言語。パッケージエコシステムの最適化は未成熟。
- しかし、新しいコンパイラ実装や長年の最適化技術の恩恵により、
```
libdeflate
```
  と対抗する基盤が備わると判断。

著者は

roc-deflate

（有料プロダクション環境で使用）のパフォーマンス最適化に時間をかけ、古典的な Silesia コーパス でのベンチマークを行い、「libdeflate の接近度合い」と「出力の同一性」を検証しました。

ベンチマーク結果：10% 以内のスロウダウン

2021 年製の M1 MacBook Pro と、AMD Ryzen 9 3900X（Ubuntu）での測定結果です。

平均パフォーマンス:
- ```
roc-deflate
```
  は
```
libdeflate
```
  よりも全体的に低速でした（中央値）。
- Ryzen 3900X: -8.9% スロー。
- M1 MacBook Pro: -2.6% スロー。
入力データによる変動:
- 最悪の場合:
```
libdeflate
```
  より 18% 遅い。
- 最佳の場合: 逆に
```
libdeflate
```
  よりわずかに 18% 高速。
- 平均的には劣りますが、特定の入力では Roc の実装が有利になるケースがあります。
C との性能ギャップ:
- 事実: C のパフォーマンス上限は Roc よりも高いです。
- ```
roc-deflate
```
  が現在の
```
libdeflate
```
  を上回るのは、C コードによってそのギャップを埋めるためであり、逆（Roc で C を凌駕する）は不可能です。

なぜ Roc は高速化できないのか？

セーフティの代償: Roc は境界チェックを実行し、自動メモリー管理を行います。「unsafe」を通じてこれらの制限を回避する手段がありません。
限界: これらの特性により、C や Zig などの「ハードウェアへの完全なアクセス」と比べて、Roc コードはより強力なセーフティ保証を得ていますが、その代わりにパフォーマンス上限が低下しています。

重要な結論: 「C のレベルのパフォーマンス」を実現することはできませんが、「以前誰も達成できなかったことが、今や可能であること」を示した点は画期的です。

パフォーマンスギャップを受け入れる意味とは？

「少し遅くてもよいのでしょうか？」という疑問に対し、純粋な Roc 実装には C にはない明確な利点があります。

1. メモリーセーフティ

言語レベルでメモリー不安全操作を完全に排除。
```
roc-deflate
```
は昨日発生した Brotli の RCE（遠隔コード実行）脆弱性を引き起こすような未検証メモリー操作にアクセスできません。

2. サイダーン・セキュリティ（副作用の無効化）

型システムが関数の純粋性（副作用の有無）を強制します（薄い矢印
```
->
```
と太い矢印
```
=>
```
）。
「薄矢印」を持つ関数は本当に純粋であることを保証され、予期せぬ副作用や状態変更を防ぎます。

3. サプライチェーンセキュリティ

FFI（Foreign Function Interface）を一切持たない。外部の危険なライブラリを呼び出すことが物理的に不可能。
ビルドスクリプトをサポートしないため、過去に Rust の
```
arrayref
```
パッケージで行われたようなビルドスクリプト攻撃や脆弱性の注入を防げます。

4. 移植性と決定論的振る舞い

同じ入力を与えれば、コンパイル先を問わないで常に同じ結果を返します。
システム間の挙動違いは、メモリー枯渇などの例外処理以外に起こりません。

トレードオフの問い直し

これらの保証（メモリーセーフティ、副作用無効化、決定論的振る舞い、ビルドスクリプト欠如によるセキュリティ）を放棄して、平均速度を 10% ほど向上させることを受け入れるべきか？

答えはケースバイケースです。
しかし、Roc コンパイラ自体がハードウェアの限界性能を狙っていることを考えると、このような「安全なままの高速化」に興奮すべきでしょう。

Roc 固有の最適化テクニック

roc-deflate

のパフォーマンス向上の多くは、Roc 言語全体に有効な一般的な技術と、Roc 固有の特性によるものです。

不要な共有を回避:
- 機会型変異（関数的だがインプレース）を活用し、値が一意であるように保つことで、共有メモリーのコストを削減します。
境界チェックの昇華:
- ループ開始前に早期リターン処理を入れるなど、コンパイラが「チェック不要」と判断できる状況を創出することで、高コストなループ内チェックを削除します。
コンパイル時評価による最適化:
- ランタイム入力に依存しないテーブルアクセスは、コンパイル時に解決されます（
```
lookup_table.get(5)
```
  のようなパターン）。これによりランタイムの境界チェックが不要になります。
加算演算のラップ（Wrap）の利用:
- ```
a + b
```
  はデフォルトでオーバーフローチェック付きですが、証明された安全な場合は
```
plus_wrap
```
  を使用して速度向上を図ります。コンパイラが最適化可能であれば両者は等価となりますが、そうできない場合は
```
plus_wrap
```
  が有利です。

今後の展望と改善の余地

著者は

roc-deflate

にさらに改善の余地があると考えています。特に x64 CPU 上での性能向上や、Roc コンパイラ自体のパイプライン最適化が期待されます。

現状: 容易なパフォーマンス向上（Low hanging fruits）はほぼ摘み取られたと判断。
目標: Roc 0.1.0 リリースへの準備と、より広範な実用的なコードベースへの汎用性の検証。
注意: 公開されたベンチマークスクリプトは生成 AI（Claude Opus）により作成されたため、セキュリティ審査を免れています。自己責任で実行してください。

Roc はまだ若く成熟途上ですが、「安全」と「高速」の狭間を行き来しつつ進化し続けています。

純粋関数型プログラミングがCにどのくらい近づけることができるのでしょうか。