krabby: 高速なRustコンパイラを作る
(bal-e.org)- Krabbyは、
rustcの遅いコンパイル速度を改善しようとする、性能優先のゼロから作るRustコンパイラ実装 rustcの体感性能改善は、もはや単一関数の変更よりもAPIとデータ構造の変更から生まれるが、大規模コードベースと安定性要件のため、大きな変更は難しい状況- Krabbyは、1人で制御できる小さなコードベースで安定性を優先せず、コンパイラの構成要素をまとめて再設計することで、新たな最適化の機会と一貫性のあるアーキテクチャを探ろうとしている
- 目標は、コンパイラ性能を大幅に高めるには設計を完全に見直す必要があるという仮説を、Rustのように複雑な言語でも検証すること
- コードはCodebergのkrabbyリポジトリで公開されており、進捗はFediverseに1〜2週間に1回以上投稿することを目標としている
Krabbyの目標と背景
- Rustは好みの言語だが、
rustcコンパイラは目に見えて遅い rustcの性能改善にはすでに多くの人が取り組んでおり、単一関数の変更で体感性能を上げられる改善は、ほぼ実装し尽くされている状態に近い- 意味のある改善は今やAPIとデータ構造の変更から生まれるが、
rustcのような大規模コードベースでは、複数機能の開発と安定性要件のため、大規模変更は事実上難しい - Krabbyは、性能を最優先にしたゼロから作るRustコンパイラ実装であり、
rustcとは目標が根本的に異なる - 小さなコードベースを1人で制御し、安定性を優先しないため、すべての構成要素を相互に考慮しながら設計することで、新たな最適化の機会を見つけ、より一貫性のあるアーキテクチャを作ろうというアプローチ
- コンパイラ性能を大きく改善するには、コンパイラ設計を完全に考え直す必要があるという仮説から出発している
- 大規模なアーキテクチャ最適化は対象言語に関係なく潜んでいる可能性があり、単純なCのような言語だけでなく、Rustのように複雑な言語にも適用できることを示そうとしている
- 結果の設計がRust特化になったとしても、その過程で得られる学びには価値があると見ている
プロジェクトの状態と公開資料
- Krabbyは非常に大きなプロジェクトであり、完成できるかどうか、あるいは自分がその適任者かどうかについては確信が持てない
- ただし、コードを最適化し完成度を高めていく過程そのものが好きであり、価値があると思える目的のために良いコードを書く楽しさが、今の原動力になっている
- コードはCodebergのkrabbyリポジトリで公開されている
- 進捗はFediverseに1〜2週間に1回以上投稿することを目標としており、より掘り下げた長文アップデートも同じサイトに掲載する予定
- 興味のある人はメールで連絡できる
-
関連する進捗記事
- identifier interning in 2025: 2026年4月20日
- a year of krabby: 2026年4月12日
- introducing
takeaway: 2025年8月11日 - krabby: for context: 2025年6月1日
- krabby: proof of concept: 2025年5月17日
- krabby: the architecture: 2025年4月27日
- krabby: making an AST: 2025年4月19日
- krabby: trying out parent ptrs: 2025年4月12日
- krabby: motivations: 2025年4月5日
1件のコメント
Lobste.rs の意見
みんな自分だけの 見栄ライセンス を持ちたがっているようだ https://codeberg.org/bal-e/krabby/…
このライセンスでは、個人・非商用目的での利用と共有は無料で許可されるが、それを基に作ったソフトウェアも同じ条件で共有しなければならず、商用目的は30日間のみ試用可能となっている
Codeberg がプロジェクトのライセンスに厳格な libre/オープンソース要件を課しているのか気になる。Codeberg は FOSS だけをホスティングしていると思っていたので、非商用利用制限 は意外だったが、最近の状況を追えていないだけかもしれない
Rust は規模が大きい。このプロジェクトは「自分で Web ブラウザを作る」よりは少し易しそうに見えるが、だからといって決して簡単ではない。それでも目標が大きい点は評価したい
krabby: motivations を見ると、速度がこのプロジェクトの主な動機のように見える
Rust についての自分の理解では、型検査や借用検査などはすでに非常に高速で、ボトルネックは コード生成 であり、そのかなりの部分は Rust 自体というより LLVM に関係している
最近の Cranelift 側がどうなっているのか、コード生成速度を高めるアイデアと重なる部分があるのか気になる
個人的には、コンパイルパイプライン全体を見るとそれはかなり筋が悪いと確信している。MIR 専用 rlib が必要だし、無限の RAM がなくても全世界最適化できるバックエンドが必要だ（このコメント 参照）
「Codegen Unit」は完全に偶発的複雑性だ
特に libraries と binaries の具体的な内訳は興味深いかもしれない
LLVM が速い方ではないのは確かだが、rustc が LLVM にやや 膨らんだ IR を渡しがちなことも助けになっていなかったと記憶している
自分の中期目標、つまり今後5年ほどの目標は
cargo checkなので、コード生成には手を付けないそれでも、よりよい並列性、診断コードのホットパス分離、型検査と借用検査の間の重複作業の削減、コアデータ構造のメモリ配置改善など、最適化の余地は まだかなりある と見ている
rustc 開発者たちと親しく、コードベースのさまざまな問題をよく聞いているのも助けになっている