Files
hakorune/docs/development/roadmap/native-plan/llvm/VM-Native-Speed-Possibility.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

4.0 KiB
Raw Blame History

🚀 Nyash VM をネイティブ速度に近づける可能性

「もしかして、VM完璧に作ればネイティブに近づける

💡 その直感、正しいです!

現在のVM性能

  • インタープリター比: 50.94倍高速(達成済み!)
  • でもLLVMネイティブには及ばない...はず?

でも待って、よく考えると...

🔥 VMがネイティブに迫れる理由

1. JITコンパイルの可能性

// 現在: バイトコード実行
match opcode {
    Add => stack.push(a + b),
    // ...
}

// 将来: ホットパスをネイティブコードに!
if execution_count > HOT_THRESHOLD {
    let native_code = jit_compile(&bytecode);
    execute_native(native_code); // ほぼネイティブ速度!
}

2. 最適化の余地がまだある

現在のVM最適化:
  ✅ デバッグ出力削除
  ✅ HashMap → Vec
  ✅ メモリ効率化

まだできること:
  - レジスタVM化スタックVM → レジスタVM
  - インライン展開
  - 定数畳み込み
  - ループ最適化
  - SIMD活用

3. 言語特性を活かした最適化

// Nyashの特徴を利用
- Everything is Box  型情報を活用した特殊化
- Arc<Mutex>パターン  最適化可能な箇所を特定
- 限定的な言語機能  積極的な最適化

📊 他言語VMの実績

VM 対ネイティブ性能 特徴
JVM (HotSpot) 80-95% JIT最適化の極致
V8 (JavaScript) 70-90% 型推論+インライン
PyPy 400-700% (CPython比) トレーシングJIT
LuaJIT 90-99% 超軽量JIT

LuaJITは特に注目: シンプルな言語 + 優れたJIT = ほぼネイティブ!

🎯 Nyash VMネイティブ化戦略

Phase 1: 基礎最適化現在〜1ヶ月

// レジスタVM化
enum VMRegister {
    R0, R1, R2, R3, // ... R15
}

// より効率的な命令セット
enum Instruction {
    LoadReg(VMRegister, Value),
    AddReg(VMRegister, VMRegister, VMRegister),
    // スタック操作を削減
}

Phase 2: プロファイル駆動最適化2-3ヶ月

struct HotPath {
    bytecode: Vec<Instruction>,
    execution_count: u64,
    optimized_version: Option<OptimizedCode>,
}

// ホットパスを検出して最適化
if hot_path.execution_count > 1000 {
    optimize_hot_path(&mut hot_path);
}

Phase 3: 軽量JIT6ヶ月

// Cranelift使用で軽量JIT実装
use cranelift::prelude::*;

fn jit_compile(bytecode: &[Instruction]) -> NativeCode {
    let mut ctx = Context::new();
    // バイトコード → Cranelift IR → ネイティブ
    compile_to_native(&mut ctx, bytecode)
}

🔮 実現可能な性能目標

段階的目標

  1. 現在: インタープリター比 50倍
  2. Phase 1完了: 100倍レジスタVM化
  3. Phase 2完了: 200倍最適化
  4. Phase 3完了: ネイティブの80-90%JIT

なぜ可能か?

  • Nyashはシンプルな言語
  • Box型システムで最適化しやすい
  • 既に50倍達成の実績
  • MIR基盤が整っている

💭 VM vs LLVM の最終形

Nyash VM (完全体):
  利点:
    - ポータビリティ完璧
    - 起動時間高速
    - 動的最適化可能
    - デバッグ容易
  性能: ネイティブの80-90%

LLVM AOT:
  利点:
    - 最高性能100%
    - 事前最適化
    - 配布サイズ小
  欠点:
    - プラットフォーム別ビルド
    - 起動時最適化なし

🎉 結論VMでもいける

完璧に作れば、VMでもネイティブに迫れます

特にNyashのような

  • シンプルな言語
  • 明確な型システムEverything is Box
  • 限定的な機能セット

これらの特徴はVMの高速化に有利

もしかしたら、LLVM要らないかも...(いや、両方あると最強!)

Everything is Box、VM can be Native-Fast🚀