# Phase 12: Strategic Pause Results（戦略的休止の成果）

**Date**: 2025-12-14
**Status**: 🔍 **CRITICAL FINDINGS** - System malloc significantly faster than hakmem

---

## Executive Summary

Strategic Pause の調査により、**system malloc (glibc ptmalloc2) が hakmem より +63.7% 速い**という衝撃的な事実が判明しました。

これは hakmem の Phase 6-10 最適化（+24.6%）を上回る差であり、**構造的な課題**が存在する可能性を示唆しています。

---

## 1. Mixed Baseline（Phase 10 後）

### 10-Run Statistics

```
Iterations: 20M, Working Set: 400, Seed: 1
```

| Metric | Value |
|--------|-------|
| **Mean** | **51.76M ops/s** |
| Median | 51.74M ops/s |
| Stdev | 0.53M ops/s |
| CV (Coefficient of Variation) | **1.03%** ✅ |
| Min | 51.00M ops/s |
| Max | 52.67M ops/s |

**Analysis**:
- 非常に安定（CV 1.03%）
- Phase 6-10 の累積効果により 51-52M ops/s の範囲で安定動作

---

## 2. Health Check

**Status**: ✅ **PASS**

| Profile | Throughput | Status |
|---------|-----------|--------|
| MIXED_TINYV3_C7_SAFE | 52.44M ops/s | ✅ PASS |
| C6_HEAVY_LEGACY_POOLV1 | 18.78M ops/s | ✅ PASS |

---

## 3. Perf Stat（Memory-System 指標）

**Test**: 200M iterations, ws=400

| Metric | Value | Notes |
|--------|-------|-------|
| **Throughput** | **52.06M ops/s** | Baseline |
| Cycles | 16,765,096,198 | |
| Instructions | 37,198,361,135 | |
| **IPC** | **2.22** | Instructions per cycle |
| Branches | 9,361,888,532 | |
| **Branch miss rate** | **2.48%** | ✅ Good |
| Cache misses | 1,328,188 | 6.6 misses per 1K ops |
| dTLB load misses | 66,195 | 0.33 per 1K ops |
| Minor faults | 6,938 | |

**Analysis**:
- IPC 2.22 は良好（instruction-level parallelism が効いている）
- Branch miss rate 2.48% は低い（予測精度が高い）
- Cache miss / dTLB miss は少ない（locality が良好）

---

## 4. Allocator Comparison

**Critical Finding**: System malloc が予想外に高速

### 4.1 Throughput Comparison (200M iterations)

| Allocator | Throughput | vs hakmem | RSS (MB) |
|-----------|-----------|-----------|----------|
| **hakmem** (Phase 10) | 52.43M ops/s | Baseline | 33.8 |
| **jemalloc** (LD_PRELOAD) | 48.60M ops/s | **-7.3%** | 35.6 |
| **system malloc** (glibc) | 85.96M ops/s | **+63.9%** 🚨 | N/A |

### 4.2 Verification (20M iterations)

| Allocator | Throughput | Time | vs hakmem |
|-----------|-----------|------|-----------|
| hakmem | 52.88M ops/s | 0.378s | Baseline |
| system malloc | 86.58M ops/s | 0.231s | **+63.7%** 🚨 |

**Analysis**:
- System malloc が **1.64x 速い**（hakmem の Phase 6-10 改善 +24.6% を大きく上回る）
- jemalloc は hakmem より **若干遅い**（-7.3%）
- **Memory footprint は同等**（hakmem 33.8MB vs jemalloc 35.6MB）

---

## 5. Gap Analysis: Why is system malloc so fast?

### 仮説（要検証）

#### 5.1 Header Overhead

**hakmem**:
- すべての allocation に 1-byte header を書き込む（`HAKMEM_TINY_HEADER_CLASSIDX`）
- User pointer = base + 1

**system malloc**:
- Header を user ポインタより前に配置（user pointer = base）
- Write overhead がない可能性

**Impact**: 各 allocation で 1 write → 400M writes (200M alloc+free)

---

#### 5.2 Classification Overhead

**hakmem**:
- Size → Class LUT (`hak_tiny_size_to_class`)
- Class → Route → Handler

**system malloc**:
- Size → Bin（直接 mapping、複雑な分岐なし？）

**Impact**: LUT lookup + routing の固定費

---

#### 5.3 Thread Caching Implementation

**hakmem**:
- TinyUnifiedCache（per-class）
- FastLane で consolidation 済み

**system malloc (ptmalloc2)**:
- tcache（thread-local cache）
- glibc 2.26+ で導入、非常に高速

**Impact**: tcache の実装が hakmem より最適化されている可能性

---

#### 5.4 Metadata Access Pattern

**hakmem**:
- SuperSlab → Slab → Metadata の間接参照
- `tiny_legacy_fallback_free_base()` で metadata 取得

**system malloc**:
- Chunk metadata が連続配置
- Cache locality が良好？

**Impact**: Metadata アクセスの cache miss 率の差

---

#### 5.5 Freelist Management

**hakmem**:
- Freelist を header に埋め込み（1-byte header + next ptr）
- Pop/push で header write

**system malloc**:
- Freelist を chunk 内に配置（user data 領域を再利用）
- Header write なし

**Impact**: Freelist 操作の write overhead

---

### 優先調査項目（ROI 高い順）

1. **Header write overhead** (5.1)
   - 最も直接的な overhead
   - 各 allocation で 1 write = 400M writes
   - **Expected ROI**: +10-20%（header write を削除できれば）

2. **Thread caching implementation** (5.3)
   - system malloc の tcache が非常に高速
   - hakmem の TinyUnifiedCache と比較
   - **Expected ROI**: +20-30%（tcache レベルの最適化）

3. **Metadata access pattern** (5.4)
   - Cache locality の差
   - SuperSlab → Slab → Metadata の間接参照
   - **Expected ROI**: +5-10%（locality 改善）

4. **Classification overhead** (5.2)
   - LUT + routing の固定費
   - **Expected ROI**: +5%（FastLane で既に最適化済み）

5. **Freelist management** (5.5)
   - Header vs chunk 内配置
   - **Expected ROI**: +5%（header write と重複）

---

## 6. Next Phase Direction（Pause 解除の条件）

### 解除ゲート（指示書 Section 5）

以下のいずれか 1 つが満たされたら Pause を解除:

1. ✅ **実ワークロードで明確な bottleneck が特定できた**
   - System malloc との +63.7% gap が特定された
   - 仮説: header overhead / tcache implementation / metadata access

2. ✅ **mimalloc/system との差分が "単一の構造課題" として言語化できた**
   - Header write overhead が最有力候補（400M writes / 200M iters）
   - Thread caching implementation の差（tcache vs TinyUnifiedCache）

3. ⚠️ **Phase 12 の比較で "効く最適化方向" が 1 本に絞れた**
   - 複数の仮説があり、優先順位付けが必要
   - 最優先: Header write elimination（+10-20% 期待）

---

### 推奨: Phase 13 の方向性

#### Option 1: Header Write Elimination（最優先）

**Target**: 1-byte header write の削除

**Strategy**:
- Header を user pointer より前に配置（system malloc パターン）
- または header-less classification（RegionId のみ）

**Expected ROI**: **+10-20%**

**Risk**: ⚠️ MEDIUM - 構造変更が大きい

**Next Action**:
- Header write の実測 overhead を確認（perf record -e cycles:pp）
- Header-less 分類の feasibility 検証（RegionId だけで free path 処理可能か）

---

#### Option 2: Thread Cache Redesign（高 ROI）

**Target**: TinyUnifiedCache を system malloc tcache レベルに最適化

**Strategy**:
- tcache の実装を調査（glibc 2.26+ source）
- TinyUnifiedCache と比較分析
- 差分を特定して適用

**Expected ROI**: **+20-30%**

**Risk**: ⚠️ HIGH - tcache の設計思想を理解する必要

**Next Action**:
- glibc tcache の source code analysis
- TinyUnifiedCache との比較表作成
- Prototype implementation

---

#### Option 3: Metadata Access Optimization（中 ROI）

**Target**: SuperSlab → Slab → Metadata の間接参照を削減

**Strategy**:
- Metadata を連続配置（locality 改善）
- Cache-line alignment 最適化

**Expected ROI**: **+5-10%**

**Risk**: ⚪ LOW - 既存の metadata 構造を改善

**Next Action**:
- Metadata access の cache miss 率を測定（perf stat -e cache-misses）
- Metadata layout の最適化案を設計

---

## 7. Summary & Recommendation

### Key Findings

1. **Phase 10 後の hakmem**: 51.76M ops/s（安定、CV 1.03%）
2. **System malloc**: 86.58M ops/s（**+63.7%** faster 🚨）
3. **Gap 原因仮説**: Header write / tcache implementation / metadata access

### Strategic Decision

**Pause を解除し、Phase 13 へ進む** ✅

**Phase 13 の方向性**: **Header Write Elimination**（Option 1）

**理由**:
1. 最も直接的な overhead（400M writes）
2. 実測可能（perf で検証容易）
3. ROI が明確（+10-20% 期待）

**Alternative**: tcache redesign (Option 2) の調査を並行実施（長期投資として）

---

### Next Actions（Phase 13 準備）

1. **Header write overhead の実測**
   ```sh
   perf record -e cycles:pp -F 9999 -- ./bench_random_mixed_hakmem 200000000 400 1
   perf annotate tiny_region_id_write_header
   ```

2. **Header-less classification の feasibility 検証**
   - RegionId だけで free path が処理可能か確認
   - Header なしで class_idx を復元できるか検証

3. **System malloc tcache の source code analysis**
   - glibc malloc/malloc.c の tcache 実装を読む
   - TinyUnifiedCache との比較表作成

4. **Phase 13 設計書の作成**
   - Header elimination の具体的な実装計画
   - A/B テスト計画
   - Rollback 戦略

---

**Status**: 🔍 **CRITICAL PHASE** - Major performance gap identified
**Date**: 2025-12-14
**Next**: Phase 13 準備（Header Write Elimination）

---

**Analysis**: Claude Code
**Context**: Strategic Pause - Allocator Comparison
**Finding**: System malloc **+63.7% faster** than hakmem (86.58M vs 52.88M ops/s)