堅牢.py#2 LT資料

私が以前より作っているコンパイラの紹介と進捗です。

Transcript

1. at the compiler level. NAME OF PROJECT: Lython PRESENTED BY: t3tra Kenro.dev 堅牢.py #2 Rebuilding Python 1/15
2. Pythonを作り直して安全にする Lython: 静的決定を最⼤化する実験的コンパイラ コンパイル言語として Python を「実⾏時に頑張る」から「コンパイル時に決める」へ寄せる 静的型付け言語として 暗黙変換を減らし、型境界をIR で明⽰化する 今日は実装の中身について話します デモとかはないです 2/15
3. 自己紹介 将来の夢は全人類の脳で80 億ノード分散コンピューティング ハンドルネーム: t3tra 読みはテトラです。leet 表記的な... 所属: “Contributing Member” @ Python Software Foundation 唯一誇れる肩書きがコレしかない Python 歴: 6 年くらい... ？ 本で存在を知り紙とペンで書いていました 自由に使える電子機器を与えられたのが高2 入ってからなのでそう言う意味では2 年弱 3/15
4. 問題設定 Python の安全性課題は仕様だけでなく実装戦略でも決まる 代表的な課題: 暗黙変換が多く、境界が見えにくい 実行時に型が確定するため、失敗が遅い 例外や呼び出し規約が高コストになりやすい 4/15 方針: 境界をIR で明⽰ verifier で機械的に制約を強制 実行前に決められるものは決める
5. LLVM/MLIR とは この処理系が基盤にしている技術 LLVM: 古くから存在するコンパイラインフラストラクチャ “LLVM Project” として LLVM Core に加え MLIR や Clang 、OpenMP などを持っている Swift, Rust, Zig など様々な言語の処理系で使われている 5/15 MLIR: 中間表現 (IR) を段階的に変換するための基盤 Dialect ( 方言): ⽬的ごとの IR 語彙 (Lython では `py.*` を定義) Pass: IR を検証/ 変換する処理単位 Verifier: IR が設計ルールを満たすかをコンパイル時に検査する実装
6. 全体パイプライン CLI から受け取った入⼒をどう処理していくか 実際の順序 (tools/CLI.cpp): 1.`NativeVerificationPass` 2.`RefCountInsertionPass` 3.Canonicalizer + CSE 4.RuntimeLoweringPass` 5.Bufferize / LinalgToLoops / ConvertToLLVM 6/15 「どこで安全性を担保しているか」を工程別に示す
7. 型システムの中核 (Two Worlds) `py.*` (boxed) と primitive (unboxed) を分離する 7/15 Object World: `!py.int`, `!py.float`, `!py.bool`, `!py.object`, `!py.func` など Primitive World: `i32`, `i64`, `f64`, `tensor<...>` などMLIR primitive `@native` 関数は Primitive World 専⽤ `py.make_native` / `py.native_call` / `func.func` 連携で境界を明⽰
8. 暗黙的型変換の禁止 変換は必ずIR に明⽰する安全化の主軸 8/15 代表op: `py.cast.to_prim` (unbox) `py.cast.from_prim` (box) `py.upcast` (`!py.object` への拡⼤) `py.cast.identity` (lowering 時の表現橋渡し) verifier で不正を拒否: `mode` は `exact|truncate|saturate` のみ 未対応な型組み合わせはコンパイル時エラー
9. verifier で守る内容 主要なものを幾つか紹介します 9/15 呼び出し規約: `maythrow` callee は `py.invoke` 強制 `nothrow` callee に `py.invoke` は禁⽌ native 純粋性: native 関数内に `!py.*` が混ざると失敗 型整合: 引数/ 戻り値/ ブロック引数の型⼀致を厳密検査 目的: 実行時の「運が良ければ動く」を排除する
10. 追加の安全策 `alloc/dealloc` のペアリングをvisitor 層で追跡 10/15 検出できるもの: double alloc / double dealloc dealloc 前提違反 use-after-dealloc dealloc 漏れ 型レベルでリソースの使用を追う: 静的型だけでなく資源使用の健全性を担う 参照カウントの最適化にも繋がる
11. 例外機構 処理系レベル安全化の延長 11/15 デバッグ情報の埋め込み: C++ の例外の仕組みを踏襲 DWARF メタデータを⽤いて格納 例外の発生: 例外が起きなければゼロコスト 例外が発生した場合のみトレースの巻き戻し・例外オブジェクトの生成が走る
12. プリミティブの表現 C ABI 互換の FFI やプリミティブ型の扱い 12/15 CPython 互換オブジェクト def fib(n: int) -> int: if n <= 1: return n return fib(n - 1) + fib(n - 2) print(fib(35)) GC オーバーヘッド・多倍長整数 Lython Primitive from lyrt import from_prim, native from lyrt.prim import Int p1 = Int[32](1) p2 = Int[32](2) @native(gc="none") def fib(n: Int[32]) -> Int[32]: if n <= p1: return n return fib(n - p1) + fib(n - p2) print(from_prim(fib(Int[32](35)))) GC なし・C 同等・Python の文法として正当 (inspired by jaxtyping!)
13. ベンチマーク Fibonacci 数の計算を例に最適化の効果を検証 13/15 カテゴリ CPython Lython (JIT) Lython Primitive (JIT) 実行時間 (fib(40)) 7201 ms ± 202 ms (x 1.0) 2563 ms ± 44 ms (x2.8) 186 ms ± 3 ms (x38.7) 互換ランタイム CPython と同じ多倍長整数の実装を⽤いるが、 参照カウント最適化やゼロコスト例外の仕組みにより2~3 倍の高速化を実現 Lython Primitive 多倍長整数を用いないため、動的メモリ確保等のコストが大幅に省略できる オーバーフローする可能性が生まれる
14. まとめ Python の安全性を担保する為に、処理系側を作り直す発想 14/15 実装的コア: Two Worlds (boxed/unboxed) 明示cast + verifier invoke/unwind ベースの例外表現 実務直結の「堅牢な型」テーマを、言語処理系側から再設計する余地は大きい このプロジェクトは趣味と実験 ただ、型安全と実行モデルを同時に扱う研究対象としては十分面白い ( はず)
15. まとめ Python の安全性を担保する為に、処理系側を作り直す発想 ( 正気の沙汰ではない) 15/15 リポジトリ: Future Work: BLAS/LAPACK へ接続し高速化 　 (NumPy を超えたい) WASM/WASI support 　 ( ブラウザ上で軽く動かしたい) クロスコンパイル ( コンパイラとしての人権) abi3 互換レイヤ (CPython 互換) 未実装の他構文 (assert とか for/yield とか) 記事類: https://zenn.dev/t3tra