hakmem/docs/archive/PHASE_6.12.1_COMPLETION_REPORT.md

Phase 6.12.1: Tiny Pool P0最適化 完了レポート

完了日: 2025-10-21 ステータス: ✅ Step 1完了（予想超え）、⚠️ Step 2完了（改善なし）、⏸️ Step 3保留

---

📊 実装サマリ

✅ 完了した実装

Step 1: SlabTag完全削除 (15分)

• SlabTag書き込み削除
• 64B予約削除
• Cookie XOR演算削除
• reserved_blocks計算削除

期待効果: 18,832ns → 9,400ns (2倍) 実測結果: 18,832ns → 7,355ns (2.56倍) ✨ 予想より22%良い！

Step 2: Slab Registry実装 (1時間)

• Hash Table (1024エントリ)
• Linear probing (最大8回)
• slab_base → TinySlab* マッピング
• O(1) average lookup

期待効果: 7,355ns → 1,500ns (5倍) 実測結果: 7,355ns → 10,471ns (string-builder) ❌ 43%悪化

---

📊 ベンチマーク結果

全シナリオ比較

Scenario	Phase 6.12 基本	Step 1	Step 2	vs 基本	vs Step 1
string-builder	7,871 ns	7,355 ns	10,471 ns	+33% ⬆️	+42% ⬆️
token-stream	99 ns	-	98 ns	-1% ⬇️	-
small-objects	6 ns	-	5 ns	-17% ⬇️	-

vs mimalloc:

• string-builder: 10,471 ns vs 18 ns → 582倍遅い
• token-stream: 98 ns vs 9 ns → 11倍遅い
• small-objects: 5 ns vs 3 ns → 1.7倍遅い

---

🔍 Step 2 性能悪化の原因分析

推定原因

1. slab数が少ない環境ではO(N)が有利

   • string-builder: 4サイズクラス × 平均1-2 slab = 8回程度のポインタ比較
   • Registry lookup: hash計算 + 配列アクセス + 2-3回probing
   • → O(N)の方が速い

2. Registry lookupオーバーヘッド

   // hash計算 (ビットシフト＋AND)
   int hash = (slab_base >> 16) & SLAB_REGISTRY_MASK;
   
   // Linear probing (平均2-3回)
   for (int i = 0; i < SLAB_REGISTRY_MAX_PROBE; i++) {
       int idx = (hash + i) & SLAB_REGISTRY_MASK;
       // 16KB配列アクセス → キャッシュミスの可能性
   }
   

3. キャッシュ局所性低下

   • 16KB Registry (1024エントリ × 16B)
   • slab listは連続アクセス（キャッシュフレンドリ）
   • Registry はランダムアクセス（キャッシュミス）

---

💡 ChatGPT Pro (gpt-5) 相談結果

推奨された Plan A

Step 1: SlabTag削除 (15分) → 2倍改善  ✅ 達成 (2.56倍)
Step 2: Slab Registry (1-1.5時間) → 5倍改善  ❌ 失敗 (1.4倍悪化)
Step 3: TLS Freelist (2-2.5時間) → 50-80ns達成  ⏸️ 保留

推奨理由:

• mimalloc: Embedded metadata（セグメント内管理領域）
• jemalloc: Registry（rtreeでO(1)）
• 推奨: Registry（安全性・移植性・デバッグ容易性）

実測結果との乖離

項目	予想	実測	差異
Step 1効果	2倍	2.56倍	+28% 🎉
Step 2効果	5倍	0.7倍	-86% 😱

教訓:

• ✅ 理論と実測は異なる - 必ず測定が必要
• ✅ 環境依存性が高い - slab数・アクセスパターンで結果が変わる
• ❌ ChatGPT予想が外れた - jemalloc/mimallocと異なる条件（slab数少）

---

🎯 技術的洞察

O(N)探索が有利な条件

1. N が小さい (< 10-20)

   • hakmem: 8サイズクラス × 平均1-2 slab = 8-16個
   • jemalloc/mimalloc: 数百～数千slab = O(1)必須

2. 連続アクセスパターン

   • slab listは連続配置
   • CPU cache lineに載る（64B）

3. 単純な比較

   • if (slab->base == slab_base) = 1命令
   • hash計算 + probing = 5-10命令

Registry が有利な条件

1. N が大きい (> 100)

   • mimalloc: 数千slab
   • jemalloc: 数万slab

2. ランダムアクセス

   • free順序がalloc順と無関係

3. マルチスレッド

   • lockフリーRegistry可能

---

📂 実装詳細

Step 1: SlabTag削除

修正ファイル:

• hakmem_tiny.c:48-67 - allocate_new_slab() 簡略化
• hakmem_tiny.c:142-154 - release_slab() 簡略化
• hakmem_tiny.c:150-154 - hak_tiny_init() Cookie削除

削減コード: 約30行

Step 2: Slab Registry

追加ファイル:

• hakmem_tiny.h:62-76 - Registry構造体定義
• hakmem_tiny.c:16 - グローバルRegistry配列
• hakmem_tiny.c:22-92 - Registry操作関数（hash/register/unregister/lookup）
• hakmem_tiny.c:126-134 - allocate_new_slab()登録処理
• hakmem_tiny.c:145-147 - release_slab()削除処理
• hakmem_tiny.c:157-166 - hak_tiny_owner_slab() O(1)化

追加コード: 約80行 メモリ使用: 16KB (1024 entries × 16B)

---

🎯 次のステップ提案

Option A: Step 1で完了 ⭐推奨

理由:

• ✅ 元の実装（7,871ns）より7%速い
• ✅ 実装シンプル（30行削減）
• ✅ メモリ効率良い（Registry不要）
• ❌ mimalloc（18ns）には程遠い（408倍遅い）

結論: Tiny Pool（≤1KB）は L2.5 LargePool（64KB-1MB） より優先度低い

---

Option B: Step 2をrevertしてStep 3へ

理由:

• Registry効果なし
• Step 1の状態でTLS Freelist実装
• TLSが本命（mimalloc/jemalloc の核心技術）

リスク: TLS実装複雑（2-2.5時間）、効果不明

---

Option C: L2.5 LargePool優先

理由:

• mir scenario (+47.8%) の方が深刻
• 64KB-1MB ギャップ埋める方が効果大
• ChatGPT Pro推奨（Phase 6.11）

期待効果: mir 1698ns → <500ns (3倍以上)

---

✅ Phase 6.12.1 完了判定

項目	ステータス
Step 1実装	✅ 完了（予想超え）
Step 2実装	✅ 完了（改善なし）
性能目標	❌ 未達（18ns目標 vs 10,471ns実測）
技術検証	✅ 完了（Registry不要と判明）
最適化戦略	✅ 確定（Step 1で十分）

総合評価: 部分成功 - Step 1は予想超え、Step 2は理論と実測の乖離を学習

---

📌 最終推奨

1. Step 2 (Registry) をrevert ← 性能悪化のため
2. Step 1の状態を維持 ← 7,355ns（元より7%速い）
3. Phase 6.13: L2.5 LargePool へ進む ← より大きな改善期待

理由:

• Tiny Pool最適化の費用対効果が低い（408倍差を埋めるのは現実的でない）
• L2.5 LargePool（64KB-1MB）の方が影響大
• リソースを効果的に配分

---

作成者: Claude + ChatGPT Pro (gpt-5) 作成日: 2025-10-21