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

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 変更内容:

// 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 変更内容:

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. ページ内ブロック管理のオーバーヘッド

検証方法:

# 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拡大（即効性高）

// Makefile or hakmem_pool.h
#define POOL_TLS_RING_CAP 32  // 16 → 32

期待効果: Ring hit率向上 → syscall頻度減少

B. リフィル処理の最適化

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

C. Learner 有効化での測定

HAKMEM_LEARN=1 HAKMEM_TARGET_HIT_MID=0.70 ./bench

効果: CAP を動的調整 → さらなる Hit 率向上の可能性

D. W_MAX_MID 緩和

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/