Files
hakmem/docs/status/PHASE_6.20_RESULTS_2025_10_24.md

168 lines
6.2 KiB
Markdown
Raw Normal View History

# 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/`