📚 Phase 12.5 最適化戦略 & Phase 15 セルフホスティング計画
Phase 12.5: MIR15最適化戦略 - コンパイラ丸投げ作戦 - optimization-strategy.txt: 詳細戦略（MIR側は軽量、コンパイラに丸投げ） - implementation-examples.md: 具体的な実装例 - debug-safety-comparison.md: 現在のDebugBox vs ChatGPT5提案の比較分析 Phase 15: Nyashセルフホスティング - 究極の目標 - self-hosting-plan.txt: 内蔵Craneliftによる実現計画 - technical-details.md: CompilerBox設計とブートストラップ手順 - README.md: セルフホスティングのビジョン 重要な知見： - LLVM統合完了済み（Phase 11）だが依存が重すぎる - Craneliftが現実的な選択肢（3-5MB vs LLVM 50-100MB） - 「コンパイラもBox、すべてがBox」の夢へ MASTERロードマップ更新済み
This commit is contained in:
Moe Charm
38
docs/development/roadmap/phases/phase-12.5/README.md
Normal file
38
docs/development/roadmap/phases/phase-12.5/README.md
Normal file
@ -0,0 +1,38 @@
|
||||
# Phase 12.5: MIR15最適化戦略 - コンパイラ丸投げ作戦
|
||||
|
||||
## 📋 概要
|
||||
|
||||
Phase 12でMIR15が確定し、Phase 11でLLVM統合が完了した後の最適化フェーズ。
|
||||
「CPU（コンパイラ）に丸投げできるところは丸投げ」という哲学で、MIR15の美しさを保ちながら実用的な性能を達成する。
|
||||
|
||||
## 🎯 フェーズの目的
|
||||
|
||||
1. **MIR15の純粋性維持**: 15命令を増やさない
|
||||
2. **実用的な性能達成**: 既存言語の70%以上
|
||||
3. **開発効率最大化**: 車輪の再発明を避ける
|
||||
4. **将来性確保**: コンパイラの進化を自動享受
|
||||
|
||||
## 📊 主要成果物
|
||||
|
||||
- [ ] MIRMetadataシステム（ヒント付与）
|
||||
- [ ] 5つの軽量最適化パス
|
||||
- [ ] バックエンド別ヒントマッピング
|
||||
- [ ] 性能評価レポート
|
||||
|
||||
## 🔗 関連ドキュメント
|
||||
|
||||
- [最適化戦略詳細](optimization-strategy.txt)
|
||||
- [Phase 11: LLVM統合](../phase-11/)
|
||||
- [Phase 12: MIR確定](../phase-12/)
|
||||
|
||||
## 💡 キーインサイト
|
||||
|
||||
> 「MIRは"整える"だけ、速さはCPUに任せる」
|
||||
|
||||
複雑な最適化は30年の歴史を持つCコンパイラ/LLVM/Craneliftに任せ、
|
||||
Nyashは意味を保存するカノニカル化と最適化ヒントの付与に専念する。
|
||||
|
||||
## 📅 実施時期
|
||||
|
||||
Phase 11（LLVM統合）完了後、Phase 13（実アプリ開発）前に実施。
|
||||
約1ヶ月の開発期間を想定。
|
||||
@ -0,0 +1,160 @@
|
||||
# DebugBox比較分析：現在実装 vs ChatGPT5提案
|
||||
|
||||
## 📊 機能比較表
|
||||
|
||||
| カテゴリ | 現在のDebugBox | ChatGPT5提案 | 評価 |
|
||||
|---------|--------------|------------|------|
|
||||
| **基本追跡** | ✅ trackBox/watch | ✅ ハンドル表(id,gen,type,size) | 提案の方が詳細 |
|
||||
| **メモリ分析** | ✅ memoryReport（型別カウント） | ✅ + allocサイト追跡 | 提案の方が深い |
|
||||
| **リーク検出** | ❌ なし | ✅ 終了時ダンプ + CI失敗 | 提案が圧倒的 |
|
||||
| **UAF検出** | ❌ なし | ✅ 世代カウンタ + カナリア | 提案が圧倒的 |
|
||||
| **GC統合** | ❌ 独立動作 | ✅ gc=stress(k)モード | 提案が統合的 |
|
||||
| **非同期対応** | ❌ なし | ✅ Safepoint可視化 | 提案が先進的 |
|
||||
| **TaskGroup監査** | ❌ なし | ✅ LIFO順序保証 | 提案が構造化 |
|
||||
| **パフォーマンス** | ⚠️ 常にオン | ✅ リリースで0コスト | 提案が実用的 |
|
||||
|
||||
## 🎯 現在のDebugBox機能
|
||||
|
||||
### 強み
|
||||
1. **使いやすいAPI**
|
||||
- trackBox/watch でシンプルに追跡
|
||||
- dumpAll/memoryReport で情報取得
|
||||
- saveToFile で永続化
|
||||
|
||||
2. **高レベル機能**
|
||||
- ブレークポイント設定
|
||||
- 関数呼び出しトレース
|
||||
- コールスタック表示
|
||||
|
||||
### 弱点
|
||||
1. **安全性検証なし**
|
||||
- リーク検出機能なし
|
||||
- Use-After-Free検出なし
|
||||
- 世代管理なし
|
||||
|
||||
2. **GCとの分離**
|
||||
- GCと独立して動作
|
||||
- 統合的なメモリ分析不可
|
||||
|
||||
3. **性能影響**
|
||||
- 常に有効（無効化機能なし）
|
||||
- リリースビルドでもコスト発生
|
||||
|
||||
## 🚀 ChatGPT5提案の革新点
|
||||
|
||||
### 1. **リーク検出（最重要）**
|
||||
```rust
|
||||
// 終了時に自動実行
|
||||
fn dump_leaks_at_exit() {
|
||||
for (handle, info) in &HANDLE_TABLE {
|
||||
if !info.freed {
|
||||
eprintln!("LEAK: {} {} bytes at {:x}",
|
||||
info.type_name, info.size, info.alloc_site);
|
||||
}
|
||||
}
|
||||
if env::var("NYASH_FAIL_ON_LEAK").is_ok() {
|
||||
process::exit(1); // CI失敗
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. **世代管理によるUAF検出**
|
||||
```rust
|
||||
struct HandleInfo {
|
||||
id: u64,
|
||||
generation: u32, // free時にインクリメント
|
||||
freed: bool,
|
||||
canary: u32, // 0xDEADBEEF
|
||||
}
|
||||
|
||||
// アクセス時チェック
|
||||
if handle.gen != info.generation || info.canary != 0xDEADBEEF {
|
||||
panic!("Use-After-Free detected!");
|
||||
}
|
||||
```
|
||||
|
||||
### 3. **GCストレステスト**
|
||||
```rust
|
||||
// k回のalloc毎に強制GC
|
||||
if ALLOC_COUNT % GC_STRESS_INTERVAL == 0 {
|
||||
force_gc_collection();
|
||||
}
|
||||
```
|
||||
|
||||
### 4. **Safepoint可視化**
|
||||
```rust
|
||||
// MIR生成時に自動挿入
|
||||
before_await() {
|
||||
emit_trace("GC_Safepoint(await_enter)");
|
||||
}
|
||||
after_await() {
|
||||
emit_trace("GC_Safepoint(await_exit)");
|
||||
}
|
||||
```
|
||||
|
||||
## 💡 統合提案：DebugBox拡張
|
||||
|
||||
### Phase 1: 既存機能維持 + 安全性追加
|
||||
```nyash
|
||||
box DebugBox {
|
||||
// 既存機能はそのまま
|
||||
trackBox(box, name) { ... }
|
||||
memoryReport() { ... }
|
||||
|
||||
// 新機能追加
|
||||
enableLeakDetection() { ... }
|
||||
setGCStressMode(interval) { ... }
|
||||
dumpLeaks() { ... }
|
||||
checkInvariants() { ... }
|
||||
}
|
||||
```
|
||||
|
||||
### Phase 2: StatsBox新設
|
||||
```nyash
|
||||
box StatsBox {
|
||||
// 低レベル統計専用
|
||||
leak_summary()
|
||||
dump_alloc_sites(n)
|
||||
snapshot()
|
||||
diff(snapshot1, snapshot2)
|
||||
watch_handle(handle)
|
||||
}
|
||||
```
|
||||
|
||||
### Phase 3: GCBox拡張
|
||||
```nyash
|
||||
box GCBox {
|
||||
// GC制御
|
||||
force_collect()
|
||||
set_mode(mode) // "off", "sync", "stress"
|
||||
get_stats()
|
||||
set_stress_interval(k)
|
||||
}
|
||||
```
|
||||
|
||||
## 📈 実装優先順位
|
||||
|
||||
### 🔥 今すぐ実装すべき（Phase 12.5.1）
|
||||
1. **リーク検出** - 終了時ダンプ + `NYASH_FAIL_ON_LEAK`
|
||||
2. **世代管理** - Handleにgenerationフィールド追加
|
||||
3. **GCストレスモード** - `gc=stress(k)`オプション
|
||||
|
||||
### 📅 次に実装（Phase 12.5.2）
|
||||
1. **Allocサイト追跡** - 軽量版（ハッシュのみ）
|
||||
2. **Safepoint可視化** - trace出力
|
||||
3. **StatsBox** - 統計情報API
|
||||
|
||||
### 🌟 将来実装（Phase 13以降）
|
||||
1. **TaskGroup監査** - 構造化並行性の完全保証
|
||||
2. **Box監査フック** - invariantsチェック
|
||||
3. **差分スナップショット** - 高度なプロファイリング
|
||||
|
||||
## 🎯 結論
|
||||
|
||||
ChatGPT5の提案は「**簡単ライフサイクル × 自己責任 × 見える化**」という哲学を完璧に体現している。現在のDebugBoxを拡張し、新たにStatsBox/GCBoxと連携することで、以下を実現：
|
||||
|
||||
1. **開発時**: 徹底的な安全性チェック
|
||||
2. **リリース時**: ゼロコスト（環境変数で制御）
|
||||
3. **CI/CD**: 自動的な品質保証
|
||||
|
||||
「Everything is Box」を保ちながら、**死ぬほど安全**を実現する素晴らしい設計！
|
||||
@ -0,0 +1,218 @@
|
||||
# Phase 12.5: 実装例集
|
||||
|
||||
## 1. MIRMetadataの具体例
|
||||
|
||||
### StringBox.lengthのヒント付与
|
||||
|
||||
```rust
|
||||
// Before（ヒントなし）
|
||||
BoxCall {
|
||||
target: ValueId(0),
|
||||
method: "length",
|
||||
args: vec![],
|
||||
}
|
||||
|
||||
// After（ヒント付き）
|
||||
BoxCall {
|
||||
target: ValueId(0),
|
||||
method: "length",
|
||||
args: vec![],
|
||||
metadata: MIRMetadata {
|
||||
pure: true, // 同じ文字列→同じ長さ
|
||||
readonly: true, // 文字列を変更しない
|
||||
nothrow: true, // 例外を投げない
|
||||
noalias: true, // 結果は新しい整数
|
||||
..Default::default()
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
### ループの最適化ヒント
|
||||
|
||||
```nyash
|
||||
// Nyashコード
|
||||
for i in 0..1000 {
|
||||
array.push(i * 2)
|
||||
}
|
||||
```
|
||||
|
||||
```rust
|
||||
// MIRでのヒント
|
||||
Branch {
|
||||
cond: ValueId(5), // i < 1000
|
||||
then_block: BlockId(2),
|
||||
else_block: BlockId(3),
|
||||
metadata: MIRMetadata {
|
||||
likely: Some(true), // ループ継続が高確率
|
||||
loop_count: Some(1000), // ループ回数ヒント
|
||||
..Default::default()
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
## 2. Cエミッタでの変換例
|
||||
|
||||
### 純粋関数の最適化
|
||||
|
||||
```c
|
||||
// MIR: BoxCall(StringBox, "length") with {pure: true}
|
||||
// ↓
|
||||
// C出力:
|
||||
static inline int64_t __attribute__((pure))
|
||||
ny_string_length(NyashHandle h) {
|
||||
NyashString* s = ny_handle_to_string(h);
|
||||
return s->length;
|
||||
}
|
||||
```
|
||||
|
||||
### 分岐予測の最適化
|
||||
|
||||
```c
|
||||
// MIR: Branch with {likely: Some(false)}
|
||||
// ↓
|
||||
// C出力:
|
||||
if (__builtin_expect(!!(error_condition), 0)) {
|
||||
// エラー処理（めったに実行されない）
|
||||
ny_handle_error();
|
||||
} else {
|
||||
// 通常処理（ほぼ常に実行）
|
||||
continue;
|
||||
}
|
||||
```
|
||||
|
||||
## 3. 最適化パスの実装例
|
||||
|
||||
### 定数畳み込み（ConstFoldingPass）
|
||||
|
||||
```rust
|
||||
impl OptPass for ConstFoldingPass {
|
||||
fn run(&self, mir: &mut MIR) -> bool {
|
||||
let mut changed = false;
|
||||
|
||||
for block in &mut mir.blocks {
|
||||
for inst in &mut block.instructions {
|
||||
match inst {
|
||||
// Const(3) + Const(5) → Const(8)
|
||||
BinOp { op: Add, left, right, result } => {
|
||||
if let (Some(a), Some(b)) = (
|
||||
self.get_const_value(*left),
|
||||
self.get_const_value(*right)
|
||||
) {
|
||||
*inst = Const {
|
||||
value: Value::Integer(a + b),
|
||||
result: *result
|
||||
};
|
||||
changed = true;
|
||||
}
|
||||
}
|
||||
_ => {}
|
||||
}
|
||||
}
|
||||
}
|
||||
changed
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### デッドコード除去（DeadCodeElimPass）
|
||||
|
||||
```rust
|
||||
impl OptPass for DeadCodeElimPass {
|
||||
fn run(&self, mir: &mut MIR) -> bool {
|
||||
// 1. 使用されている値を収集
|
||||
let used = self.collect_used_values(mir);
|
||||
|
||||
// 2. 未使用の命令を削除
|
||||
let mut changed = false;
|
||||
for block in &mut mir.blocks {
|
||||
block.instructions.retain(|inst| {
|
||||
if let Some(result) = inst.get_result() {
|
||||
if !used.contains(&result) && !inst.has_side_effects() {
|
||||
changed = true;
|
||||
return false; // 削除
|
||||
}
|
||||
}
|
||||
true
|
||||
});
|
||||
}
|
||||
changed
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 4. バックエンド別の出力例
|
||||
|
||||
### zig cc向け（Ubuntu/macOS）
|
||||
|
||||
```bash
|
||||
# MIRからCへ変換
|
||||
nyash --emit-c program.nyash -o program.c
|
||||
|
||||
# 最適化コンパイル
|
||||
zig cc -O3 -flto -march=native \
|
||||
-fno-plt \
|
||||
-fomit-frame-pointer \
|
||||
program.c nyrt.c \
|
||||
-o program
|
||||
```
|
||||
|
||||
### MSVC向け（Windows）
|
||||
|
||||
```batch
|
||||
REM リンク時最適化を有効化
|
||||
cl /O2 /GL /MD program.c nyrt.c /Fe:program.exe ^
|
||||
/link /LTCG /OPT:REF /OPT:ICF
|
||||
```
|
||||
|
||||
### プロファイルガイド最適化（PGO）
|
||||
|
||||
```bash
|
||||
# Step 1: プロファイル収集
|
||||
zig cc -O3 -fprofile-generate program.c -o program_prof
|
||||
./program_prof < typical_input.txt
|
||||
|
||||
# Step 2: プロファイルを使用して再コンパイル
|
||||
zig cc -O3 -fprofile-use program.c -o program_opt
|
||||
```
|
||||
|
||||
## 5. 性能測定の例
|
||||
|
||||
```nyash
|
||||
// benchmark.nyash
|
||||
static box Benchmark {
|
||||
main() {
|
||||
local start, end, result
|
||||
|
||||
// ウォームアップ
|
||||
me.fibonacci(20)
|
||||
|
||||
// 測定開始
|
||||
start = Time.now()
|
||||
result = me.fibonacci(40)
|
||||
end = Time.now()
|
||||
|
||||
print("Fibonacci(40) = " + result)
|
||||
print("Time: " + (end - start) + "ms")
|
||||
}
|
||||
|
||||
@[pure, nothrow] // 最適化ヒント
|
||||
fibonacci(n) {
|
||||
if n <= 1 {
|
||||
return n
|
||||
}
|
||||
return me.fibonacci(n - 1) + me.fibonacci(n - 2)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 6. 最適化レベルごとの比較
|
||||
|
||||
| レベル | MIR最適化 | Cコンパイラ | 想定性能 | 用途 |
|
||||
|--------|-----------|-------------|----------|------|
|
||||
| 0 | なし | -O0 | 10% | デバッグ |
|
||||
| 1 | 基本 | -O2 | 50% | 開発 |
|
||||
| 2 | 全て | -O3 -flto | 70% | リリース |
|
||||
| 3 | 全て+PGO | -O3 -flto -fprofile-use | 85% | 高性能 |
|
||||
| 4 | 全て | LLVM -O3 | 90%+ | 特殊用途 |
|
||||
|
||||
*性能は理論上の最大性能を100%とした場合の目安
|
||||
@ -0,0 +1,208 @@
|
||||
================================================================================
|
||||
Phase 12.5: MIR15最適化戦略 - コンパイラ丸投げ作戦
|
||||
================================================================================
|
||||
|
||||
【基本哲学】
|
||||
「CPU（コンパイラ）に丸投げできるところは丸投げ」
|
||||
|
||||
MIR15の美しさ（15命令）を保ちながら、実用的な性能を達成する戦略。
|
||||
自前で複雑な最適化を実装するのではなく、既存の成熟したコンパイラ技術を活用。
|
||||
|
||||
================================================================================
|
||||
1. 最適化の境界線
|
||||
================================================================================
|
||||
|
||||
■ MIR15側でやること（軽量・意味保存のみ）
|
||||
├─ 定数畳み込み（Const Folding）
|
||||
│ └─ Const(3) + Const(5) → Const(8)
|
||||
├─ デッドコード除去（DCE）
|
||||
│ └─ 未使用のStore、到達不能コード除去
|
||||
├─ 分岐単純化（Branch Folding）
|
||||
│ └─ if true → Jump、if false → 削除
|
||||
├─ CFG整理
|
||||
│ └─ 空ブロック除去、ブロック併合
|
||||
└─ 軽量インライン化
|
||||
└─ 小さい関数のみ（10命令以下）、再帰なし
|
||||
|
||||
■ MIR15側でやらないこと（コンパイラに丸投げ）
|
||||
├─ ループ最適化
|
||||
│ └─ アンローリング、LICM、ベクトル化 → Cコンパイラ/LLVM
|
||||
├─ レジスタ割り当て
|
||||
│ └─ 完全にバックエンドに任せる
|
||||
├─ 命令選択・スケジューリング
|
||||
│ └─ CPU依存の最適化は触らない
|
||||
└─ SIMD/並列化
|
||||
└─ 高度な最適化は成熟したツールに
|
||||
|
||||
================================================================================
|
||||
2. ヒントシステム（命令を増やさずに最適化を強化）
|
||||
================================================================================
|
||||
|
||||
■ MIRMetadataの設計
|
||||
struct MIRMetadata {
|
||||
// 関数特性
|
||||
pure: bool, // 副作用なし（同じ引数→同じ結果）
|
||||
readonly: bool, // グローバル状態を読まない
|
||||
noalias: bool, // ポインタエイリアスなし
|
||||
nothrow: bool, // 例外を投げない
|
||||
|
||||
// 制御フロー
|
||||
likely: Option<bool>, // 分岐予測ヒント
|
||||
cold: bool, // めったに実行されない
|
||||
|
||||
// ループ特性
|
||||
loop_count: Option<u32>, // ループ回数ヒント
|
||||
vectorizable: bool, // ベクトル化可能
|
||||
}
|
||||
|
||||
■ 適用例
|
||||
BoxCall("StringBox", "length") → {pure: true, readonly: true, nothrow: true}
|
||||
BoxCall("ConsoleBox", "log") → {pure: false, readonly: false}
|
||||
Branch(cond, then, else) → {likely: Some(true)} // thenが高確率
|
||||
|
||||
================================================================================
|
||||
3. バックエンド別マッピング
|
||||
================================================================================
|
||||
|
||||
■ Cエミッタ（zig cc / clang / MSVC）
|
||||
├─ pure → __attribute__((pure))
|
||||
├─ readonly → __attribute__((const))
|
||||
├─ noalias → restrict
|
||||
├─ likely → __builtin_expect
|
||||
└─ cold → __attribute__((cold))
|
||||
|
||||
■ Cranelift
|
||||
├─ ヒントをCranelift IRのフラグに変換
|
||||
└─ 特にループとメモリアクセスのヒントが効果的
|
||||
|
||||
■ LLVM（実装済み・依存重いため非推奨）
|
||||
├─ 完全なメタデータサポート
|
||||
├─ !llvm.loop.vectorize.enable
|
||||
├─ !prof 分岐確率
|
||||
├─ noalias, readonly等の属性
|
||||
└─ ※Phase 11で実装完了、動作確認済み
|
||||
|
||||
================================================================================
|
||||
4. 段階的最適化レベル
|
||||
================================================================================
|
||||
|
||||
Level 0: 開発モード
|
||||
- MIR最適化なし
|
||||
- デバッグ情報完全保持
|
||||
- nyash program.nyash
|
||||
|
||||
Level 1: 基本最適化（デフォルト）
|
||||
- MIRカノニカル化のみ
|
||||
- Cエミッタ → gcc -O2
|
||||
- nyash --release program.nyash
|
||||
|
||||
Level 2: 高速化
|
||||
- MIR全最適化パス
|
||||
- Cエミッタ → zig cc -O3 -flto
|
||||
- nyash --release --opt program.nyash
|
||||
|
||||
Level 3: プロファイルガイド（PGO）
|
||||
- 実行プロファイル収集
|
||||
- ホットパス特定
|
||||
- nyash --release --pgo program.nyash
|
||||
|
||||
Level 4: 特殊用途
|
||||
- SIMD必要 → LLVM使用（ただし依存が重い）
|
||||
- 起動速度重視 → Cranelift JIT（推奨）
|
||||
- nyash --backend cranelift program.nyash
|
||||
|
||||
================================================================================
|
||||
5. 実装計画
|
||||
================================================================================
|
||||
|
||||
Phase 12.5.1: 基盤整備（1週間）
|
||||
□ MIRMetadata構造体追加
|
||||
□ 各MIR命令にmetadataフィールド追加
|
||||
□ デフォルトヒントの設定
|
||||
|
||||
Phase 12.5.2: MIR最適化パス（1週間）
|
||||
□ ConstFoldingPass実装
|
||||
□ DeadCodeElimPass実装
|
||||
□ BranchFoldingPass実装
|
||||
□ CFGCleanupPass実装
|
||||
□ LightInliningPass実装
|
||||
|
||||
Phase 12.5.3: バックエンド統合（2週間）
|
||||
□ Cエミッタでヒント→属性変換
|
||||
□ zig cc最適化オプション統合
|
||||
□ MSVC最適化オプション対応
|
||||
□ 簡易ベンチマーク作成
|
||||
|
||||
Phase 12.5.4: 評価・調整（1週間）
|
||||
□ 各最適化レベルの性能測定
|
||||
□ コンパイル時間 vs 実行時間のトレードオフ評価
|
||||
□ ドキュメント作成
|
||||
|
||||
================================================================================
|
||||
6. 成功指標
|
||||
================================================================================
|
||||
|
||||
- MIR15の命令数は変更なし（15命令維持）
|
||||
- 基本的なベンチマークで既存言語の70%以上の性能
|
||||
- コンパイル時間は既存言語の10%以下
|
||||
- 最適化パスのコード行数は1000行以下
|
||||
|
||||
================================================================================
|
||||
7. リスクと対策
|
||||
================================================================================
|
||||
|
||||
リスク1: ヒントが複雑になりすぎる
|
||||
→ 対策: 自動推論を強化、明示的ヒントは最小限
|
||||
|
||||
リスク2: バックエンド依存が強くなる
|
||||
→ 対策: 共通ヒントセットを定義、バックエンド固有は分離
|
||||
|
||||
リスク3: 性能が期待に達しない
|
||||
→ 対策: プロファイリング強化、ボトルネック特定
|
||||
|
||||
================================================================================
|
||||
8. なぜこの戦略が最適か
|
||||
================================================================================
|
||||
|
||||
1. シンプルさの維持
|
||||
- MIR15の美しさを損なわない
|
||||
- 最適化バグのリスク最小化
|
||||
|
||||
2. 実用的な性能
|
||||
- 成熟したコンパイラ技術を活用
|
||||
- 必要十分な性能を達成
|
||||
|
||||
3. 開発効率
|
||||
- 車輪の再発明を避ける
|
||||
- 既存ツールチェーンと協調
|
||||
|
||||
4. 将来性
|
||||
- コンパイラの進化を自動的に享受
|
||||
- 新しいCPUアーキテクチャにも対応
|
||||
|
||||
================================================================================
|
||||
9. Phase 11からの知見
|
||||
================================================================================
|
||||
|
||||
LLVM実装完了から得られた重要な知見：
|
||||
|
||||
1. 技術的成功・実用的課題
|
||||
- LLVM統合は技術的に成功
|
||||
- しかし依存関係が重すぎる（ビルド時間・バイナリサイズ）
|
||||
- Craneliftが現実的な選択肢
|
||||
|
||||
2. コンパイラ丸投げ戦略の妥当性
|
||||
- LLVMの重さを経験したことで、Cコンパイラ活用の価値を再認識
|
||||
- zig cc / clang / MSVCは既にインストール済み
|
||||
- 追加依存なしで高性能を達成可能
|
||||
|
||||
3. 段階的アプローチの重要性
|
||||
- 必要な時だけ重い最適化
|
||||
- デフォルトは軽量・高速
|
||||
- ユーザーが選択可能
|
||||
|
||||
================================================================================
|
||||
|
||||
「シンプルなMIR × 賢いコンパイラ = 実用的な性能」
|
||||
|
||||
これがNyashの最適化哲学。
|
||||
Reference in New Issue
Block a user