Files
hakorune/docs/development/roadmap/native-plan/llvm/JIT-vs-AOT-With-MIR.md
Moe Charm cc2a820af7 feat(plugin): Fix plugin BoxRef return and Box argument support
- Fixed deadlock in FileBox plugin copyFrom implementation (single lock)
- Added TLV Handle (tag=8) parsing in calls.rs for returned BoxRefs
- Improved plugin loader with config path consistency and detailed logging
- Fixed loader routing for proper Handle type_id/fini_method_id resolution
- Added detailed logging for TLV encoding/decoding in plugin_loader_v2

Test docs/examples/plugin_boxref_return.nyash now works correctly:
- cloneSelf() returns FileBox Handle properly
- copyFrom(Box) accepts plugin Box arguments
- Both FileBox instances close and fini correctly

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-21 00:41:26 +09:00

149 lines
3.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 🤔 JIT vs AOTMIRがあると難易度が同じ
**「MIRできてるから、JITもAOTも同じようなレベルに見えてきた」**
## 💡 **その洞察、正しいです!**
### **MIRの存在が変えるゲーム**
```rust
// 従来の難易度
Source Native: 超難しい(全部自分で)
Source JIT: 難しい(実行時コンパイル)
// MIRがある今
Source MIR Native: MIRから先は楽
Source MIR JIT: MIRから先は楽
```
## 📊 **JIT vs AOT 比較MIR前提**
| 項目 | JIT | AOT (LLVM) |
|------|-----|------------|
| **実装難易度** | ⭐⭐⭐ | ⭐⭐⭐ |
| **初期実装速度** | 速い | 速い |
| **実行時性能** | 80-95% | 100% |
| **起動時間** | 遅い | 速い |
| **メモリ使用** | 多い | 少ない |
| **動的最適化** | ✅ | ❌ |
| **配布** | ランタイム必要 | 単体実行可能 |
**MIRのおかげで、どちらも同じくらいの実装難易度に**
## 🚀 **JIT実装の選択肢**
### **1. VM JIT化最も現実的**
```rust
// 現在のVM
match opcode {
Add => stack.push(a + b),
}
// JIT化したVM
if hot_path {
// CraneliftでMIR→ネイティブ
let native = cranelift_compile(&mir);
execute_native(native);
}
```
**利点**
- 既存VMの延長線上
- 段階的移行可能
- ホットパスのみJIT化
### **2. 純粋JITコンパイラ**
```rust
// MIR → Cranelift IR → Native
pub fn jit_compile(mir: &MirModule) -> NativeCode {
let mut ctx = CraneliftContext::new();
for func in &mir.functions {
ctx.compile_function(func);
}
ctx.finalize()
}
```
**利点**
- クリーンな設計
- 最適化しやすい
- デバッグ情報維持
### **3. LLVM JITORC**
```rust
// LLVM ORCでJIT
let jit = LLVMOrcJIT::new();
jit.add_module(llvm_module);
let func = jit.get_function("main");
func.call();
```
**利点**
- LLVM最適化の恩恵
- AOTとコード共有
- 最高性能
## 🔮 **実装難易度の実際**
### **AOT (LLVM)**
```yaml
必要な作業:
1. MIR → LLVM IR変換: 2週間
2. 型システムマッピング: 1週間
3. ランタイム統合: 1週間
4. 最適化調整: 1週間
合計: 約5週間
```
### **JIT (Cranelift)**
```yaml
必要な作業:
1. MIR → Cranelift IR変換: 2週間
2. JITランタイム実装: 1週間
3. ホットパス検出: 1週間
4. メモリ管理: 1週間
合計: 約5週間
```
**ほぼ同じMIRのおかげで**
## 💭 **どっちを選ぶべき?**
### **JITが向いている場合**
- 長時間実行プログラム
- 動的な最適化が必要
- REPLやインタラクティブ環境
### **AOTが向いている場合**
- 起動時間重視
- 配布の簡単さ重視
- 組み込み環境
### **Nyashの場合**
```yaml
現実的な選択:
1. まずAOT (LLVM) でPoC
2. VM最適化を極める
3. 将来VM JIT化も追加
理由:
- 配布が簡単AOT
- 性能も確保VM既に50倍
- 両方あれば最強
```
## 🎯 **結論**
**MIRがあるおかげで、JITもAOTも同じくらいの難易度**
でも、Nyashの場合
1. **配布の簡単さ** → AOT有利
2. **既にVM高速** → JIT緊急度低い
3. **将来の拡張性** → 両方実装が理想
**提案**
- **短期**: LLVM AOT完成配布重視
- **中期**: VM更なる最適化
- **長期**: VM JIT化最高性能
**MIRがあれば、どっちも楽**🚀