# Phase 6.20: 綺麗綺麗ベンチマーク大作戦 - 結果報告
**日付**: 2025-10-24
**対象**: Phase 2 即効改善3施策の統合測定

---

## 📋 実施した改善（Phase 2）

### 1. ⭐⭐⭐ W_MAX_LARGE 1.30 → 1.60
**ファイル**: `hakmem_policy.c:77`
**変更内容**: Large Pool の切り上げ許容倍率を 30% → 60% へ緩和
**狙い**: 32-64KB ギャップの解消
- 例: 40KB 要求 → 64KB クラス使用可能 (1.6倍 ≤ 1.60) ✅
- 旧: 35KB 要求 → 64KB は 1.83倍 > 1.30 → malloc fallback ❌

### 2. ⭐⭐ 初期CAP 4倍化
**ファイル**: `hakmem_policy.c:46-47`
**変更内容**:
```c
// Old: Mid={64,64,64,32,16} Large={8,8,4,2,1}  → 合計 19.5 MB
// New: Mid={256,256,256,128,64} Large={32,32,16,8,4} → 合計 78 MB
```
**狙い**: ヒット率向上（保守的 → パフォーマンス優先）
**トレードオフ**: メモリフットプリント 4倍増加

### 3. ⭐⭐ DYN1=6KB デフォルト有効化
**ファイル**: `hakmem_policy.c:53-54`
**変更内容**:
```c
pol->mid_dyn1_bytes = 6144;  // 6KB 動的クラス有効化
pol->mid_cap_dyn1 = 64;      // CAP = 64 pages
```
**狙い**: 4-8KB ギャップの解消
- 5-7KB 要求を専用クラスでカバー（8KB への切り上げを回避）

---

## 📊 ベンチマーク結果（Larson, 3秒, mimalloc-bench）

### Tiny (8-64B) - TinyPool領域
| Threads | system     | mimalloc   | hakmem     | vs mimalloc |
|---------|-----------|-----------|-----------|-------------|
| 1T      | 39.6 M/s  | 36.3 M/s  | 22.7 M/s  | **57%** ❌   |
| 4T      | 86.9 M/s  | 42.8 M/s  | 51.3 M/s  | **120%** ✅  |

**分析**:
- 1T: 単一スレッドでは mimalloc に劣後（TinyPool の最適化不足）
- 4T: マルチスレッドで mimalloc を上回る（TLS Ring Buffer の効果）

### Mid (2-32KB) - L2 Mid Pool領域 ⚠️
| Threads | system     | mimalloc   | hakmem     | vs mimalloc |
|---------|-----------|-----------|-----------|-------------|
| 1T      | 6.0 M/s   | 15.1 M/s  | 4.3 M/s   | **29%** ❌   |
| 4T      | 11.8 M/s  | 15.1 M/s  | 9.6 M/s   | **64%** ❌   |

**分析**:
- **Phase 2 改善にもかかわらず低パフォーマンス**
- CAP 4倍化・DYN1有効化の効果が見られない
- 考えられる原因:
  1. リフィル処理のオーバーヘッド（`refill_freelist` コスト大）
  2. TLS Ring Buffer のサイズ不足（`POOL_TLS_RING_CAP=16` は小さい？）
  3. ロック競合（`pthread_mutex` vs mimalloc の lock-free）
  4. ヒット率以外のボトルネック（キャッシュミス、メモリレイアウト）

### Large (64KB-1MB) - L2.5 Large Pool領域
| Threads | system     | mimalloc   | hakmem     |
|---------|-----------|-----------|-----------|
| 1T      | 695 K/s   | (timeout)  | (未実行)   |

**ステータス**: mimalloc ベンチマークがタイムアウト → Large 以降未測定
**次回**: W_MAX_LARGE=1.60 の効果検証のため Large のみ再測定推奨

---

## 🔍 問題点と次のアクション

### 1. Mid Pool パフォーマンス問題 🔴 **Critical**
**現状**: mimalloc の 29% (1T) / 64% (4T) しか出ていない
**原因仮説**:
- A. リフィル処理が重い（syscall/mmap 頻度高い？）
- B. TLS Ring が小さすぎる（16 → 32/64 へ拡大？）
- C. ロック粒度が粗い（クラス別ロック → さらに細分化？）
- D. ページ内ブロック管理のオーバーヘッド

**検証方法**:
```bash
# 1. TLS Ring拡大の効果測定
make clean && make CFLAGS="-DPOOL_TLS_RING_CAP=32"
RUNTIME=3 THREADS=1,4 ./scripts/run_bench_suite.sh

# 2. プロファイリング（どこで時間を消費？）
perf record -g LD_PRELOAD=./libhakmem.so ./mimalloc-bench/bench/larson/larson 3 2048 32768 10000 1 12345 4
perf report

# 3. リフィル頻度測定
HAKMEM_DEBUG=1 LD_PRELOAD=./libhakmem.so <bench> 2>&1 | grep -i refill
```

### 2. Large Pool 測定未完了
**原因**: mimalloc が Large ベンチマークでタイムアウト（環境問題？）
**対策**: Large のみ単独測定（`BENCH_TIMEOUT=30` 延長）

### 3. 比較対象の追加
現状は「改善後のみ」測定 → **改善前との比較データがない**
**提案**: Git で Phase 2 変更を revert して「改善前ベースライン」測定

---

## 📈 改善提案（Phase 2.1 候補）

### A. TLS Ring Buffer拡大（即効性高）
```c
// Makefile or hakmem_pool.h
#define POOL_TLS_RING_CAP 32  // 16 → 32
```
**期待効果**: Ring hit率向上 → syscall頻度減少

### B. リフィル処理の最適化
```c
// refill_freelist() の改善案:
// 1. batch mmap (複数ページを一度に確保)
// 2. prefault (mmap後即座にtouch → TLBミス回避)
// 3. background refill (閾値で非同期リフィル開始)
```

### C. Learner 有効化での測定
```bash
HAKMEM_LEARN=1 HAKMEM_TARGET_HIT_MID=0.70 ./bench
```
**効果**: CAP を動的調整 → さらなる Hit 率向上の可能性

### D. W_MAX_MID 緩和
```c
pol->w_max_mid = 1.60f;  // 1.40 → 1.60
```
**トレードオフ**: 内部断片化 ↑、ヒット率 ↑

---

## 📝 まとめ

### ✅ 成功したこと
1. **ドキュメント整備完了** - 各実装ファイルにヘッダコメント追加、INDEX.md 更新
2. **Phase 2 改善を実装・ビルド成功** - W_MAX_LARGE 緩和、CAP 4倍化、DYN1 有効化
3. **ベンチマーク基盤確立** - 測定スクリプト整備、結果保存体制

### ❌ 未達成・問題点
1. **Mid Pool が mimalloc に大幅劣後** - 根本原因の特定が必要
2. **Large Pool の測定未完了** - W_MAX_LARGE 効果が不明
3. **改善前との比較データなし** - どれだけ改善したか不明

### 🎯 次のステップ
1. **Phase 2.1: Mid Pool パフォーマンス調査**
   - perf プロファイリング
   - TLS Ring 拡大実験
   - リフィル頻度測定
2. **Large Pool 単独測定** - W_MAX_LARGE=1.60 効果検証
3. **改善前ベースライン測定** - git revert → 測定 → 比較表作成

---

## 付録: 環境情報
- **OS**: Linux 5.15.167.4-microsoft-standard-WSL2
- **Compiler**: gcc -O2
- **Benchmark**: mimalloc-bench/larson (3秒)
- **Build**: libhakmem.so (LD_PRELOAD方式)
- **保存場所**: `docs/benchmarks/20251024_082117_SUITE/`