185 lines
5.4 KiB
Markdown
185 lines
5.4 KiB
Markdown
|
# MIR13時代の論文戦略 - 2本構成の提案
|
|||
|
|
|
|||
|
|
Date: 2025-09-03
|
|||
|
|
Author: Claude + にゃ
|
|||
|
|
|
|||
|
|
## 📚 2本の論文に分ける理由
|
|||
|
|
|
|||
|
|
### なぜ2本が良いか
|
|||
|
|
1. **読者層が違う** - システム屋 vs 言語設計者
|
|||
|
|
2. **評価軸が違う** - 実装の幅広さ vs 設計の美しさ
|
|||
|
|
3. **投稿先が違う** - システム系会議 vs プログラミング言語系会議
|
|||
|
|
|
|||
|
|
## 🎯 論文A: 実装の幅広さ（システム寄り）
|
|||
|
|
|
|||
|
|
### タイトル案
|
|||
|
|
**"From Interpreter to Native GUI Apps: Universal Execution with 13 Instructions"**
|
|||
|
|
|
|||
|
|
### 日本語仮題
|
|||
|
|
「13命令で作る万能実行系：インタープリターからネイティブGUIアプリまで」
|
|||
|
|
|
|||
|
|
### ストーリー
|
|||
|
|
```
|
|||
|
|
MIR13という超コンパクトIR
|
|||
|
|
↓
|
|||
|
|
インタープリター実装（開発用）
|
|||
|
|
↓
|
|||
|
|
VM実装（高速実行）
|
|||
|
|
↓
|
|||
|
|
JIT/AOT（Cranelift統合）
|
|||
|
|
↓
|
|||
|
|
ネイティブEXE生成（lld内蔵）
|
|||
|
|
↓
|
|||
|
|
Windows GUIアプリも動く！（EguiBox）
|
|||
|
|
↓
|
|||
|
|
「たった13命令ですべて実現」
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 主な貢献
|
|||
|
|
1. **実装の完全性**: 1つのIRで5つの実行形態
|
|||
|
|
2. **実用性の証明**: 実際のGUIアプリが動作
|
|||
|
|
3. **統合ツールチェーン**: 外部依存なしで完結
|
|||
|
|
|
|||
|
|
### データ・評価
|
|||
|
|
- 各バックエンドの性能比較
|
|||
|
|
- バイナリサイズ比較
|
|||
|
|
- 起動時間・メモリ使用量
|
|||
|
|
- GUIアプリのレスポンス性
|
|||
|
|
|
|||
|
|
### 投稿先
|
|||
|
|
- **ASPLOS**: システム×言語の交差点
|
|||
|
|
- **OSDI/SOSP**: システム実装の革新性
|
|||
|
|
- **CGO**: コード生成の多様性
|
|||
|
|
|
|||
|
|
## 🌟 論文B: 設計の美しさ（言語設計寄り）
|
|||
|
|
|
|||
|
|
### タイトル案
|
|||
|
|
**"The Simple Lifecycle Philosophy: How Everything-is-Box Enables Minimal IR Design"**
|
|||
|
|
|
|||
|
|
### 日本語仮題
|
|||
|
|
「シンプルライフサイクル哲学：Everything is BoxがもたらすミニマルIR設計」
|
|||
|
|
|
|||
|
|
### ストーリー
|
|||
|
|
```
|
|||
|
|
Everything is Box哲学
|
|||
|
|
↓
|
|||
|
|
統一的オブジェクトモデル
|
|||
|
|
↓
|
|||
|
|
ライフサイクルの単純化
|
|||
|
|
↓
|
|||
|
|
だからMIR13で十分
|
|||
|
|
↓
|
|||
|
|
User Box = Plugin Box = Builtin Box
|
|||
|
|
↓
|
|||
|
|
「美しい対称性」
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 主な貢献
|
|||
|
|
1. **設計哲学**: Box統一による簡潔性
|
|||
|
|
2. **ライフサイクル**: 生成・使用・解放の一貫性
|
|||
|
|
3. **拡張性**: プラグインも同じ仕組み
|
|||
|
|
|
|||
|
|
### データ・評価
|
|||
|
|
- コード行数の削減率（80k→20k）
|
|||
|
|
- APIの一貫性メトリクス
|
|||
|
|
- 学習曲線（初心者の理解速度）
|
|||
|
|
- 拡張性の実証（プラグイン数）
|
|||
|
|
|
|||
|
|
### 投稿先
|
|||
|
|
- **PLDI**: プログラミング言語設計の最高峰
|
|||
|
|
- **OOPSLA**: オブジェクト指向設計
|
|||
|
|
- **Onward!**: 新しい考え方の提案
|
|||
|
|
|
|||
|
|
## 📊 既存のMIR15論文の活用方法
|
|||
|
|
|
|||
|
|
### Paper Aへの統合
|
|||
|
|
```
|
|||
|
|
旧: MIR15の設計詳細
|
|||
|
|
↓
|
|||
|
|
新: MIR13への進化 + 実装の幅広さ
|
|||
|
|
```
|
|||
|
|
- Introduction で MIR15→13 の改善に軽く触れる
|
|||
|
|
- メインは「13命令で何ができるか」の実証
|
|||
|
|
- 評価は実装の多様性に焦点
|
|||
|
|
|
|||
|
|
### Paper Bでの位置づけ
|
|||
|
|
```
|
|||
|
|
旧: 命令削減のテクニック
|
|||
|
|
↓
|
|||
|
|
新: なぜ13で十分なのかの哲学的説明
|
|||
|
|
```
|
|||
|
|
- Box統一があるから13で済む
|
|||
|
|
- ライフサイクルが単純だから13で済む
|
|||
|
|
- 設計思想の一貫性を強調
|
|||
|
|
|
|||
|
|
## 🎨 具体的な分担案
|
|||
|
|
|
|||
|
|
### Paper A の章構成
|
|||
|
|
1. Introduction: 多様な実行形態の課題
|
|||
|
|
2. MIR13 Overview: 13命令の紹介
|
|||
|
|
3. Implementation:
|
|||
|
|
- Interpreter（500行）
|
|||
|
|
- VM（1000行）
|
|||
|
|
- JIT/AOT（Cranelift統合）
|
|||
|
|
- Native EXE（lld内蔵）
|
|||
|
|
- GUI Apps（EguiBox）
|
|||
|
|
4. Evaluation: 性能・サイズ・実用性
|
|||
|
|
5. Related Work: 他言語の実行モデル
|
|||
|
|
6. Conclusion: 統一IRの価値
|
|||
|
|
|
|||
|
|
### Paper B の章構成
|
|||
|
|
1. Introduction: 複雑性の問題
|
|||
|
|
2. Box Philosophy: Everything is Box
|
|||
|
|
3. Lifecycle Design:
|
|||
|
|
- Creation（new/birth）
|
|||
|
|
- Usage（method calls）
|
|||
|
|
- Destruction（自動管理）
|
|||
|
|
4. MIR13 Minimalism: なぜ13で十分か
|
|||
|
|
5. Case Studies:
|
|||
|
|
- User-defined Boxes
|
|||
|
|
- Plugin Boxes
|
|||
|
|
- Builtin Boxes
|
|||
|
|
6. Discussion: シンプルさの価値
|
|||
|
|
7. Conclusion: 新しい設計パラダイム
|
|||
|
|
|
|||
|
|
## 💡 実践的アドバイス
|
|||
|
|
|
|||
|
|
### まず書くべきは Paper A
|
|||
|
|
**理由**：
|
|||
|
|
1. **データが揃っている** - すでに実装済み
|
|||
|
|
2. **インパクトが明確** - 「13命令で全部できる」
|
|||
|
|
3. **デモが強力** - GUIアプリの動画
|
|||
|
|
4. **差別化しやすい** - 他にない実績
|
|||
|
|
|
|||
|
|
### Paper B は少し寝かせる
|
|||
|
|
**理由**：
|
|||
|
|
1. **哲学は熟成が必要** - 使用経験を積む
|
|||
|
|
2. **事例を集める** - コミュニティフィードバック
|
|||
|
|
3. **Paper Aの反応を見る** - 方向性の確認
|
|||
|
|
|
|||
|
|
## 🚀 アクションプラン
|
|||
|
|
|
|||
|
|
### Step 1: MIR13への更新（1週間）
|
|||
|
|
- [ ] 既存のMIR15ドキュメントを13に更新
|
|||
|
|
- [ ] 削減の経緯を簡潔にまとめる
|
|||
|
|
- [ ] ベンチマークを13命令で再実行
|
|||
|
|
|
|||
|
|
### Step 2: Paper A 執筆（3週間）
|
|||
|
|
- [ ] Windows GUIアプリのスクリーンショット/動画
|
|||
|
|
- [ ] 各バックエンドの性能データ収集
|
|||
|
|
- [ ] 実装のLOCカウント
|
|||
|
|
- [ ] 図表の作成
|
|||
|
|
|
|||
|
|
### Step 3: Paper B 準備（同時進行）
|
|||
|
|
- [ ] Box哲学の整理
|
|||
|
|
- [ ] ライフサイクルの図解
|
|||
|
|
- [ ] ユーザー事例の収集
|
|||
|
|
|
|||
|
|
## 🎯 結論
|
|||
|
|
|
|||
|
|
**2本に分けるのは大正解！**
|
|||
|
|
|
|||
|
|
- **Paper A**: 「こんなにできる」（HOW）- システム実装の広さ
|
|||
|
|
- **Paper B**: 「なぜできる」（WHY）- 設計哲学の深さ
|
|||
|
|
|
|||
|
|
論文の世界では、1つの論文に1つの明確なメッセージが重要。2本に分けることで、それぞれのメッセージが明確になり、より多くの読者に届きますにゃ！
|