hakmem/PHASE19_AB_TEST_RESULTS.md

# Phase 19: Frontend Layer A/B Test Results

## テスト環境
- **ベンチマーク**: `bench_random_mixed_hakmem 500000 4096 42`
- **ワークロード**: ランダム割り当て 16-1040バイト、50万イテレーション
- **測定対象**: C2 (33-64B), C3 (65-128B) のヒット率と性能

---

## A/Bテスト結果サマリー

| 設定 | Throughput | vs Baseline | C2 ヒット率 | C3 ヒット率 | 評価 |
|------|-----------|-------------|-------------|-------------|------|
| **Baseline** (UH + HV2) | **10.1M ops/s** | - | UH=11.7%, HV2=88.3% | UH=0.2%, HV2=99.8% | ベースライン |
| **HeapV2のみ** (UH無効) | **11.4M ops/s** | **+12.9%** ⭐ | HV2=99.3%, SLL=0.7% | HV2=97.3%, SLL=2.7% | **最速！** |
| **UltraHotのみ** (HV2無効) | **6.6M ops/s** | **-34.4%** ❌ | UH=96.4%, SLL=3.6% | UH=5.8%, SLL=94.2% | 大幅劣化 |

---

## 詳細分析

### テスト1: Baseline（両方ON - 現状）

```
Throughput: 10.1M ops/s

Class C2 (33-64B):
  UltraHot:  455 hits (11.7%)
  HeapV2:   3450 hits (88.3%)
  Total:    3905 allocations

Class C3 (65-128B):
  UltraHot:   13 hits (0.2%)
  HeapV2:   7585 hits (99.8%)
  Total:    7598 allocations
```

**観察**:
- HeapV2 が主力として機能（88-99% ヒット率）
- UltraHot の貢献は微小（0.2-11.7%）
- 2層のチェックによる分岐オーバーヘッド発生

---

### テスト2: HeapV2のみ（UltraHot無効） ⭐ 推奨設定

```
ENV: HAKMEM_TINY_FRONT_DISABLE_ULTRAHOT=1
Throughput: 11.4M ops/s (+12.9% vs Baseline)

Class C2 (33-64B):
  HeapV2:   3866 hits (99.3%)
  TLS SLL:    29 hits (0.7%)  ← HeapV2 miss 時の fallback
  Total:    3895 allocations

Class C3 (65-128B):
  HeapV2:   7596 hits (97.3%)
  TLS SLL:   208 hits (2.7%)  ← HeapV2 miss 時の fallback
  Total:    7804 allocations
```

**重要な発見**:
- **UltraHot 削除で性能向上** (+12.9%)
- HeapV2 単独でも 97-99% の高ヒット率を維持
- UltraHot の分岐チェックがオーバーヘッドになっていた
- SLL が HeapV2 miss を拾って補完（0.7-2.7%）

**分析**:
- **分岐予測ミスのコスト** > UltraHot のヒット率向上効果
- UltraHot チェック: `if (ultra_hot_enabled() && front_prune_ultrahot_enabled())`
  - 毎回評価されるが、11.7% しかヒットしない
  - 88.3% のケースで無駄な分岐チェック
- HeapV2 単独の方が **予測可能性が高い** → CPU 分岐予測器に優しい

---

### テスト3: UltraHotのみ（HeapV2無効） ❌ 非推奨

```
ENV: HAKMEM_TINY_FRONT_DISABLE_HEAPV2=1
Throughput: 6.6M ops/s (-34.4% vs Baseline)

Class C2 (33-64B):
  UltraHot: 3765 hits (96.4%)
  TLS SLL:   141 hits (3.6%)
  Total:    3906 allocations

Class C3 (65-128B):
  UltraHot:  248 hits (5.8%)  ← C3 サイズに対応できていない！
  TLS SLL:  4037 hits (94.2%) ← ほぼ全てが SLL に漏れる
  Total:    4285 allocations
```

**問題点**:
- **C3 でヒット率壊滅** (5.8%) → 94.2% が SLL に漏れる
- UltraHot の magazine サイズが C3 に不十分
- SLL アクセスは遅い（linked list traversal）
- 結果: -34.4% の大幅性能劣化

**UltraHot の設計限界**:
- C2: 4スロット magazine → 96.4% ヒット率（まずまず）
- C3: 4スロット magazine → 5.8% ヒット率（不十分）
- C3 の高需要に対応できない magazine 容量

---

## 結論と推奨事項

### 🎯 推奨設定: HeapV2のみ（UltraHot無効）

```bash
export HAKMEM_TINY_FRONT_DISABLE_ULTRAHOT=1
./bench_random_mixed_hakmem
```

**理由**:
1. **性能向上** +12.9% (10.1M → 11.4M ops/s)
2. **コード簡素化** - 1層削減で分岐予測改善
3. **高ヒット率維持** - HeapV2 単独で 97-99% 達成
4. **SLL fallback** - HeapV2 miss 時は SLL が補完（0.7-2.7%）

### ❌ UltraHot 削除の根拠

**定量的根拠**:
- ヒット率貢献: 0.2-11.7%（微小）
- 分岐オーバーヘッド: 毎回評価（100% のケース）
- 性能影響: 削除で +12.9% 改善

**定性的根拠**:
- 設計の複雑性（Borrowing Design）
- HeapV2 との機能重複（C2/C3 両方対応）
- メンテナンスコスト > 効果

### ✅ HeapV2 保持の根拠

**定量的根拠**:
- ヒット率: 88-99%（主力）
- 性能影響: 無効化で -34.4% 劣化
- SLL fallback: miss 時も 0.7-2.7% で収まる

**定性的根拠**:
- シンプルな magazine 設計
- C2/C3 両方で高効率
- UltraHot より容量大（ヒット率高）

---

## 次のステップ

### Phase 19-5: UltraHot 削除パッチ作成

1. **コード削除**:
   - `core/front/tiny_ultra_hot.h/c` 削除
   - `tiny_alloc_fast.inc.h` から UltraHot セクション削除
   - ENV 変数 `HAKMEM_TINY_ULTRA_HOT` 削除

2. **ビルドシステム更新**:
   - Makefile から UltraHot 関連削除
   - build.sh 更新

3. **ドキュメント更新**:
   - CLAUDE.md に Phase 19 結果追記
   - CURRENT_TASK.md 更新

### Phase 19-6: 回帰テスト

1. **性能検証**:
   - `bench_random_mixed_hakmem` - 目標: 11M+ ops/s
   - `larson_hakmem` - 安定性確認
   - `bench_fixed_size_hakmem` - 各サイズクラス確認

2. **機能検証**:
   - HeapV2 単独で全サイズクラス対応確認
   - SLL fallback 動作確認
   - Prewarm 動作確認

---

## ChatGPT 先生の戦略検証 ✅

**Phase 19 戦略**:
1. ✅ **観測** (Box FrontMetrics) → HeapV2 88-99%, UltraHot 0.2-11.7%
2. ✅ **診断** (Box FrontPrune A/B) → UltraHot 削除で +12.9%
3. ⏭️ **治療** (UltraHot 削除実装) → 次フェーズ

**結果**:
- 「観測 → 診断 → 治療」のアプローチが **完璧に機能** 🎉
- 直感に反する発見（UltraHot が阻害要因）を **データで証明**
- A/B テストで **リスクなし確認** してから削除へ

---

## ファイル変更履歴

**Phase 19-1 & 19-2** (Metrics):
- `core/box/front_metrics_box.h` - NEW
- `core/box/front_metrics_box.c` - NEW
- `core/tiny_alloc_fast.inc.h` - メトリクス収集追加

**Phase 19-3** (FrontPrune):
- `core/box/front_metrics_box.h` - ENV切り替え関数追加
- `core/tiny_alloc_fast.inc.h` - ENV条件分岐追加

**Phase 19-4** (A/B Test):
- このレポート: `PHASE19_AB_TEST_RESULTS.md`
- 分析: `PHASE19_FRONTEND_METRICS_FINDINGS.md`

---

## 付録: 性能比較グラフ（テキスト）

```
Throughput (M ops/s):

Baseline    ████████████████████ 10.1
HeapV2のみ  ██████████████████████ 11.4 (+12.9%) ⭐
UltraHotのみ █████████████ 6.6 (-34.4%) ❌

             0    2    4    6    8   10   12 (M ops/s)
```

```
C2 Hit Rate (33-64B):

Baseline:    [UH 11.7%][======= HV2 88.3% =======]
HeapV2のみ:  [============ HV2 99.3% ===========][SLL 0.7%]
UltraHotのみ:[========== UH 96.4% ==========][SLL 3.6%]
```

```
C3 Hit Rate (65-128B):

Baseline:    [UH 0.2%][========== HV2 99.8% ==========]
HeapV2のみ:  [========= HV2 97.3% =========][SLL 2.7%]
UltraHotのみ:[UH 5.8%][========== SLL 94.2% ==========]  ← 壊滅！
```

---

**まとめ**: ChatGPT 先生の推奨通り、**Box FrontMetrics → Box FrontPrune** で科学的にフロント層を分析した結果、**UltraHot削除で +12.9% 性能向上** という明確な結論が得られたにゃ！🎉