hakmem/archive/analysis/NEXT_STEP_ANALYSIS.md

# 次のステップ分析：mimalloc vs ChatGPT Pro 案 (2025-11-01)

## 📊 現状の課題

### ベンチマーク結果（P0実装後）

| ベンチマーク       | hakx    | mimalloc | 差分      | 評価 |
|--------------|---------|----------|---------|------|
| **Tiny Hot 32B** | 215 M   | 182 M    | +18%    | ✅ 勝利 |
| **Random Mixed** | 22.5 M  | 25.1 M   | -10%    | ⚠️ 負け |
| **mid_large_mt** | 46-47 M | 122 M    | **-62%** | ❌❌ 惨敗 |

### 問題の優先度

1. **🚨 最優先**: mid_large_mt (8-32KB, MT) で 2.6倍遅い
2. **⚠️ 中優先**: Random Mixed (8B-128B混合) で 10%遅い
3. **✅ 良好**: Tiny Hot で 18%速い（P0成功）

---

## 🔍 根本原因分析

### mid_large_mt が遅い理由

**ベンチマーク内容**:
- サイズ: 8KB, 16KB, 32KB
- スレッド: 2スレッド（各独立ワーキングセット）
- パターン: ランダム alloc/free（25%確率でfree）

**hakmem の処理フロー**:
```
8-32KB → L2 Hybrid Pool (hakmem_pool.c)
         ↓
     Strategy選択（ELO学習）
         ↓
     Globalロックあり？
```

**mimalloc の処理フロー**:
```
8-32KB → per-thread segment (lock-free)
         ↓
     TLSから直接取得（ロック不要）
```

### 差の本質

| 設計 | mimalloc | hakmem |
|------|----------|--------|
| **MT戦略** | per-thread heap | 共有Pool + ロック |
| **思想** | 静的最適化 | 動的学習・適応 |
| **8-32KB** | 完全TLS | 戦略ベース（ロックあり？） |
| **利点** | MT性能最高 | ワークロード適応 |
| **欠点** | 固定戦略 | ロック競合 |

---

## 🎯 2つのアプローチ

### Approach A: mimalloc 方式（静的最適化）

#### 概要
per-thread heap を導入し、MT時のロック競合を完全排除

#### 実装案
```c
// 8-32KB: per-thread segment（mimalloc風）
__thread ThreadSegment g_mid_segments[NUM_SIZE_CLASSES];

void* mid_alloc_mt(size_t size) {
    int class_idx = size_to_class(size);
    ThreadSegment* seg = &g_mid_segments[class_idx];

    // TLSから直接取得（ロックフリー）
    void* p = segment_alloc(seg, size);
    if (likely(p)) return p;

    // Refill: 中央からバッチ取得（稀）
    segment_refill(seg, class_idx);
    return segment_alloc(seg, size);
}
```

#### 利点 ✅
- ✅ MT性能最高（mimalloc並み）
- ✅ ロック競合ゼロ
- ✅ 実装がシンプル

#### 欠点 ❌
- ❌ **学習層と衝突**：ELO戦略選択が無意味に
- ❌ ワークロード適応不可
- ❌ メモリオーバーヘッド（スレッド数 × サイズクラス）

---

### Approach B: ChatGPT Pro 方式（適応的最適化）

#### 概要
学習層を保持しつつ、ロック競合を最小化

#### ChatGPT Pro 推奨（P0-P6）

**P0: 完全バッチ化** ✅ **完了（+5.16%）**

**P1: Quick補充の粒度可変化**
- 現状: 固定2個
- 改善: `g_frontend_fill_target` による動的調整
- 期待: +1-2%

**P2: Remote Freeしきい値最適化**
- 現状: 全クラス共通
- 改善: クラス別しきい値（ホットクラス↑、コールド↓）
- 期待: MT性能 +2-3%

**P3: Bundle ノード（Transfer Cache）**
- 現状: Treiber Stack（単体ポインタ）
- 改善: バンドルノード（32/64個を1ノードに）
- 期待: MT性能 +5-10%

**P4: 二段ビットマップ最適化**
- 現状: 線形スキャン
- 改善: 語レベルヒント + ctz
- 期待: +2-3%

**P5: UCB1/ヒルクライム自動調整**
- 現状: 固定パラメータ
- 改善: 自動チューニング
- 期待: +3-5%（長期）

**P6: NUMA/CPUシャーディング**
- 現状: グローバルロック
- 改善: NUMA/CPU単位で分割
- 期待: MT性能 +10-20%

#### 利点 ✅
- ✅ **学習層と協調**：ELO戦略が活きる
- ✅ ワークロード適応可能
- ✅ 段階的実装（リスク分散）

#### 欠点 ❌
- ❌ 実装が複雑（P3, P6）
- ❌ 短期効果は限定的（P1-P2で+3-5%程度）
- ❌ mimalloc並みには届かない可能性

---

## 🤔 学習層との相性分析

### hakmem の学習層（ELO）とは

**役割**:
```c
// 複数の戦略から最適を選択
Strategy strategies[] = {
    {size: 512KB, policy: MADV_FREE},
    {size: 1MB,   policy: KEEP_MAPPED},
    {size: 2MB,   policy: BATCH_FREE},
    // ...
};

// ELOレーティングで評価
int best = elo_select_strategy(size);
apply_strategy(best, ptr);
```

**学習対象**:
- サイズごとの free policy（MADV_FREE vs KEEP vs BATCH）
- BigCache ヒット率
- リージョンサイズの最適化

### mimalloc 方式との衝突点

#### 衝突する部分 ❌

**1. 8-32KB の戦略選択**
```
mimalloc方式: per-thread heap → 常に同じパス
hakmem学習:   戦略A/B/C → 選択の余地なし
結果: 学習が無駄
```

**2. Remote Free戦略**
```
mimalloc方式: 各スレッドが独立管理
hakmem学習:   Remote Freeのバッチサイズを学習
結果: 衝突（各スレッド独立では学習不要）
```

#### 衝突しない部分 ✅

**1. 64KB以上（L2.5, Whale）**
```
mimalloc方式: 8-32KBのみ
hakmem学習:   64KB以上は既存のまま
結果: 学習層は活きる
```

**2. Tiny Pool（≤1KB）**
```
mimalloc方式: 影響なし
hakmem学習:   Tiny は別設計
結果: P0の成果そのまま
```

### ChatGPT Pro 方式との協調

#### 協調する部分 ✅

**P3: Bundle ノード**
```c
// 中央Poolは戦略ベースのまま
Strategy* s = elo_select_strategy(size);
void* bundle = pool_alloc_bundle(s, 64);  // 戦略に従う

// TLS側はバンドル単位で受け取り
thread_cache_refill(bundle);
```
→ **学習層が活きる**

**P6: NUMA/CPUシャーディング**
```c
// NUMA node単位で戦略を学習
int node = numa_node_of_cpu(cpu);
Strategy* s = elo_select_strategy_numa(node, size);
```
→ **学習がより高精度に**

---

## 📊 効果予測

### Approach A: mimalloc 方式

| ベンチマーク | 現状 | 予測 | 改善 |
|------------|------|------|------|
| mid_large_mt | 46 M | **120 M** | +161% ✅✅ |
| Random Mixed | 22.5 M | 24 M | +7% ✅ |
| Tiny Hot | 215 M | 215 M | 0% |

**総合**: MT性能は大幅改善、**but 学習層が死ぬ**

### Approach B: ChatGPT Pro P1-P6

| ベンチマーク | 現状 | P1-P2後 | P3後 | P6後 |
|------------|------|---------|------|------|
| mid_large_mt | 46 M | 49 M | 55 M | **70-80 M** |
| Random Mixed | 22.5 M | 23.5 M | 24.5 M | 25 M |
| Tiny Hot | 215 M | 220 M | 220 M | 220 M |

**総合**: 段階的改善、学習層は活きる、**but mimalloc には届かない**

---

## 💡 ハイブリッド案（推奨）

### 設計思想

**「8-32KB だけ mimalloc 風、それ以外は学習」**

```c
void* malloc(size_t size) {
    if (size <= 1KB) {
        // Tiny Pool（P0完了、学習不要）
        return tiny_alloc(size);
    }

    if (size <= 32KB) {
        // Mid Range: mimalloc風 per-thread segment
        // 理由: MT性能が最優先、学習の余地少ない
        return mid_mt_alloc(size);
    }

    // 64KB以上: 学習ベース（ELO戦略選択）
    // 理由: ワークロード依存、学習が効く
    Strategy* s = elo_select_strategy(size);
    return large_alloc(s, size);
}
```

### 利点 ✅

1. **MT性能**: 8-32KB は mimalloc 並み
2. **学習層**: 64KB以上で活きる
3. **Tiny**: P0の成果そのまま
4. **段階的**: 小さく始められる

### 実装優先度

**Phase 1: Mid Range MT最適化**（1週間）
- 8-32KB: per-thread segment 実装
- 目標: mid_large_mt で 100+ M ops/s

**Phase 2: Large学習強化**（1-2週間）
- 64KB以上: ChatGPT Pro P5（UCB1自動調整）
- 目標: ワークロード適応精度向上

**Phase 3: Bundle + NUMA**（2-3週間）
- ChatGPT Pro P3, P6 実装
- 目標: 全体的なMT性能向上

---

## 🎯 推奨アクション

### 短期（今週～来週）

**1. ドキュメント更新** ✅ 完了
- NEXT_STEP_ANALYSIS.md

**2. Mid Range MT最適化（mimalloc風）**
```c
// 新規ファイル: core/hakmem_mid_mt.c
// 8-32KB専用 per-thread segment
```

**期待効果**:
- mid_large_mt: 46M → **100-120M** (+120-160%)
- 学習層への影響: 64KB以上は無影響

### 中期（2-3週間）

**3. ChatGPT Pro P1-P2 実装**
- Quick補充粒度可変化
- Remote Freeしきい値最適化

**期待効果**:
- Random Mixed: 22.5M → 24M (+7%)
- Tiny Hot: 215M → 220M (+2%)

### 長期（1-2ヶ月）

**4. ChatGPT Pro P3, P5, P6**
- Bundle ノード
- UCB1自動調整
- NUMA/CPUシャーディング

**期待効果**:
- 全体的なMT性能 +10-20%
- ワークロード適応精度向上

---

## 📋 決定事項（提案）

### 採用: ハイブリッド案

**理由**:
1. ✅ MT性能（mimalloc並み）
2. ✅ 学習層保持（64KB以上）
3. ✅ 段階的実装（リスク低）
4. ✅ hakmem の設計思想を尊重

### 非採用: 純粋mimalloc方式

**理由**:
1. ❌ 学習層が死ぬ
2. ❌ hakmem の差別化ポイント喪失
3. ❌ ワークロード適応不可

### 非採用: 純粋ChatGPT Pro方式

**理由**:
1. ❌ MT性能がmimallocに届かない
2. ❌ 実装コストに対して効果が限定的
3. ❌ 8-32KBでの学習効果は低い

---

## 🤔 客観的評価

### hakmem の設計思想

**コアバリュー**:
- ワークロード適応（ELO学習）
- サイト別最適化
- 動的戦略選択

**トレードオフ**:
- 学習層のオーバーヘッド
- MT性能（ロック競合）

### mimalloc の設計思想

**コアバリュー**:
- 静的最適化（学習なし）
- per-thread heap（完全TLS）
- MT性能最優先

**トレードオフ**:
- ワークロード固定
- メモリオーバーヘッド

### ハイブリッド案の位置づけ

```
               MT性能
                 ↑
      mimalloc  |
         ●      |
         |      |  ← ハイブリッド案（目標）
         |   ●  |     ・8-32KB: mimalloc風
         |      |     ・64KB+: 学習ベース
         |      |
    hakmem(現状)|
         ●      |
         |      |
         +──────┼─────→ 学習・適応性
                0
```

**結論**: 両者の良いとこ取り

---

## 📚 参考資料

- ChatGPT Pro UltraThink Response: `docs/analysis/CHATGPT_PRO_ULTRATHINK_RESPONSE.md`
- P0 Success Report: `P0_SUCCESS_REPORT.md`
- mimalloc paper: https://www.microsoft.com/en-us/research/publication/mimalloc-free-list-sharding-in-action/
- hakmem ELO learning: `core/hakmem_elo.c`
- L2 Hybrid Pool: `core/hakmem_pool.c`

---

**日時**: 2025-11-01
**推奨**: ハイブリッド案（8-32KB mimalloc風 + 64KB以上学習ベース）
**次のステップ**: Mid Range MT最適化の実装設計