ハクソク

世界を動かす技術を、日本語で。

Bzip2クレートがCから100% Rustに移行

2025年6月18日原文(trifectatech.org)

概要

bzip2の最新版0.6.0がリリースされ、 Rust実装 のlibbz2-rs-sysがデフォルトに この変更により 高速化 と クロスコンパイル容易化 を実現 libbz2-rs-sysは Cダイナミックライブラリ としても利用可能 多くのプロジェクトが依然としてbzip2への依存を持つ現状 パフォーマンスや保守性、セキュリティ面での改善が主な利点

bzip2 0.6.0リリースとRust実装の導入

  • bzip2バージョン0.6.0 の公開
  • デフォルトで Rust実装（libbz2-rs-sys） を採用
  • bzip2 crateが 従来より高速化、クロスコンパイルも容易
  • libbz2-rs-sysは Cプロジェクト向けダイナミックライブラリ としてもビルド可能
  • 90年代のアルゴリズムだが、 多くのプロトコルやライブラリが依然bzip2を必要
  • 深い依存関係の中でbzip2が必要なプロジェクト多数

Rust化の背景と意義

  • zlib-rsの経験 を活かしbzip2実装を近代化
  • C依存から Rust依存へ移行 し、保守・ビルドの負担軽減
  • 以前の実装詳細は 「Translating bzip2 with c2rust」 で解説済み

パフォーマンス向上

  • Rust実装はC実装より全般的に高速
    • 圧縮は特に顕著な高速化
    • レベル設定はメモリ使用量のみ影響し、パフォーマンス差は小
  • ベンチマーク例（CPUサイクル数、低い方が高速）
    • sample3.ref (level 1): C: 38.51M → Rust: 33.53M（-14.87%）
    • silesia-small.tar (level 1): C: 3.43G → Rust: 3.00G（-14.30%）
    • silesia-small.tar (level 9): C: 3.47G → Rust: 3.17G（-9.66%）
  • 展開処理も全体的に 高速化
    • sample3.bz2: C: 2.53M → Rust: 2.42M（-4.48%）
    • zip64support.tar.bz2: C: 2.32G → Rust: 2.11G（-10.00%）
  • macOS上では展開速度にばらつき が見られることも
  • パフォーマンス測定の自動化が難しい環境も存在

クロスコンパイルの容易化

  • RustプロジェクトのC依存解消 でクロスコンパイルが容易
  • C依存時のビルドエラーやシステムライブラリの競合問題を回避
  • WebAssembly・Windows・Android 向けビルドも簡単
  • 保守性向上 とユーザー体験の改善

シンボル競合の防止

  • C依存の場合は シンボルがエクスポートされ競合リスク
  • libbz2-rs-sysは デフォルトでシンボル非エクスポート
  • 必要なら feature flagでエクスポート可能

MIRIによるテスト実行

  • 安全で高性能なbzip2実装にはunsafeコードが必要
  • MIRI でのテスト実行が可能
  • bzip2を利用する上位ライブラリやアプリも MIRIで検証可能

セキュリティ監査と改善

  • Radically Open Security による監査実施
  • オフバイワンのバグ とファザーの制限を修正
  • 重大な問題は他に発見されず
  • Christian Reitter らによるフィードバック
  • 監査レポートの公開

結論と謝辞

  • bzip2 crateは以前より高速化
  • 利用者は意識せずに恩恵を受けられる
  • Alex Crichton へのメンテナンス協力感謝
  • Radically Open Security への監査と専門知識の提供感謝
  • NLnet Foundation による資金提供感謝

Hackerたちの意見

Trifecta Techの実装が、2019年以降アップストリームリリースのないLinuxディストリビューションで使われている「公式」実装を置き換えるのはどれくらい現実的なんだろう？Fedoraは最近、元のAdler zlib実装をzlib-ngに切り替えたから、そういうことは不可能じゃないよね。元のものと互換性のあるC ABIを提供すればいいだけなんだ。

└

互換性のあるC ABIは提供してるよ。誰かが「ただ」その作業をやれば実現するんだ。

└

元のものと互換性のあるC ABIを提供すればいいだけなんだ。これって動的リンクとどう関わるの？今のRustツールチェーンって静的リンクを強制してるんじゃないの？

└

UbuntuはRustのsudoを使ってるから、確かに可能だよ。

└

それがuutilsの目標だと思う。 https://uutils.github.io/

パフォーマンス向上 uutilsの騒動の後、独立した検証なしで「Rustで書き直した」っていうプロモーションベンチマークを信じる人っているの？

└

もちろん、これらの結果は自分のシナリオで確認すべきだよ。でも、パフォーマンスにこだわっている人がbzip2を考慮するとはちょっと疑わしいな。設計スペースのどこを見ても、bzip2がzstdに勝るポイントはないし。zstdなら、一般的な入力に対して1/20の時間でより小さな出力が得られるし、同じ時間をかけてもかなり小さい出力が得られる。さらに、zstdの解凍は状況によって20～50倍速いから、bzip2の実装の速度について議論する価値はあまりないように思う。

└

uutilsの騒動の後 どの騒動のこと？

この「XをRustで書き直す」っていうのは、自分の家を燃やしてから再建して違う色に塗るみたいな感じがする。CPUサイクルを成果として数えるのは、現代のCPUリソースの50%がUIの見た目に使われてる世界では無関係に思える。

└

節約したサイクルはバッテリーの持ちを延ばすことにつながる。ポーティングの一度きりのコストを誰かが払ったから、今後ずっとより良いパフォーマンスを楽しめるんだ。

└

個人的には「クロスコンパイルを可能にする」って部分の方がずっと重要で、これは勝利だと思う。同じように、エクスポートされたシンボルやwasmに簡単にコンパイルできることも大事だよね。

└

バイナリファイルフォーマットのパース（と構築）は、バッファオーバーフローに対してあまり脆弱でない言語を使うのに良い場所だと思う。特に、一般的なフォーマットで、そのコードがいろんなセキュリティコンテキストで使われる可能性があるならなおさら。

Hacker Newsで議論の続きを見る