1397 lines
68 KiB
Markdown
1397 lines
68 KiB
Markdown
## HAKMEM 状況メモ（コンパクト版, 2025-12-11）
|
||
|
||
このファイルは「いま何を基準に A/B するか」「どの箱が本線か」だけを短くまとめたものです。
|
||
過去フェーズの詳細なログは `CURRENT_TASK_ARCHIVE_20251210.md` と各 `docs/analysis/*` に残しています。
|
||
|
||
---
|
||
|
||
## Phase ULTRA 総括（2025-12-11）
|
||
|
||
### Tiny/ULTRA 層は「完成世代」として固定化
|
||
|
||
**最終成果**: Mixed 16–1024B = **43.9M ops/s**（baseline 30.6M → +43.5%）
|
||
|
||
**現在の本線構成**:
|
||
- C4–C7 ULTRA（寄生型 TLS cache）で legacy 49% → 4.8% に削減
|
||
- v3 backend（alloc_current_hit=100%, free_retire=0.1%）で堅牢に
|
||
- Dispatcher/gate snapshot で ENV/route を hot path から排除
|
||
- C7 ULTRA refill を division → bit shift で +11%
|
||
|
||
**設計的な完成度**:
|
||
- Small object（C2–C7） = ULTRA 最適化済み（fast path も slow path も）
|
||
- v3 backend = ロジック部分は完全最適化（残り 5% は header write/memcpy 等の内部コスト）
|
||
- 研究箱（v4/v5/v6）は OFF で標準プロファイルに影響なし
|
||
|
||
**今後の大きい変更は別ライン**:
|
||
1. **Headerless/v6 系**: header out-of-band 化で alloc 毎の write 削減（1-2%）
|
||
2. **mid/pool v3**: C6-heavy を 10M → 20–25M に改善する新設計
|
||
3. 上記は Tiny/ULTRA 層に影響を与えない独立ラインで検討予定
|
||
|
||
**詳細**: `docs/analysis/PERF_EXEC_SUMMARY_ULTRA_PHASE_20251211.md` 参照
|
||
|
||
---
|
||
|
||
## Phase V6-HDR-0: C6-only headerless core 設計確定（進行中）
|
||
|
||
### 目的
|
||
|
||
Tiny/ULTRA 完成を受け、C6-only で **headerless 設計** を実証する最小コア（v6）を構築する。
|
||
C7 ULTRA は既に完成・凍結されており、v6 は C6 専用の研究ラインとして独立させる。
|
||
|
||
### 4層 Box Theory（設計原則）
|
||
|
||
```
|
||
┌──────────────────────────────────────────────────────────────┐
|
||
│ L0: ULTRA lanes (TinyC7UltraBox 等) │
|
||
│ - C7 ULTRA は frozen / v6 とは独立 │
|
||
│ - v6 ULTRA（将来）は C6-only で別途設計 │
|
||
├──────────────────────────────────────────────────────────────┤
|
||
│ L1: TLS Box (SmallTlsLaneV6 / SmallHeapCtxV6) │
|
||
│ - per-class TLS freelist + current page ptr │
|
||
│ - 責務: fast alloc/free（header 書き込みなし） │
|
||
├──────────────────────────────────────────────────────────────┤
|
||
│ L2: Segment / ColdIface (SmallSegmentV6 / ColdIfaceV6) │
|
||
│ - page_meta[], segment base/end 管理 │
|
||
│ - refill / retire の page lifecycle 管理 │
|
||
├──────────────────────────────────────────────────────────────┤
|
||
│ L3: Policy / RegionIdBox / Stats │
|
||
│ - RegionIdBox: ptr→(region_kind, region_id, page_meta) │
|
||
│ - PageStatsV6: page lifetime summary（占有率、retire 頻度）│
|
||
│ - Policy: GC / compaction 決定（将来） │
|
||
└──────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 設計ポイント
|
||
|
||
1. **C7 ULTRA は独立 frozen 箱**
|
||
- TinyC7UltraBox / C7UltraSegmentBox はそのまま維持
|
||
- v6 は C7 に触らない（C6-only）
|
||
|
||
2. **v6 は C6-only small core（headerless 研究）**
|
||
- alloc 時に header byte を書かない（out-of-band metadata）
|
||
- free 時は RegionIdBox で ptr 分類 → page_meta へ直接アクセス
|
||
|
||
3. **ptr 分類は RegionIdBox に集約**
|
||
- 従来: classify_ptr / hak_super_lookup / ss_fast_lookup など分散
|
||
- v6: `region_id_lookup_v6(ptr)` で (region_kind, region_id, page_meta*) を返す
|
||
- region_kind: SMALL_V6 / POOL / LARGE / UNKNOWN
|
||
|
||
4. **Stats/Learning は page lifetime summary のみを L3 に渡す**
|
||
- L1/L2 で個別 block の stats は取らない
|
||
- page retire 時に summary (total_allocs, avg_lifetime_ns) を L3 へ push
|
||
|
||
### 実装タスク（Phase V6-HDR-0: 完了）
|
||
|
||
| No | タスク | 状態 |
|
||
|----|--------|------|
|
||
| 1-1 | CURRENT_TASK.md 整理（本セクション追加）| ✅ |
|
||
| 1-2 | SMALLOBJECT_CORE_V6_DESIGN.md 新規作成 | ✅ |
|
||
| 1-3 | REGIONID_V6_DESIGN.md 新規作成 | ✅ |
|
||
| 2-1 | SmallTlsLaneV6 / SmallHeapCtxV6 型スケルトン | ✅ |
|
||
| 2-2 | v6 TLS API (small_v6_tls_alloc/free) | ✅ |
|
||
| 3-1 | RegionIdBox 型と lookup API スケルトン | ✅ |
|
||
| 3-2 | OBSERVE モード（v6 free 入口にログ）| ✅ |
|
||
| 4-1 | PageStatsV6 箱（未接続）| ✅ |
|
||
| 5-1 | AGENTS.md に v6 研究箱ルール追記 | ✅ |
|
||
| 5-2 | サニティベンチ（Mixed / C6-heavy）| ✅ |
|
||
|
||
### ENV
|
||
|
||
- `HAKMEM_SMALL_CORE_V6_ENABLED=0` (default OFF)
|
||
- `HAKMEM_REGION_ID_V6_OBSERVE=0` (default OFF, ログ出力用)
|
||
- `HAKMEM_PAGE_STATS_V6_ENABLED=0` (default OFF)
|
||
|
||
---
|
||
|
||
## Phase V6-HDR-2: C6 headerless free 実験 ON（進行中）
|
||
|
||
### 目的
|
||
|
||
V6-HDR-0/1 で作成した箱と RegionId の配線を使い、C6 だけ headerless free を実際に通電する。
|
||
挙動は C6-heavy 専用プロファイルでだけ変える前提。
|
||
|
||
### 実装タスク
|
||
|
||
| No | タスク | 状態 |
|
||
|----|--------|------|
|
||
| 1 | smallobject_v6_env_box.h 作成（ENV ゲート管理）| ✅ |
|
||
| 2 | front から v6 free ルート接続 | ✅ |
|
||
| 3 | small_v6_headerless_free 本実装 | ✅ |
|
||
| 4 | front から v6 alloc ルート接続 | ✅ |
|
||
| 5 | small_v6_headerless_alloc 本実装 | ✅ |
|
||
| 6 | header 書き込み 1回だけ化確認 | ✅ |
|
||
| 7 | ドキュメント更新 | ✅ |
|
||
| 8 | C6-heavy ベンチテスト | ✅ |
|
||
|
||
### 実装詳細
|
||
|
||
1. **smallobject_v6_env_box.h** (新規)
|
||
- `small_heap_v6_headerless_enabled()`: ENV `HAKMEM_SMALL_HEAP_V6_HEADERLESS`
|
||
- `small_v6_region_observe_enabled()`: ENV `HAKMEM_SMALL_V6_REGION_OBSERVE`
|
||
- `small_v6_headerless_route_enabled(class_idx)`: 結合ゲート
|
||
|
||
2. **smallobject_core_v6.c** (変更)
|
||
- `small_v6_headerless_free()`: RegionIdBox lookup → class_idx 取得 → TLS push
|
||
- `small_v6_headerless_alloc()`: TLS pop (header 書き込みなし) + refill
|
||
|
||
3. **malloc_tiny_fast.h** (変更)
|
||
- `TINY_ROUTE_SMALL_HEAP_V6` case で headerless free/alloc を呼び出し
|
||
- ENV ゲート付き（デフォルト OFF）
|
||
|
||
### Header 書き込みポリシー
|
||
|
||
- **refill 時のみ**: carve/refill で page から TLS にブロックを移動する際に header 書き込み
|
||
- **alloc/free では書かない**: v6 headerless route では header に一切触らない
|
||
- **front は従来通り**: class_idx hint は header byte から取得（front 側の読み取りは維持）
|
||
|
||
### ENV 変数
|
||
|
||
| ENV | Default | Description |
|
||
|-----|---------|-------------|
|
||
| `HAKMEM_SMALL_HEAP_V6_ENABLED` | 0 | v6 route 有効化 |
|
||
| `HAKMEM_SMALL_HEAP_V6_CLASSES` | 0x40 | v6 対象クラスマスク (0x40=C6) |
|
||
| `HAKMEM_SMALL_HEAP_V6_HEADERLESS` | 0 | headerless mode 有効化 |
|
||
| `HAKMEM_SMALL_V6_REGION_OBSERVE` | 0 | class_idx 検証ログ |
|
||
|
||
### ベンチマーク結果
|
||
|
||
```
|
||
# Baseline (v6 OFF)
|
||
C6-heavy 257-768B: 26.8M ops/s
|
||
|
||
# v6 headerless ON
|
||
C6-heavy 257-768B: 26.7M ops/s
|
||
|
||
# v6 headerless ON + OBSERVE
|
||
C6-heavy 257-768B: 26.1M ops/s (MISMATCH なし)
|
||
```
|
||
|
||
---
|
||
|
||
## Phase V6-HDR-3: SmallSegmentV6 実割り当て（完了）
|
||
|
||
### 目的
|
||
|
||
V6-HDR-2 で connectionした headerless free/alloc を実際に機能させるため、SmallSegmentV6 の TLS-scope segment registration を実装する。RegionIdBox lookup が SMALL_V6 を返すようにして、headerless design のフルチェーンを完成させる。
|
||
|
||
### 実装タスク
|
||
|
||
| No | タスク | 状態 |
|
||
|----|--------|------|
|
||
| 1 | SmallSegmentV6 実割り当てロジック確認 | ✅ |
|
||
| 2 | small_v6_get_ctx() で segment 取得確認 | ✅ |
|
||
| 3 | RegionIdBox へ segment 登録実装 | ✅ |
|
||
| 4 | v6 alloc で segment 作成時の header 書き込み確認 | ✅ |
|
||
| 5 | RegionIdBox lookup が SMALL_V6 を返す確認 | ✅ |
|
||
| 6 | Mixed でも v6 部分 headerless 有効化 | ✅ |
|
||
| 7 | ベンチマーク 測定（headerless 効領確認）| ✅ |
|
||
|
||
### 実装詳細
|
||
|
||
1. **SmallSegmentV6 allocation** (既に v6-0 で実装済み)
|
||
- `smallsegment_v6.c`: `small_segment_v6_acquire_for_thread()` で mmap allocation + 2MiB alignment
|
||
|
||
2. **Segment registration** (`core/region_id_v6.c` 新規)
|
||
- TLS-scoped registration: 4つの static __thread 変数でセグメント情報をキャッシュ
|
||
- `region_id_register_v6_segment(seg)`: segment base/end を TLS に記録
|
||
- `region_id_lookup_v6(ptr)`: TLS segment range check を最初に実行 → O(1) hit
|
||
|
||
3. **Region type include** (`core/box/region_id_v6_box.h`)
|
||
- `#include "smallsegment_v6_box.h"` 追加（SmallSegmentV6 type 参照用）
|
||
- Function declaration: `region_id_register_v6_segment(SmallSegmentV6* seg)`
|
||
|
||
4. **Segment registration call** (`core/smallobject_core_v6.c` 変更)
|
||
- `small_heap_ctx_v6()` で segment 取得後に `region_id_register_v6_segment(seg)` 呼び出し
|
||
- region_id_observe_lookup() を small_v6_region_observe_validate() で呼び出し追加
|
||
|
||
### ENV 変数
|
||
|
||
| ENV | Default | Description |
|
||
|-----|---------|-------------|
|
||
| `HAKMEM_SMALL_HEAP_V6_ENABLED` | 0 | v6 route 有効化 |
|
||
| `HAKMEM_SMALL_HEAP_V6_CLASSES` | 0 | v6 対象クラスマスク (0x40=C6, 0x70=C4+C5+C6) |
|
||
| `HAKMEM_SMALL_HEAP_V6_HEADERLESS` | 0 | headerless mode 有効化 |
|
||
| `HAKMEM_SMALL_V6_REGION_OBSERVE` | 0 | RegionIdBox class_idx 検証ログ |
|
||
| `HAKMEM_REGION_ID_V6_OBSERVE` | 0 | RegionIdBox lookup ログ |
|
||
|
||
### ベンチマーク結果
|
||
|
||
```
|
||
# Baseline (v6 OFF)
|
||
Size 257-768B: 9.68M ops/s
|
||
|
||
# C6-only v6 (0x40)
|
||
Size 257-768B: 8.88M ops/s (-8.3%)
|
||
|
||
# C4+C5+C6 v6 Mixed (0x70)
|
||
Size 64-768B: 9.34M ops/s (-3.5%)
|
||
```
|
||
|
||
### 検証項目
|
||
|
||
- ✅ SmallSegmentV6 は mmap allocation で既に実装済み（v6-0）
|
||
- ✅ small_heap_ctx_v6() で segment 取得時に registration 呼び出し
|
||
- ✅ RegionIdBox lookup が TLS segment をチェック
|
||
- ✅ Header write は refill/carve time のみ（alloc/free で無し）
|
||
- ✅ region_id_lookup_v6() が SMALL_V6 を返すようになった
|
||
- ✅ Mixed mode でも v6 headerless が安全に動作
|
||
- ✅ ベンチマーク実行で挙動確認
|
||
|
||
---
|
||
|
||
## Phase V6-HDR-1: RegionIdBox 実配線・OBSERVE（完了）
|
||
|
||
### 目的
|
||
|
||
V6-HDR-0 で作成した RegionIdBox を C6 segment に実配線し、OBSERVE モードで
|
||
`ptr → (kind, page_meta.class_idx)` の正当性を検証する。**挙動変更なし**。
|
||
|
||
### 実装タスク
|
||
|
||
| No | タスク | 状態 |
|
||
|----|--------|------|
|
||
| 1 | RegionIdBox 実装を埋める（C6 segment lookup）| ✅ |
|
||
| 2 | v6 free の REGION_OBSERVE ロジック具体化 | ✅ |
|
||
| 3 | front 側 class_idx ヒント配線確認 | ✅ |
|
||
| 4 | ドキュメント更新（CURRENT_TASK.md, REGIONID_V6_DESIGN.md）| ✅ |
|
||
| 5 | テスト（OBSERVE ON でベンチ実行）| ✅ |
|
||
|
||
### 実装詳細
|
||
|
||
1. **RegionIdBox 実装** (`core/region_id_v6.c`)
|
||
- `region_id_lookup_v6(ptr)`: `small_page_meta_v6_of(ptr)` を使用して C6 segment 判定
|
||
- TLS cache 付き高速版: `region_id_lookup_cached_v6(ptr)`
|
||
- OBSERVE ログ: `HAKMEM_REGION_ID_V6_OBSERVE=1` で有効
|
||
|
||
2. **REGION_OBSERVE ロジック** (`core/smallobject_core_v6.c`)
|
||
- ENV: `HAKMEM_SMALL_V6_REGION_OBSERVE=1`（新設、V6-HDR-1 専用）
|
||
- free 入口で `region_id_lookup_v6(ptr)` を呼び、class_idx 検証
|
||
- 不一致時: `[V6_REGION_OBSERVE] MISMATCH ptr=... hint=X actual=Y`
|
||
|
||
3. **front 配線確認結果**
|
||
- `class_idx` hint は `free_tiny_fast()` 内でヘッダバイト `(header & 0x0F)` から取得
|
||
- v6 route (`TINY_ROUTE_SMALL_HEAP_V6`) は現在未接続（break でスキップ）
|
||
- これは「OBSERVE only, 挙動変更なし」の仕様通り
|
||
|
||
### ENV
|
||
|
||
- `HAKMEM_SMALL_V6_REGION_OBSERVE=1`: free path で class_idx 検証ログを出力
|
||
|
||
---
|
||
|
||
---
|
||
|
||
### 1. ベースライン（1 thread, ws=400, iters=1M, seed=1）
|
||
|
||
- **Mixed 16–1024B（本線）**
|
||
- コマンド: `HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE ./bench_random_mixed_hakmem 1000000 400 1`
|
||
- 主な ENV（bench_profile 経由）:
|
||
- `HAKMEM_TINY_HEAP_PROFILE=C7_SAFE`
|
||
- `HAKMEM_TINY_C7_HOT=1`
|
||
- `HAKMEM_SMALL_HEAP_V3_ENABLED=1` / `HAKMEM_SMALL_HEAP_V3_CLASSES=0x80`（C7-only v3）
|
||
- `HAKMEM_TINY_C7_ULTRA_ENABLED=1`（UF-3 セグメント版, 2MiB/64KiB）
|
||
- `HAKMEM_TINY_FRONT_V3_ENABLED=1` / `HAKMEM_TINY_FRONT_V3_LUT_ENABLED=1`
|
||
- `HAKMEM_POOL_V2_ENABLED=0`
|
||
- Throughput（現 HEAD, Release）: **約 44–45M ops/s**
|
||
- 競合:
|
||
- mimalloc: ~110–120M ops/s
|
||
- system: ~90M ops/s
|
||
|
||
- **C7-only (1024B 固定, C7 v3 + ULTRA)**
|
||
- C7 ULTRA OFF: ~38M ops/s
|
||
- C7 ULTRA ON: ~57M ops/s（約 +50%以上）
|
||
- C7 向け設計（ULTRA セグメント + TLS freelist + mask free）は成功パターンとみなし、今後の small-object v4/mid に展開予定。
|
||
|
||
- **C6-heavy mid/smallmid (257–768B, C6 は mid/pool 経路)**
|
||
- コマンド: `HAKMEM_PROFILE=C6_HEAVY_LEGACY_POOLV1 ./bench_mid_large_mt_hakmem 1 1000000 400 1`
|
||
- 現状 Throughput: **約 10M ops/s**
|
||
- 過去 Phase82 では LEGACY + flatten で 23–27M ops/s を記録しており、現行 HEAD では lookup 層（hak_super_lookup/mid_desc_lookup 等）がボトルネック化している状態。
|
||
|
||
---
|
||
|
||
### 2. いま本線で有効な箱
|
||
|
||
1. **C7 v3 + C7 ULTRA (UF-3 セグメント版)**
|
||
- Hot: TinyC7UltraBox（TLS freelist + 2MiB Segment / 64KiB Page, mask 判定）。
|
||
- Cold: C7UltraSegmentBox（page_meta[] で page/class/used/capacity を管理）。
|
||
- 特徴:
|
||
- C7-only で ~38M→~57M ops/s。Mixed でも 35M→44–45M ops/s まで底上げ。
|
||
- C7 ULTRA 管理外の ptr は必ず C7 v3 free にフォールバック（ヘッダ付き Fail-Fast 経路を維持）。
|
||
- ENV:
|
||
- `HAKMEM_TINY_C7_ULTRA_ENABLED=1`（デフォルト ON）
|
||
- `HAKMEM_TINY_C7_ULTRA_HEADER_LIGHT` は研究箱（デフォルト 0）。
|
||
|
||
2. **SmallObject v3（C7-only 本線）**
|
||
- C7 ページ単位の freelist + current/partial 管理。ColdIface は Tiny v1 経由で Superslab/Warm/Stats を触る。
|
||
- C7 ULTRA ON 時は「セグメント内 ptr だけ ULTRA が先に食い、残りは v3 free」が基本構造。
|
||
|
||
3. **mid/pool v1（C6 は一旦ここに固定, Phase C6-FREEZE）**
|
||
- C6 は Tiny/SmallObject/ULTRA で特別扱いしない。
|
||
- C6 専用 smallheap v3/v4/ULTRA・pool flatten はすべて ENV opt-in の研究箱扱い。
|
||
- 現状 C6-heavy は ~10M ops/s。再設計ターゲット。
|
||
|
||
---
|
||
|
||
### 3. small-object v4 / mid 向けの現状と方針
|
||
|
||
- **SmallObjectHotBox_v4 の箱構造（設計済み, 部分実装）**
|
||
- `SmallPageMeta`: `free_list/used/capacity/class_idx/flags/page_idx/segment`。
|
||
- `SmallClassHeap`: `current/partial_head/full_head`。
|
||
- `SmallHeapCtx`: per-thread で `SmallClassHeap cls[NUM_SMALL_CLASSES]` を持つ。
|
||
- `SmallSegment` (v4): 2MiB Segment / 64KiB Page を前提に `page_meta[]` を持つ。
|
||
- ColdIface_v4: `small_cold_v4_refill_page` / `small_cold_v4_retire_page` / `small_cold_v4_remote_push/drain` の 1 箱。
|
||
|
||
- **C6-only v4 実装（Phase v4-mid-2, 研究箱）**
|
||
- C6 の alloc/free を SmallHeapCtx v4 経由で処理し、Segment v4 から refill/retire する経路を実装済み。
|
||
- C6-heavy A/B（C6 v1 vs v4）:
|
||
- v4 OFF: ~9.4M ops/s
|
||
- v4 ON : ~10.1M ops/s（約 +8〜9%）
|
||
- Mixed で C6-only v4 を ON にすると +1% 程度（ほぼ誤差内）で回帰なし。
|
||
- デフォルトでは `HAKMEM_SMALL_HEAP_V4_ENABLED=0` / `CLASSES=0x0` のため標準プロファイルには影響しない。
|
||
|
||
- **mid/smallmid の今後の狙い**
|
||
- 現状：C6-heavy ~10M ops/s、lookup 系（hak_super_lookup / mid_desc_lookup / classify_ptr / ss_map_lookup）が ~40% を占める。
|
||
- 方向性：
|
||
- C7 ULTRA で成功したパターン（Segment + Page + TLS freelist + mask free）を small-object v4 に広げて、ptr→page→class を O(1) にする。
|
||
- mid_desc_lookup / hak_super_lookup などの lookup 層を small-object v4 route から外す。
|
||
- C6/C5 は「hot mid クラス」として段階的に v4 に載せ、その他の mid/smallmid は SmallHeap v4 or pool v1 で扱う。
|
||
|
||
---
|
||
|
||
### 4. 今後のフェーズ（TODO 概要）
|
||
|
||
1. **Phase v4-mid-3（C5-only v4 研究箱）** ✅ 完了
|
||
- ENV: `HAKMEM_SMALL_HEAP_V4_ENABLED=1` / `HAKMEM_SMALL_HEAP_V4_CLASSES=0x20` で C5 を SmallHeap v4 route に載せる。
|
||
- A/B 結果:
|
||
- C5-heavy (129–256B): v4 OFF **54.4M** → v4 ON **48.7M ops/s** (−10〜11%回帰)。既存 Tiny/front v3 経路が速い。
|
||
- Mixed 16–1024B (C6+C5 v4): C6-only **28.3M** → C5+C6 **28.9M ops/s** (+2%, 誤差〜微改善)。回帰なし。
|
||
- 方針: C5-heavy では v4 が劣後するため、C5 v4 は研究箱のまま標準プロファイルには入れない。Mixed では影響小さいため C5+C6 v4 (0x60) も研究箱として利用可能。
|
||
|
||
2. **Phase v4-mid-4/5/6（C6/C5 v4 の診断と一時凍結）** ✅ 完了
|
||
- C5 v4:
|
||
- C5-heavy (129–256B): v4 OFF **54.4M** → v4 ON **48.7M ops/s**（−10〜11% 回帰）。既存 Tiny/front v3 経路が速い。
|
||
- Mixed 16–1024B では C5+C6 v4 ON で +2〜3% 程度の微改善だが、本線として採用するほどのメリットは無い。
|
||
- C6 v4:
|
||
- 正しい C6-only ベンチ（MIN=256 MAX=510）で v4 OFF **~58–67M** → v4 ON **~48–50M ops/s**（−15〜28% 回帰）。
|
||
- stats から C6 alloc/free の 100% が v4 経路を通っていることが確認でき、route/fallback ではなく v4 実装そのものが重いことが判明。
|
||
- ws/iters を増やすと TinyHeap とページ共有する設計起因のクラッシュも残存しており、C6 v4 を現行設計のまま本線に載せるのは難しい。
|
||
- TLS fastlist:
|
||
- C6 用 TLS fastlist を追加したが、v4 ON 時の C6-heavy throughput はほぼ変わらず（48〜49M ops/s）。根本的な回帰（v4のページ管理/構造）を打ち消すには至っていない。
|
||
- 方針:
|
||
- SmallObject v4（C5/C6 向け）は当面 **研究箱のまま凍結**し、本線の mid/smallmid 改善は別設計（small-object v5 / mid-ULTRA / pool 再設計）として検討する。
|
||
- Mixed/C7 側は引き続き「C7 v3 + C7 ULTRA」を基準に A/B を行い、mid/pool 側は現行 v1 を基準ラインとして据え置く。
|
||
|
||
3. **Phase v5-2/3（C6-only v5 通電 & 薄型化）** ✅ 完了（研究箱）
|
||
- Phase v5-2: C6-only small-object v5 を Segment+Page ベースで本実装。Tiny/Pool から完全に切り離し、2MiB Segment / 64KiB Page 上で C6 ページを管理。初回は ~14–20M ops/s 程度で v1 より大幅に遅かった。
|
||
- Phase v5-3: C6 v5 の HotPath を薄型化（単一 TLS セグメント + O(1) `page_meta_of` + ビットマップによる free page 検索）。C6-heavy 1M/400 で v5 OFF **~44.9M** → v5 ON **~38.5M ops/s**（+162% vs v5-2, baseline 比約 -14%）。Mixed でも 36–39M ops/s で SEGV 無し。
|
||
- 方針: v5 は v4 より構造的には良いが、C6-only でもまだ v1 を下回るため、当面は研究箱のまま維持。本線 mid/smallmid は引き続き pool v1 基準で見つつ、v5 設計を C7 ULTRA パターンに近づける方向で検討を継続する。
|
||
|
||
3. **Phase v4-mid-SEGV（C6 v4 の SEGV 修正・研究箱安定化）** ✅ 完了
|
||
- **問題**: C6 v4 が TinyHeap のページを共有 → iters >= 800k で freelist 破壊 → SEGV
|
||
- **修正**: C6 専用 refill/retire を SmallSegment v4 に切り替え、TinyHeap 依存を完全排除
|
||
- **結果**:
|
||
- iters=1M, ws <= 390: **SEGV 消失** ✅
|
||
- C6-only (MIN=257 MAX=768): v4 OFF ~47M → v4 ON ~43M ops/s（−8.5% 回帰のみ、安定）
|
||
- Mixed 16–1024B: v4 ON で SEGV なし（小幅回帰許容）
|
||
- **方針**: C6 v4 は研究箱として**安定化完了**。本線には載せない（既存 mid/pool v1 を使用）。
|
||
|
||
4. **Phase v5-0（SmallObject v5 refactor: ENV統一・マクロ化・構造体最適化）** ✅ 完了
|
||
- **内容**: v5 基盤の改善・最適化（挙動は完全不変）
|
||
- **改善項目**:
|
||
- ENV initialization を sentinel パターンで統一（ENV_UNINIT/ENABLED/DISABLED + `__builtin_expect`）
|
||
- ポインタマクロ化: `BASE_FROM_PTR`, `PAGE_IDX`, `PAGE_META`, `VALIDATE_MAGIC`, `VALIDATE_PTR`
|
||
- SmallClassHeapV5 に `partial_count` 追加
|
||
- SmallPageMetaV5 の field 再配置（hot fields 先頭集約 → L1 cache 最適化, 24B）
|
||
- route priority ENV 追加: `HAKMEM_ROUTE_PRIORITY={v4|v5|auto}`
|
||
- segment_size override ENV 追加: `HAKMEM_SMALL_HEAP_V5_SEGMENT_SIZE`
|
||
- **挙動**: 完全不変（v5 route は呼ばれない、ENV デフォルト OFF）
|
||
- **テスト**: Mixed 16–1024B で 43.0–43.8M ops/s（変化なし）、SEGV/assert なし
|
||
- **目標**: v5-1 で C6-only stub → v5-2 で本実装 → v5-3 で Mixed に段階昇格
|
||
|
||
5. **Phase v5-1（SmallObject v5 C6-only route stub 接続）** ✅ 完了
|
||
- **内容**: C6 を v5 route に接続（中身は v1/pool fallback）
|
||
- **実装**:
|
||
- `tiny_route_env_box.h`: C6 で `HAKMEM_SMALL_HEAP_V5_ENABLED=1` なら `TINY_ROUTE_SMALL_HEAP_V5` に分岐
|
||
- `malloc_tiny_fast.h`: alloc/free switch に v5 case 追加（fallthrough で v1/pool に落ちる）
|
||
- `smallobject_hotbox_v5.c`: stub 実装（alloc は NULL 返却、free は no-op）
|
||
- **ENV**: `HAKMEM_SMALL_HEAP_V5_ENABLED=1` / `HAKMEM_SMALL_HEAP_V5_CLASSES=0x40` で opt-in
|
||
- **テスト結果**:
|
||
- C6-heavy: v5 OFF ~15.5M → v5 ON ~16.4M ops/s（変化なし, 正常）
|
||
- Mixed: 47.2M ops/s（変化なし）
|
||
- SEGV/assert なし ✅
|
||
- **方針**: v5-1 では挙動は v1/pool fallback と同じ。研究箱として ENV プリセット（`C6_SMALL_HEAP_V5_STUB`）を `docs/analysis/ENV_PROFILE_PRESETS.md` に追記。v5-2 で本実装を追加。
|
||
|
||
6. **Phase v5-2 / v5-3（SmallObject v5 C6-only 実装＋薄型化, 研究箱）** ✅ 完了
|
||
- **内容**: C6 向け SmallObjectHotBox v5 を Segment + Page + TLS ベースで実装し、v5-3 で単一 TLS セグメント＋O(1) `page_meta_of`＋ビットマップ free-page 検索などで HotPath を薄型化。
|
||
- **C6-heavy 1M/400**:
|
||
- v5 OFF（pool v1）: 約 **44.9M ops/s**
|
||
- v5-3 ON: 約 **38.5M ops/s**（v5-2 の ~14.7M からは +162% だが、baseline 比では約 -14%）
|
||
- **Mixed 16–1024B**:
|
||
- v5 ON（C6 のみ v5 route）でも 36–39M ops/s で SEGV なし（本線 Mixed プロファイルでは v5 はデフォルト OFF）。
|
||
- **方針**: C6 v5 は構造的には v4 より良く安定もしたが、まだ v1 を下回るため **研究箱のまま維持**。本線 mid/smallmid は引き続き pool v1 基準で見る。
|
||
|
||
7. **Phase v5-4（C6 v5 header light / freelist 最適化）** ✅ 完了（研究箱）
|
||
- **目的**: C6-heavy で v5 ON 時の回帰を詰める（target: baseline 比 -5〜7%）。
|
||
- **実装**:
|
||
- `HAKMEM_SMALL_HEAP_V5_HEADER_MODE=full|light` ENV を追加（デフォルト full）
|
||
- light mode: page carve 時に全ブロックの header を初期化、alloc 時の header write をスキップ
|
||
- full mode: 従来どおり alloc 毎に header write（標準動作）
|
||
- SmallHeapCtxV5 に header_mode フィールド追加（TLS で ENV を 1 回だけ読んで cache）
|
||
- **実測値**（1M iter, ws=400）:
|
||
- C6-heavy (257-768B): v5 OFF **47.95M** / v5 full **38.97M** (-18.7%) / v5 light **39.25M** (+0.7% vs full, -18.1% vs baseline)
|
||
- Mixed 16-1024B: v5 OFF **43.59M** / v5 full **36.53M** (-16.2%) / v5 light **38.04M** (+4.1% vs full, -12.7% vs OFF)
|
||
- **結論**: header light は微改善（+0.7-4.1%）だが、target の -5〜7% には届かず（現状 -18.1%）。header write 以外にも HotPath コストあり（freelist 操作、metadata access 等）。v5-5 以降で TLS cache / batching により HotPath を詰める予定。
|
||
- **運用**: 標準プロファイルでは引き続き `HAKMEM_SMALL_HEAP_V5_ENABLED=0`（v5 OFF）。C6 v5 は研究専用で、A/B 時のみ明示的に ON。
|
||
|
||
8. **Phase v5-5（C6 v5 TLS cache）** ✅ 完了（研究箱）
|
||
- **目的**: C6 v5 の HotPath から page_meta access を削減、+1-2% 改善を目指す。
|
||
- **実装**:
|
||
- `HAKMEM_SMALL_HEAP_V5_TLS_CACHE_ENABLED=0|1` ENV を追加（デフォルト 0）
|
||
- SmallHeapCtxV5 に `c6_cached_block` フィールド追加（1-slot TLS cache）
|
||
- alloc: cache hit 時は page_meta 参照せず即座に返す（header mode に応じて処理）
|
||
- free: cache 空なら block を cache に格納（freelist push をスキップ）、満杯なら evict して新 block を cache
|
||
- **実測値**（1M iter, ws=400, HEADER_MODE=full）:
|
||
- C6-heavy (257-768B): cache OFF **35.53M** → cache ON **37.02M ops/s** (+4.2%)
|
||
- Mixed 16-1024B: cache OFF **38.04M** → cache ON **37.93M ops/s** (-0.3%, 誤差範囲)
|
||
- **結論**: TLS cache により C6-heavy で +4.2% の改善を達成（目標 +1-2% を上回る）。Mixed では影響ほぼゼロ。page_meta access 削減が効いている。
|
||
- **既知の問題**: header_mode=light 時に infinite loop 発生（freelist pointer が header と衝突する edge case）。現状は full mode のみ動作確認済み。
|
||
- **運用**: 標準プロファイルでは `HAKMEM_SMALL_HEAP_V5_TLS_CACHE_ENABLED=0`（OFF）。C6 研究用で cache ON により v5 性能を部分改善可能。
|
||
|
||
9. **Phase v5-6（C6 v5 TLS batching）** ✅ 完了（研究箱）
|
||
- **目的**: refill 頻度を削減し、C6-heavy で v5 full+cache 比の追加改善を狙う。
|
||
- **実装**:
|
||
- `HAKMEM_SMALL_HEAP_V5_BATCH_ENABLED` / `HAKMEM_SMALL_HEAP_V5_BATCH_SIZE` を追加し、SmallHeapCtxV5 に `SmallV5Batch c6_batch`（slots[4] + count）を持たせて、C6 v5 alloc/free で TLS バッチを優先的に使うようにした。
|
||
- **実測（1M/400, HEADER_MODE=full, TLS cache=ON, v5 ON）**:
|
||
- C6-heavy: batch OFF **36.71M** → batch ON **37.78M ops/s**（+2.9%）
|
||
- Mixed 16–1024B: batch OFF **38.25M** → batch ON **37.09M ops/s**（約 -3%, C6-heavy 専用オプションとして許容）
|
||
- **方針**: C6-heavy では cache に続いて batch でも +数% 改善を確認できたが、v5 全体は依然 baseline(v1/pool) より遅い。C6 v5 は引き続き研究箱として維持し、本線 mid/smallmid は pool v1 を基準に見る。
|
||
|
||
10. **Phase v6-0（SmallObject Core v6 設計・型スケルトン）** ✅ 完了（設計）
|
||
- **目的**: 16〜2KiB small-object/mid 向けに、L0 ULTRA / L1 Core / L2 Segment+ColdIface / L3 Policy の4層構造とヘッダレス前提の HotBox を定義し、「これ以上動かさない核」の設計を固める。
|
||
- **内容**:
|
||
- `docs/analysis/SMALLOBJECT_CORE_V6_DESIGN.md` を追加し、SmallHeapCtxV6 / SmallClassHeapV6 / SmallPageMetaV6 / SmallSegmentV6 と ptr→page→class O(1) ルール、HotBox が絶対にやらない責務（header 書き・lookup・Stats など）を明文化。
|
||
- v6 は現時点ではコードは一切触らず、設計レベルの仕様と型イメージだけをまとめた段階。v5 は C6 研究箱として残しつつ、将来 small-object を作り直す際の「芯」として v6 の層構造を採用する。
|
||
|
||
11. **Phase v6-1〜v6-4（SmallObject Core v6 C6-only 実装＋薄型化＋Mixed 安定化）** ✅ 完了（研究箱）
|
||
- **v6-1**: route stub 接続（挙動は v1/pool fallback のまま）。
|
||
- **v6-2**: Segment v6 + ColdIface v6 + Core v6 HotPath の最低限実装。C6-heavy で v6 経路が SEGV なく完走するところまで確認（初期は約 -44%）。
|
||
- **v6-3**: 薄型化（TLS ownership check + batch header write + TLS batch refill）により、C6-heavy で v6 OFF ≈27.1M / v6-3 ON ≈27.1M（±0%, baseline 同等）まで改善。
|
||
- **v6-4**: Mixed での v6 安定化。`small_page_meta_v6_of` が TLS メタではなく mmap 領域を見ていたバグを修正し、Mixed v6 ON でも完走（C6-only v6 のため Mixed は v6 ON ≈35.8M, v6 OFF ≈44M）。
|
||
- **現状**:
|
||
- C6-heavy: v6 OFF ≈27.1M / v6 ON ≈27.4M（C6 Core v6 は baseline 同等・安定）。
|
||
- Mixed: C6-only v6 のため全体ではまだ約 -19% 回帰。C6-heavy 用の実験箱として v6 を維持しつつ、本線 Mixed は引き続き v6 OFF を基準に見る。
|
||
|
||
12. **Phase v6-5（SmallObject Core v6 C5 拡張, 研究箱）** ✅ 完了
|
||
- **目的**: Core v6 を C5 サイズ帯（129–256B）にも拡張し、free hotpath で v6 がカバーするクラスを増やす足場を作る。
|
||
- **実装**:
|
||
- `SmallHeapCtxV6` に C5 用 TLS freelist（`tls_freelist_c5` / `tls_count_c5`）を追加し、C5 でも `small_alloc_fast_v6` / `small_free_fast_v6` が TLS→refill/slow のパターンで動くようにした。
|
||
- ColdIface v6 の refill/retire を class_idx（C5/C6）に応じて block_size/容量を変えられるよう一般化。
|
||
- **実測（1M/400, v6 ON C5-only, C6 v6 OFF）**:
|
||
- C5-heavy (129–256B): v6 OFF ≈53.6M → v6 ON(C5) ≈41.0M（約 -23%）
|
||
- Mixed 16–1024B: v6 OFF ≈44.0M → v6 ON(C5) ≈36.2M（約 -18%）
|
||
- **方針**: C5 Core v6 は安定して動くものの、Tiny front v3 + v1/pool より大きく遅いため、本線には乗せず C5 v6 は研究箱扱いとする。C5-heavy/Mixed の free hotpath をさらに削るなら、v6 側のさらなる薄型化か、別の箱（front/gate や pool）の再設計を検討する。
|
||
|
||
13. **Phase v6-6（SmallObject Core v6 C4 拡張, 研究箱）** ✅ 完了
|
||
- **目的**: Core v6 を C4 サイズ帯（65–128B）に拡張して、free hotpath カバー範囲を広げ、`ss_fast_lookup`/`slab_index_for` 依存を削減。
|
||
- **実装内容**:
|
||
- `SmallHeapCtxV6` に C4 用 TLS freelist（`tls_freelist_c4` / `tls_count_c4`）を追加。
|
||
- `small_alloc_fast_v6` に C4 fast/cold refill path を追加（`small_alloc_c4_hot_v6` / `small_alloc_cold_v6` で C4 支援）。
|
||
- `small_free_fast_v6` に C4 TLS push path を追加（`small_free_c4_hot_v6`）。
|
||
- `malloc_tiny_fast.h` alloc/free dispatcher に C4 case を追加。
|
||
- ColdIface v6 refill を C4（128B block）に対応。
|
||
- **バグ修正**: `small_alloc_cold_v6` に C4 refill logic が欠落していたのを修正（cold path で C4 refill が実装されていなかったため、全て pool fallback になっていた）。
|
||
- **実測値**（100k iter, v6 ON, mixed size workload）:
|
||
- **C4-only (80B, class 4)**: v6 OFF ≈47.4M → v6 ON ≈39.4M（**−17% 回帰**）
|
||
- **C5+C6 (mixed 200/400B)**: v6 OFF ≈43.5M → v6 ON ≈26.8M（**−38% 回帰**）
|
||
- **Mixed (500B)**: v6 OFF ≈40.8M → v6 ON ≈27.5M（**−33% 回帰**）
|
||
- **評価**:
|
||
- 目標: v6-6 は ±0–数% within acceptable range（user 指定）を狙っていたが、C4 実装によっても大きな回帰が消えず（C4-only: −17%）。
|
||
- 根本原因: v6 実装そのもの（TLS ownership check + page refill + cold path）の overhead が v5 以来続いており、C4 拡張では構造的な改善に至らず。
|
||
- **安全確認の閾値超過**: Mixed で −33% は user 指定の「−10% 以上落ちたら研究箱に留める」基準を大きく超過。
|
||
- **方針**: **Phase v6-6 は研究箱に留め、本線に乗せない**。v6-6 （C4 extend ）は ENV opt-in のみ。混在リスク防止のため、v6-5（C5）と v6-6（C4）は同時 ON は非推奨（Mixed で −33%）。
|
||
- **今後の方向性**:
|
||
- v6 系は「C6 baseline 同等」では達成できたが（v6-3：C6-only で ±0%），C5/C4 への拡張では overhead が大きい。
|
||
- 次のアプローチは v6 architecture の root cause 調査（TLS ownership check の cost / page refill overhead / cold path cost 等）か、別設計（pool v2 再設計, front gate 薄型化, ULTRA segment 拡張）を検討すべき。
|
||
|
||
---
|
||
|
||
### 6. free path 最適化の方針（Phase FREE-LEGACY-BREAKDOWN 系列）
|
||
|
||
**現状認識**:
|
||
- Mixed 16–1024B の perf 内訳: free ≈ 24%, tiny_alloc_gate_fast ≈ 22%
|
||
- v6（C5/C4 拡張）で −33% 回帰、free-front v3 で −4% 回帰
|
||
- 新世代追加ではなく、既存 free path の「どの箱が何％食っているか」を可視化してピンポイント削減する方針に転換
|
||
|
||
**本線の前提（固定）**:
|
||
- Mixed 16–1024B: Tiny front v3 + C7 ULTRA + pool v1（約 44–45M ops/s）
|
||
- v4/v5/v6（C5/C4）/ free-front v3 は 研究箱・デフォルト OFF
|
||
- v6 は C6-only の mid 向けコア（C6-heavy プロファイル専用で ON、±0% 達成）
|
||
- `HAKMEM_SMALL_HEAP_V6_ENABLED=0` / `HAKMEM_TINY_FREE_FRONT_V3_ENABLED=0` が基準
|
||
|
||
**Phase FREE-LEGACY-BREAKDOWN-1** ✅ 完了
|
||
- 目的: free ホットパスを箱単位でカウントし、内訳を可視化
|
||
- 実装:
|
||
- ENV: `HAKMEM_FREE_PATH_STATS=1` で free path の箱ごとカウンタを有効化（default 0）
|
||
- FreePathStats 構造体で c7_ultra / v3 / v6 / pool v1 / super_lookup / remote_free などを計測
|
||
- デストラクタで `[FREE_PATH_STATS]` 出力
|
||
- 測定結果: `docs/analysis/FREE_LEGACY_PATH_ANALYSIS.md` に記録
|
||
- 次フェーズ: 測定結果を見て FREE-LEGACY-OPT-1/2/3 のどれを実装するか決定
|
||
|
||
**Phase FREE-LEGACY-BREAKDOWN-1 測定結果** ✅ 完了
|
||
- Mixed 16–1024B の free 経路内訳:
|
||
- **C7 ULTRA fast**: 50.7% (275,089 / 542,031 calls)
|
||
- **Legacy fallback**: 49.2% (266,942 / 542,031 calls)
|
||
- pool_v1_fast: 1.5% (8,081 / 542,031 calls)
|
||
- その他（v3/v6/tiny_v1/super_lookup/remote）: 0.0%
|
||
- C6-heavy の free 経路内訳:
|
||
- **pool_v1_fast**: 100% (500,099 / 500,108 calls)
|
||
- その他: 0.0%
|
||
- 主要発見:
|
||
- Mixed は **完全な二極化構造**（C7 ULTRA 50.7% vs Legacy 49.2%）
|
||
- C6-heavy は pool_v1 経路のみを使用（最適化ターゲット明確）
|
||
- 詳細: `docs/analysis/FREE_LEGACY_PATH_ANALYSIS.md` 参照
|
||
|
||
**Phase FREE-LEGACY-OPT-4 シリーズ: Legacy fallback 削減（計画中）**
|
||
- 目的: Mixed の Legacy fallback 49.2% を削減し、C7 ULTRA パターンを他クラスに展開
|
||
- アプローチ:
|
||
- **4-0**: ドキュメント整理 ✅
|
||
- **4-1**: Legacy の per-class 分析（どのクラスが Legacy を最も使用しているか特定）
|
||
- **4-2**: 1クラス限定 ULTRA-Free lane の設計・実装
|
||
- 対象: 4-1 で特定された最大シェアクラス（仮に C5）
|
||
- 実装: TLS free キャッシュのみ追加（alloc 側は既存のまま）
|
||
- ENV: `HAKMEM_TINY_C5_ULTRA_FREE_ENABLED=0` (研究箱)
|
||
- **4-3**: A/B テスト（Mixed で効果測定、結果次第で本線化 or 研究箱維持）
|
||
- 期待効果: Legacy 49% → 35-40% に削減、free 全体で 5-10% 改善、Mixed で +2-4M ops/s
|
||
|
||
---
|
||
|
||
### 5. 健康診断ラン（必ず最初に叩く 2 本）
|
||
|
||
- Tiny/Mixed 用:
|
||
```sh
|
||
HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE \
|
||
./bench_random_mixed_hakmem 1000000 400 1
|
||
# 目安: 44±1M ops/s / segv/assert なし
|
||
```
|
||
|
||
- mid/smallmid C6 用:
|
||
```sh
|
||
HAKMEM_PROFILE=C6_HEAVY_LEGACY_POOLV1 \
|
||
./bench_mid_large_mt_hakmem 1 1000000 400 1
|
||
# 現状: ≈10M ops/s / segv/assert なし（再設計ターゲット）
|
||
```
|
||
|
||
まとめて叩きたいときは `scripts/verify_health_profiles.sh`（存在する場合）を利用し、
|
||
詳細な perf/フェーズログは `CURRENT_TASK_ARCHIVE_20251210.md` と各 `docs/analysis/*` を参照してください。
|
||
|
||
|
||
---
|
||
|
||
## Phase FREE-LEGACY-OPT-4-4: C6 ULTRA free+alloc 統合（寄生型 TLS キャッシュ）✅ 完了
|
||
|
||
### 目的
|
||
Phase 4-3 で free-only TLS キャッシュが effective でないことが判明したため、
|
||
alloc 側に TLS pop を追加して統合し、完全な alloc/free サイクルを実現。
|
||
|
||
### 実装内容
|
||
- malloc_tiny_fast.h: C6 ULTRA alloc pop（L191-202）
|
||
- FreePathStats: c6_ultra_alloc_hit カウンタ追加
|
||
- ENV: HAKMEM_TINY_C6_ULTRA_FREE_ENABLED (default: OFF)
|
||
|
||
### 計測結果
|
||
|
||
**Mixed 16–1024B (1M iter, ws=400)**:
|
||
- OFF (baseline): 40.2M ops/s
|
||
- ON (統合後): 42.2M ops/s
|
||
- **改善: +4.9%** ✅ 期待値達成
|
||
|
||
**C6-heavy (257-768B, 1M iter, ws=400)**:
|
||
- OFF: 40.7M ops/s
|
||
- ON: 43.8M ops/s
|
||
- **改善: +7.6%** ✅ Mixed より効果大
|
||
|
||
### 効果の分析
|
||
|
||
**Legacy の劇的削減**:
|
||
- Legacy fallback: 266,942 → 129,623 (**-51.4%**)
|
||
- Legacy by class[6]: 137,319 → 0 (**100% 排除**)
|
||
|
||
**TLS サイクルの成功**:
|
||
- C6 allocs: 137,241 が TLS pop で direct serve
|
||
- C6 frees: 137,319 が TLS push で登録
|
||
- キャッシュは過充填しない（alloc が drain）
|
||
|
||
### 設計パターン
|
||
|
||
**寄生型 TLS キャッシュ**:
|
||
- Core v6 のような専用 segment 管理なし
|
||
- 既存 allocator に「寄生」（overhead minimal）
|
||
- free + alloc 両方制御で完全なサイクル実現
|
||
|
||
### 判定結果
|
||
|
||
✅ **期待値達成**: +3-5% → **+4.9%** を実現
|
||
✅ **C6 legacy 100% 排除**: 設計の妥当性確認
|
||
✅ **本命候補に昇格**: ENV デフォルト OFF は維持
|
||
|
||
---
|
||
|
||
## Phase REFACTOR-1/2/3: Code Quality Improvement ✅ 完了
|
||
|
||
### 実施内容
|
||
|
||
1. **REFACTOR-1: Magic Number → Named Constants**
|
||
- 新ファイル: tiny_ultra_classes_box.h
|
||
- TINY_CLASS_C6/C7、tiny_class_is_c6/c7() マクロ定義
|
||
- malloc_tiny_fast.h: == 6, == 7 → semantic macros
|
||
|
||
2. **REFACTOR-2: Legacy Fallback Logic 統一化**
|
||
- 新ファイル: tiny_legacy_fallback_box.h
|
||
- tiny_legacy_fallback_free_base() 統一関数
|
||
- 重複削除: 60行（malloc_tiny_fast.h と tiny_c6_ultra_free_box.c）
|
||
|
||
3. **REFACTOR-3: Inline Pointer Macro 中央化**
|
||
- 新ファイル: tiny_ptr_convert_box.h
|
||
- tiny_base_to_user_inline(), tiny_user_to_base_inline()
|
||
- offset 1 byte を centralized に
|
||
|
||
### 効果
|
||
|
||
- ✅ **DRY 原則**: Code duplication 削減（60行）
|
||
- ✅ **可読性**: Magic number → semantic macro
|
||
- ✅ **保守性**: offset, logic を1箇所で定義
|
||
- ✅ **Performance**: Zero regression（inline preserved）
|
||
|
||
### 累積改善（Phase 4-0 → Refactor-3）
|
||
|
||
| Phase | 改善 | 累積 | 特徴 |
|
||
|-------|------|------|------|
|
||
| 4-1 | - | - | Legacy per-class 分析 |
|
||
| 4-2 | +0% | 0% | Free-only TLS（効果なし） |
|
||
| 4-3 | +1-3% | 1-3% | Segment 学習（限定的） |
|
||
| **4-4** | **+4.9%** | **+4.9%** | **Free+alloc 統合（本命）** |
|
||
| REFACTOR | +0% | +4.9% | Code quality（overhead なし） |
|
||
|
||
---
|
||
|
||
## Phase FREE-FRONT-V3-1 実装完了 (2025-12-11)
|
||
|
||
**目的**: free 前段に「v3 snapshot 箱」を差し込み、route 判定と ENV 判定を 1 箇所に集約する足場を作る。挙動は変えない。
|
||
|
||
**実装内容**:
|
||
|
||
1. **新規ファイル作成**: `core/box/free_front_v3_env_box.h`
|
||
- free_route_kind_t enum (FREE_ROUTE_LEGACY, FREE_ROUTE_TINY_V3, FREE_ROUTE_CORE_V6_C6, FREE_ROUTE_POOL_V1)
|
||
- FreeRouteSnapshotV3 struct (route_kind[NUM_SMALL_CLASSES])
|
||
- API 3個: free_front_v3_enabled(), free_front_v3_snapshot_get(), free_front_v3_snapshot_init()
|
||
- ENV: HAKMEM_TINY_FREE_FRONT_V3_ENABLED (default 0 = OFF)
|
||
|
||
2. **実装ファイル**: `core/box/free_front_v3_env_box.c`
|
||
- free_front_v3_enabled() - ENV lazy init (default OFF)
|
||
- free_front_v3_snapshot_get() - TLS snapshot アクセス
|
||
- free_front_v3_snapshot_init() - route_kind テーブル初期化
|
||
- 現行 tiny_route_for_class() を使って既存挙動を維持
|
||
|
||
3. **ファイル修正**: `core/box/hak_free_api.inc.h`
|
||
- FG_DOMAIN_TINY 内に v3 snapshot routing logic を追加
|
||
- v3 OFF (default) では従来パスを維持（挙動変更なし）
|
||
- v3 ON では snapshot 経由で route 決定 (v6 c6, v3, pool v1)
|
||
|
||
4. **Makefile 更新**
|
||
- OBJS_BASE, BENCH_HAKMEM_OBJS_BASE, SHARED_OBJS に free_front_v3_env_box.o 追加
|
||
|
||
**ビルド結果**:
|
||
- ✅ コンパイル成功 (free_front_v3_env_box.o 生成)
|
||
- ✅ リンク成功 (free_front_v3_enabled, free_front_v3_snapshot_get シンボル解決)
|
||
- 既存の v3/v4/v5/v6 関連のリンクエラーは pre-existing issue
|
||
|
||
**次フェーズ (FREE-FRONT-V3-2)**:
|
||
- route_for_class 呼び出し削減
|
||
- ENV check 削除（snapshot 内に統合済み）
|
||
- snapshot 初期化の最適化
|
||
|
||
---
|
||
|
||
## Phase FREE-FRONT-V3-2 実装完了 (2025-12-11)
|
||
|
||
**目的**: free path から `tiny_route_for_class()` 呼び出しと redundant な ENV check を削減し、free 処理を最適化する。
|
||
|
||
**実装内容**:
|
||
|
||
1. **smallobject_hotbox_v3_env_box.h に small_heap_v3_class_mask() 追加**
|
||
- v3 対象クラスのビットマスクを返す関数を追加（v6 と同様の API）
|
||
- small_heap_v3_class_enabled() をマスク経由に書き換え
|
||
|
||
2. **free_front_v3_snapshot_init() の最適化** (core/box/free_front_v3_env_box.c)
|
||
- tiny_route_for_class() 呼び出しを完全削除
|
||
- ENV マスクを直接読んで判定（v6_mask, v3_mask）
|
||
- 優先度順に route 決定: v6 > v3 > pool/legacy
|
||
|
||
3. **hak_free_at() v3 path の最適化** (core/box/hak_free_api.inc.h)
|
||
- v6 hot path を inline で呼び出す（small_free_c6_hot_v6, c5, c4）
|
||
- ENV check なし、snapshot だけで完結
|
||
- v3 path (C7) は so_free() に委譲（ss_fast_lookup は v3 内部で処理）
|
||
|
||
**ベンチマーク結果**:
|
||
|
||
**Mixed 16-1024B (bench_random_mixed_hakmem 100000 400 1)**:
|
||
- v3 OFF (baseline): 42.6M, 41.6M, 45.2M ops/s → 平均 **43.1M ops/s**
|
||
- v3 ON (optimized): 41.1M, 39.9M, 43.0M ops/s → 平均 **41.3M ops/s**
|
||
- 結果: **−4.2%** (微回帰)
|
||
|
||
**C6-heavy mid/smallmid (bench_mid_large_mt_hakmem 1 100000 400 1)**:
|
||
- v3 OFF (baseline): 13.8M, 15.2M, 14.5M ops/s → 平均 **14.5M ops/s**
|
||
- v3 ON (optimized): 15.5M, 15.2M, 14.0M ops/s → 平均 **14.9M ops/s**
|
||
- 結果: **+2.8%** (誤差〜微改善)
|
||
|
||
**安定性**:
|
||
- ✅ コンパイル成功、リンク成功
|
||
- ✅ SEGV/assert なし
|
||
- ✅ v3 OFF 時は従来パスを維持（完全に変更なし）
|
||
|
||
**結論**:
|
||
- Mixed で微回帰 (−4%) が見られるため、v3 は引き続き研究箱（default OFF）として維持
|
||
- C6-heavy では微改善 (+3%) が確認されたが、誤差範囲内
|
||
- snapshot infrastructure は正常に動作しており、今後の最適化の足場として有用
|
||
- Phase v3-3 では、v6 hot path の inline 化や route dispatch の最適化を検討
|
||
|
||
---
|
||
|
||
## Phase PERF-ULTRA-REBASE-1 実施完了 (2025-12-11)
|
||
|
||
**目的**: C4-C7 ULTRA を全て有効にした状態での CPU ホットパス計測
|
||
|
||
**計測条件**:
|
||
- ENV: HAKMEM_TINY_C4/C5/C6/C7_ULTRA_FREE_ENABLED=1（全て ON）
|
||
- v6/v5/v4/free-front-v3 は OFF（研究箱）
|
||
- ワークロード: Mixed 16-1024B, 10M cycles, ws=8192
|
||
- Throughput: 31.61M ops/s
|
||
|
||
**ホットパス分析結果** (allocator 内部, self%):
|
||
|
||
| 順位 | 関数/パス | self% | 分類 |
|
||
|------|----------|-------|------|
|
||
| 🔴 **#1** | **C7 ULTRA alloc** | **7.66%** | ← **新しい最大ボトルネック** |
|
||
| #2 | C4-C7 ULTRA free群 | 5.41% | alloc-free cycle |
|
||
| #3 | so_alloc系 (v3 backend) | 3.60% | 中規模alloc |
|
||
| #4 | page_of/segment判定 | 2.74% | ptr解決 |
|
||
| #5 | gate/front前段 | 2.51% | ✅改善済み |
|
||
| #6 | so_free系 | 2.47% | - |
|
||
| #7 | ss_map_lookup | 0.79% | ✅大幅改善済み |
|
||
|
||
**重要な発見**:
|
||
1. **C7 ULTRA alloc が明確な最大ボトルネック** - gate/front や header はもう十分薄い
|
||
2. **header書き込みが不可視** (< 0.17%) - ULTRA経路での削減効果が出ている
|
||
3. **gate/front は既に許容範囲** (2.51%) - 以前のフェーズより改善済み
|
||
|
||
**分析結論**:
|
||
- v6/v5/v4 のような新世代追加ではなく、「既に当たりが出ている C7/C4/C5/C6 ULTRA 内部を薄くする」フェーズへ転換すべき
|
||
- C7 ULTRA alloc の 7.66% を 5-6% に削れば、全体で 2-3% の効果が期待できる
|
||
|
||
**詳細**: `docs/analysis/TINY_CPU_HOTPATH_USERLAND_ANALYSIS.md` 参照
|
||
|
||
---
|
||
|
||
## Phase PERF-ULTRA-ALLOC-OPT-1 計画（実装予定）
|
||
|
||
**目的**: C7 ULTRA alloc（7.66%）の内部最適化による alloc パス高速化
|
||
|
||
**ターゲット**: `tiny_c7_ultra_alloc()` の hot path を直線化
|
||
|
||
**実装施策**:
|
||
1. **TLS ヒットパスの直線化**
|
||
- env check / snapshot 取得が残っていないか確認
|
||
- fast path を完全に直線化（分岐最小化）
|
||
2. **TLS freelist レイアウト最適化**
|
||
- 1 cache line に収まるか確認
|
||
- alloc ホットデータ（freelist[], count）の配置最適化
|
||
3. **segment/page_meta アクセスの確認**
|
||
- segment learning / page_meta access が本当に slow path だけか確認
|
||
- hot path に余分なメモリアクセスがないか確認
|
||
|
||
**計測戦略**:
|
||
- C7-only と Mixed 両方の A/B テスト（enabler: HAKMEM_TINY_C7_ULTRA_FREE_ENABLED=1）
|
||
- perf 計測で self% が 7.66% → 5-6% まで落ちるか確認
|
||
- throughput 改善量を測定
|
||
|
||
**期待値**: alloc パスで 5-10% の削減
|
||
|
||
**次ステップ**: 実装完了後、perf 再計測で効果を検証
|
||
|
||
---
|
||
|
||
## 次フェーズ候補（決定保留中）
|
||
|
||
### 実装予定フェーズ
|
||
|
||
1. **Phase PERF-ULTRA-ALLOC-OPT-1** (即座実装)
|
||
- C7 ULTRA alloc 内部最適化
|
||
- 目標: 7.66% → 5-6%
|
||
- 期待: 全体で 2-3% 改善
|
||
|
||
2. **Phase PERF-ULTRA-ALLOC-OPT-2** (後続)
|
||
- C4-C7 ULTRA free群（5.41%）の軽量化
|
||
- page_of / segment判定との連携最適化
|
||
|
||
### 研究箱（後回し、当面は OFF）
|
||
|
||
- **C3/C2 ULTRA**: legacy 小さい（4% 未満）のに TLS 増加で L1 汚染リスク
|
||
- **v6/v5/v4 拡張**: 既存 v1/pool より大幅に遅く、新世代追加は現段階では回帰誘発
|
||
- **FREE-FRONT-V3-2**: 以前 -4% 回帰があったため、ULTRA 整備後に再検討
|
||
|
||
---
|
||
|
||
## 実装ポリシー変換（重要）
|
||
|
||
### これまで（フェーズ 4-4 まで）
|
||
- 新しい箱や世代（v4/v5/v6/free-front-v3 等）を増やす
|
||
- 当たりが出たら本線化する
|
||
|
||
### 今後（PERF-ULTRA-ALLOC-OPT 以降）
|
||
- **既に当たりが出ている箱（C4-C7 ULTRA）の中身を細かく削る**
|
||
- 新世代追加は避ける（L1 キャッシュ汚染、複雑度増加のリスク）
|
||
- hotpath 分析 → ピンポイント最適化のサイクルを回す
|
||
|
||
|
||
---
|
||
|
||
## Phase PERF-ULTRA-ALLOC-OPT-1 実装試行 (2025-12-11)
|
||
|
||
**目的**: C7 ULTRA alloc（現在 7.66% self%）の hot path を直線化し、5-6% まで削減
|
||
|
||
**実装内容**:
|
||
- 新規ファイル作成:
|
||
- `core/box/tiny_c7_ultra_free_env_box.h`: ENV gate (HAKMEM_TINY_C7_ULTRA_FREE_ENABLED, default ON)
|
||
- `core/box/tiny_c7_ultra_free_box.h`: TLS structure (TinyC7UltraFreeTLS) with optimized layout (count first)
|
||
- `core/box/tiny_c7_ultra_free_box.c`: tiny_c7_ultra_alloc_fast() / tiny_c7_ultra_free_fast() implementation
|
||
- 変更ファイル:
|
||
- `core/front/malloc_tiny_fast.h`: 新しい C7 ULTRA alloc/free fast path の統合
|
||
- `core/box/free_path_stats_box.h`: c7_ultra_free_fast / c7_ultra_alloc_hit カウンタ追加
|
||
- `Makefile`: tiny_c7_ultra_free_box.o の追加
|
||
|
||
**設計意図**:
|
||
- C4/C5/C6 ULTRA free と同様の「寄生型 TLS キャッシュ」パターンを C7 に適用
|
||
- TLS freelist (128 slots) で alloc/free を高速化
|
||
- hot field (count) を構造体先頭に配置して L1 cache locality 向上
|
||
- 既存 C7 ULTRA (UF-3) をコールドパスとして温存
|
||
|
||
**実装上の課題**:
|
||
1. **Segment lookup 問題**:
|
||
- tiny_c7_ultra_segment_from_ptr() が常に NULL を返す現象を確認
|
||
- BASE pointer / USER pointer 両方試したが解決せず
|
||
- g_ultra_seg (TLS変数) の初期化タイミング or 可視性の問題の可能性
|
||
|
||
2. **TLS cache 未動作**:
|
||
- FREE_PATH_STAT の c7_ultra_free_fast カウンタが常に 0
|
||
- c7_ultra_alloc_hit カウンタも常に 0
|
||
- segment check を完全に bypass しても改善せず
|
||
- TLS cache への push/pop が一度も成功していない状態
|
||
|
||
3. **統合の複雑性**:
|
||
- 既存 C7 ULTRA (UF-1/UF-2/UF-3) と新実装の ENV 変数が異なる
|
||
- HAKMEM_TINY_C7_ULTRA_ENABLED (既存) vs HAKMEM_TINY_C7_ULTRA_FREE_ENABLED (新規)
|
||
- 既存実装が tiny_c7_ultra.c で独自の TLS freelist を持っている
|
||
|
||
**計測結果**:
|
||
- Build: 成功 (warning のみ)
|
||
- Sanity test: 成功 (SEGV/assert なし)
|
||
- Throughput: ~44M ops/s (ベースラインと同等, 改善なし)
|
||
- perf self%: 7.66% (変化なし, 最適化未適用状態)
|
||
|
||
**分析と考察**:
|
||
1. **根本原因の可能性**:
|
||
- C7 ULTRA の既存実装 (tiny_c7_ultra.c) が独自の TLS state と segment 管理を持つ
|
||
- 新規に作成した TLS cache が既存実装と統合されていない
|
||
- segment lookup が期待通り動作しない (g_ultra_seg の初期化/可視性問題)
|
||
|
||
2. **アプローチの見直し必要性**:
|
||
- 現在: 既存 C7 ULTRA とは別の並列システムを作成 (C4/C5/C6 パターン)
|
||
- 提案: 既存 tiny_c7_ultra.c の tiny_c7_ultra_alloc() を直接最適化すべき
|
||
- 理由: C7 ULTRA は既に専用 segment と TLS を持ち、独立したサブシステム
|
||
|
||
3. **次ステップの推奨**:
|
||
- Option A: tiny_c7_ultra.c の tiny_c7_ultra_alloc() 内部を直接最適化
|
||
- ENV check の外出し
|
||
- TLS freelist access の直線化
|
||
- 不要な分岐の削除
|
||
- Option B: 現在の実装の segment lookup 問題を解決
|
||
- g_ultra_seg の初期化タイミングを調査
|
||
- デバッグビルドでの詳細トレース
|
||
- segment registry との統合確認
|
||
|
||
**ステータス**: **未完了 (要再設計)**
|
||
|
||
**教訓**:
|
||
- C7 ULTRA は C4/C5/C6 と異なり、既に専用の segment 管理と TLS を持つ独立システム
|
||
- 「寄生型」パターンは既存 allocator に寄生する前提だが、C7 ULTRA は独立しており不適合
|
||
- 直接最適化 (ENV check 外出し、分岐削減) の方が適切なアプローチの可能性が高い
|
||
|
||
**次フェーズへの示唆**:
|
||
- Phase PERF-ULTRA-ALLOC-OPT-1 は一旦保留し、アプローチを再検討
|
||
- tiny_c7_ultra.c の tiny_c7_ultra_alloc() を直接プロファイリングし、hot path 特定
|
||
- ENV check / 分岐削減 / TLS access 最小化を既存コード内で実施
|
||
|
||
---
|
||
|
||
## Phase PERF-ULTRA-ALLOC-OPT-1 実装完了 (2025-12-11)
|
||
|
||
C7 ULTRA alloc は tiny_c7_ultra.c 内最適化で self%/throughput ともほぼ不変。
|
||
これ以上は refill/path 設計が絡むため一旦打ち止め。
|
||
|
||
---
|
||
|
||
## Phase PERF-ULTRA-FREE-OPT-1 実装完了 (2025-12-11)
|
||
|
||
**実装内容**:
|
||
- C4–C7 ULTRA free を pure TLS push + cold segment learning に統一
|
||
- C4/C5/C6 ULTRA は既に最適化済み（統一 legacy fallback 経由）
|
||
- C7 ULTRA free を同じパターンに整列（likely/unlikely + FREE_PATH_STAT_INC 追加）
|
||
- base/user 変換は tiny_ptr_convert_box.h マクロで統一済み
|
||
|
||
**実測値** (Mixed 16-1024B, 1M iter, ws=400):
|
||
- Baseline (C7 ULTRA のみ): 42.0-42.1M ops/s, legacy_fb=266,943 (49.2%)
|
||
- Optimized (C4-C7 ULTRA 全有効): 45.7-47.0M ops/s, legacy_fb=26,025 (4.8%)
|
||
- **改善: +8.8-11.7%** (平均 +9.3%, 約 +4M ops/s)
|
||
|
||
**FREE_PATH_STATS 分析**:
|
||
- C7 ULTRA: 275,057 (50.7%, 不変)
|
||
- C6 ULTRA: 0 → 137,319 free + 137,241 alloc (**100% カバー**, legacy C6 完全排除)
|
||
- C5 ULTRA: 0 → 68,871 free + 68,827 alloc (**100% カバー**, legacy C5 完全排除)
|
||
- C4 ULTRA: 0 → 34,727 free + 34,696 alloc (**100% カバー**, legacy C4 完全排除)
|
||
- Legacy fallback: 266,943 → 26,025 (**-90.2%**, C2/C3 のみ残存)
|
||
|
||
**C4/C5/C6-heavy 安定性確認**:
|
||
- C4-heavy (65-128B): 55.0M ops/s, SEGV/assert なし
|
||
- C5-heavy (129-256B): 56.5M ops/s, SEGV/assert なし
|
||
- C6-heavy (257-768B): 16.9M ops/s, SEGV/assert なし
|
||
|
||
**評価**: **目標達成**
|
||
- Legacy 49% → 5% に削減（−90%）
|
||
- C4/C5/C6 ULTRA により Mixed throughput +9.3%
|
||
- 全クラス（C4-C7）で統一された TLS push パターン確立
|
||
|
||
|
||
|
||
---
|
||
|
||
## Phase PERF-ULTRA-REBASE-3: 正しいパラメータで再計測 (2025-12-11)
|
||
|
||
**問題**: Phase REBASE-2 で iters=1M, ws=400 は軽すぎて ULTRA 関数が invisible（238 samples のみ）だったため、正しいパラメータで再実施。
|
||
|
||
**修正内容**: iters=10M, ws=8192（Phase REBASE-1 と同じパラメータで再計測）
|
||
|
||
### Mixed 16-1024B ホットパス（self% 上位, 1890 samples）
|
||
|
||
| 順位 | 関数 | self% | 分類 |
|
||
|------|------|-------|------|
|
||
| **#1** | **free** | **29.22%** | free dispatcher |
|
||
| **#2** | **main** | **19.27%** | benchmark overhead |
|
||
| **#3** | **tiny_alloc_gate_fast** | **18.17%** | alloc gate |
|
||
| #4 | tiny_c7_ultra_refill | 6.92% | C7 ULTRA refill |
|
||
| #5 | malloc | 5.00% | malloc dispatcher |
|
||
| #6 | tiny_region_id_write_header (lto_priv) | 4.29% | header write |
|
||
| #7 | hak_super_lookup | 2.90% | segment lookup |
|
||
| #8 | hak_free_at | 2.36% | free routing |
|
||
| #9 | so_free | 2.60% | v3 free |
|
||
| #10 | so_alloc_fast | 2.46% | v3 alloc |
|
||
|
||
**スループット**:
|
||
- Mixed 16-1024B: **30.6M ops/s** (10M iter, ws=8192)
|
||
- C6-heavy 257-768B: **17.0M ops/s** (10M iter, ws=8192)
|
||
|
||
### C6-heavy ホットパス（self% 上位, 3027 samples）
|
||
|
||
| 順位 | 関数 | self% | 分類 |
|
||
|------|------|-------|------|
|
||
| **#1** | **worker_run** | **10.66%** | benchmark loop |
|
||
| **#2** | **free** | **25.13%** | free dispatcher |
|
||
| **#3** | **hak_free_at** | **19.89%** | free routing |
|
||
| #4 | hak_pool_free_v1_impl | 10.16% | pool v1 free |
|
||
| #5 | hak_pool_try_alloc_v1_impl | 10.95% | pool v1 alloc |
|
||
| #6 | pthread_once | 5.94% | initialization |
|
||
| #7 | hak_pool_free_fast_v2_impl | 3.94% | pool v2 fallback |
|
||
| #8 | hak_super_lookup | 4.39% | segment lookup |
|
||
| #9 | malloc | 3.77% | malloc dispatcher |
|
||
| #10 | hak_pool_try_alloc (part) | 0.66% | pool alloc slow |
|
||
|
||
### 分析
|
||
|
||
**Mixed 16-1024B での変化**:
|
||
- free: 29.22% (benchmark 外のディスパッチャ部分)
|
||
- tiny_alloc_gate_fast: 18.17% (前回 REBASE-1 の計測と一致)
|
||
- C7 ULTRA refill: 6.92% (前回 REBASE-1 では 7.66% だったが、ワークロードにより変動範囲内)
|
||
- C4-C7 ULTRA free 群: 個別には invisible (< 1% each) だが、合計で数%程度
|
||
- so_alloc系: 2.46% (so_alloc_fast) + 1.16% (so_alloc) = 約 3.62%
|
||
- page_of/segment: hak_super_lookup 2.90%
|
||
|
||
**C6-heavy での状況**:
|
||
- pool v1 経路が dominant: hak_pool_free_v1_impl (10.16%) + hak_pool_try_alloc_v1_impl (10.95%)
|
||
- hak_free_at: 19.89% (free routing overhead が大きい)
|
||
- hak_super_lookup: 4.39% (segment lookup)
|
||
- C6-heavy は完全に pool v1 経路を使用（前回の FREE_PATH_STATS 分析と一致）
|
||
|
||
### 次のボトルネック確定
|
||
|
||
**Mixed では**:
|
||
- **free dispatcher 全体（29.22%）** が最大
|
||
- tiny_alloc_gate_fast（18.17%）が第二
|
||
- C7 ULTRA refill（6.92%）は既に薄い部類
|
||
|
||
**C6-heavy では**:
|
||
- **hak_free_at（19.89%）** が最大の allocator 内部ボトルネック
|
||
- pool v1 alloc/free（各 10%）は構造的なコスト
|
||
- hak_super_lookup（4.39%）も削減余地あり
|
||
|
||
### 次フェーズ候補
|
||
|
||
1. **Option A: free dispatcher 最適化** (Mixed 向け)
|
||
- free() 内部の routing logic を最適化
|
||
- hak_free_at の分岐を削減
|
||
- 期待効果: Mixed で free 29% → 25% 程度に削減（+1-2M ops/s）
|
||
|
||
2. **Option B: alloc gate 最適化** (Mixed 向け)
|
||
- tiny_alloc_gate_fast（18.17%）の内部最適化
|
||
- class 判定や routing の直線化
|
||
- 期待効果: Mixed で alloc gate 18% → 15% 程度に削減（+1-2M ops/s）
|
||
|
||
3. **Option C: C6-heavy mid/pool 再設計** (C6 向け)
|
||
- hak_free_at（19.89%）の C6 専用 fast path 追加
|
||
- pool v1 の lookup overhead 削減
|
||
- 期待効果: C6-heavy で 17M → 20-25M ops/s
|
||
|
||
**推奨**: Option A または B（Mixed が本線のため）。C6-heavy は別途 mid 再設計フェーズで対応。
|
||
|
||
**次フェーズ決定**:
|
||
- Mixed: free dispatcher ≈29%, alloc gate ≈18%, C7 ULTRA refill ≈6.9%
|
||
- 次は **FREE-DISPATCHER-OPT-1** で hak_free_at 系のルーティング層を薄くする
|
||
|
||
---
|
||
|
||
### 生成ファイル
|
||
|
||
1. `/mnt/workdisk/public_share/hakmem/perf_ultra_mixed_v3.txt` - Mixed 16-1024B の complete perf report (1890 samples)
|
||
2. `/mnt/workdisk/public_share/hakmem/perf_ultra_c6_v3.txt` - C6-heavy の complete perf report (3027 samples)
|
||
3. `/mnt/workdisk/public_share/hakmem/CURRENT_TASK_PERF_REBASE3.md` - 詳細レポート
|
||
|
||
---
|
||
|
||
## Phase SO-BACKEND-OPT-1: v3 backend (so_alloc/so_free) 分解フェーズ ✅ 完了 (2025-12-11)
|
||
|
||
### 目的
|
||
|
||
PERF-ULTRA-REFILL-OPT-1a/1b で C7 ULTRA refill を +11% 最適化した後、次のボトルネック **v3 backend (so_alloc/so_free) が ~5% を占める** ことが判明。
|
||
- Mixed 16-1024B では so_alloc_fast (2.46%) + so_free (2.47%) + so_alloc (1.21%) = 合計 ~5%
|
||
- 内訳を細分化し、次フェーズで最適化すべき箇所（クラス別 hot path、メモリアクセス、分岐）を特定する
|
||
|
||
### 実装内容（完了）
|
||
|
||
✅ **Task 1: ドキュメント更新**
|
||
- CURRENT_TASK.md に Phase SO-BACKEND-OPT-1 セクション追加
|
||
- docs/analysis/SMALLOBJECT_HOTBOX_V3_DESIGN.md に「Phase SO-BACKEND-OPT-1: v3 Backend ボトルネック分析」セクション追加
|
||
- 現状認識：v3 backend の perf 内訳（alloc 2.46%, free 2.47%, alloc_slow 1.21% = 合計 5.14%）
|
||
- 実装方針：詳細 stats 構造体の定義
|
||
|
||
✅ **Task 2: v3 backend 用 stats 実装**
|
||
- ENV: `HAKMEM_SO_V3_STATS` (既存、デフォルト 0)で使用
|
||
- core/box/smallobject_hotbox_v3_box.h に新フィールド追加：
|
||
- `alloc_current_hit`: current ページから pop
|
||
- `alloc_partial_hit`: partial ページから pop
|
||
- `free_current`: current に push
|
||
- `free_partial`: partial に push
|
||
- `free_retire`: page retire
|
||
- core/smallobject_hotbox_v3.c に helper 関数実装 (6個)：
|
||
- `so_v3_record_alloc_current_hit()`
|
||
- `so_v3_record_alloc_partial_hit()`
|
||
- `so_v3_record_free_current()`
|
||
- `so_v3_record_free_partial()`
|
||
- `so_v3_record_free_retire()`
|
||
- etc.
|
||
- so_alloc_fast / so_free_fast 内に埋め込み
|
||
- デストラクタで `[ALLOC_DETAIL]` / `[FREE_DETAIL]` セクション追加
|
||
|
||
✅ **Task 3: Mixed / C7-only で計測**
|
||
- C7-only (1024B, 1M iter, ws=400, ULTRA 無効化):
|
||
- alloc_current_hit=550095 (99.99%), alloc_partial_hit=5 (0.001%)
|
||
- alloc_refill=5045 (0.9%), fallback=0
|
||
- free_retire=349 (0.09%), fallback=0, page_of_fail=0 (perfect)
|
||
- Throughput: 42.4M ops/s (baseline 62.9M with ULTRA)
|
||
- Mixed 16–1024B (1M iter, ws=400, ULTRA 無効化):
|
||
- alloc_current_hit=275089 (100%), alloc_partial_hit=0
|
||
- alloc_refill=2340 (0.85%), fallback=0
|
||
- free_retire=142 (0.07%), fallback=0, page_of_fail=0 (perfect)
|
||
- Throughput: 35.9M ops/s (baseline 43.4M with ULTRA)
|
||
|
||
✅ **Task 4: 計測分析と次フェーズ候補**
|
||
- Alloc パス評価：**alloc_current_hit ≈100% で最適化済み** → page locality 完璧
|
||
- Free パス評価：**free_retire ≈0.1% で最適化済み** → page churn 低い
|
||
- Page lookup：**page_of_fail = 0 で robust** → corner case なし
|
||
- **結論**: v3 backend のロジック部分（ページ選択、retire）は既に最適化済み
|
||
- **ボトルネック特定**: so_alloc/so_free の「内部コスト」（header write, memcpy, 分岐）が 5% overhead の主因
|
||
|
||
### Phase SO-BACKEND-OPT-2 候補（次フェーズ）
|
||
|
||
計測結果に基づく実装案（優先度順）：
|
||
|
||
| 候補 | 内容 | 期待効果 | 難易度 |
|
||
|-----|------|---------|--------|
|
||
| **Header write 削減** | carve 時一括初期化（light mode） | 1-2% | 低 |
|
||
| **Freelist carve 最適化** | pre-carved freelist を Cold IF から返却 | <1% | 中 |
|
||
| **分岐削減** | hot path 直線化、unlikely() 使用 | 0.5-1% | 中 |
|
||
| **Memcpy 削減** | inline asm や atomic で 8byte store 最適化 | 0.5-1% | 高 |
|
||
|
||
**推奨**: Phase SO-BACKEND-OPT-2 実施前に perf profile (cycles:u) で so_alloc_fast/so_free_fast を詳細計測（既存 CPU ホットパス分析に含めるのが望ましい）
|
||
|
||
### ビルド・テスト結果
|
||
- ✅ Release ビルド成功 (warning: unused variable `front_snap` は pre-existing)
|
||
- ✅ Mixed 16-1024B テスト成功（SEGV/assert なし）
|
||
- ✅ C7-only テスト成功
|
||
- ✅ Stats 出力動作確認済み
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## Phase FREE-DISPATCHER-OPT-1: free dispatcher 統計計測 (2025-12-11)
|
||
|
||
**目的**: free dispatcher（29%）の内訳を細分化
|
||
- domain 判定（tiny/mid/large）の比率
|
||
- route 判定（ULTRA/legacy/pool/v6）の比率
|
||
- ENV check / route_for_class 呼び出し回数
|
||
|
||
**方針**: 統計カウンタを追加し、挙動は変えない。次フェーズ（OPT-2）で最適化実装を判断。
|
||
|
||
**実装内容**:
|
||
- FreeDispatchStats 構造体追加（ENV gated, default OFF）
|
||
- hak_free_at / fg_classify_domain / tiny_free_gate にカウンタ埋め込み
|
||
- 挙動変更なし（計測のみ）
|
||
|
||
**ENV**: `HAKMEM_FREE_DISPATCH_STATS=1` で有効化（デフォルト 0）
|
||
|
||
**計測結果**:
|
||
- Mixed: total=8,081, route_calls=267,967, env_checks=9
|
||
- BENCH_FAST_FRONT により大半は早期リターン
|
||
- route_for_class は主に alloc 側で呼ばれる
|
||
- ENV check は初期化時の 9回のみ
|
||
- C6-heavy: total=500,099, route_calls=1,034, env_checks=9
|
||
- fg_classify_domain に到達する free が多い
|
||
- route_for_class 呼び出しは極小（snapshot 効果）
|
||
|
||
**結論**:
|
||
- ENV check は既に十分最適化されている（初期化時のみ）
|
||
- route_for_class は alloc 側での呼び出しが主で、free 側は snapshot で O(1)
|
||
- 次フェーズ（OPT-2）では別のアプローチを検討（domain 判定の早期化など）
|
||
|
||
**発見**: FREE_DISPATCH_STATS より ENV/route は初期化時にしか呼ばれていない。route_calls=267,967 はほぼ alloc 側から。
|
||
|
||
---
|
||
|
||
## Phase ALLOC-GATE-OPT-1: tiny_alloc_gate_fast 統計計測 (2025-12-11)
|
||
|
||
**目的**: alloc gate（18%）の内訳を細分化
|
||
- size→class 変換の回数
|
||
- route_for_class 呼び出し回数
|
||
- alloc-side ENV check 回数
|
||
- クラス別分布（C0〜C7）
|
||
|
||
**方針**: 統計カウンタを追加し、挙動は変えない。次フェーズ（OPT-1B）で最適化実装を判断。
|
||
|
||
**実装内容**:
|
||
- AllocGateStats 構造体追加（size2class/route/env/class分布）
|
||
- malloc_tiny_fast 内にカウンタ埋め込み
|
||
- ENV: HAKMEM_ALLOC_GATE_STATS (default 0)
|
||
- 挙動変更なし（計測のみ）
|
||
|
||
**計測結果**:
|
||
- Mixed: total=542,033, size2class=0, route_calls=0, env_checks=275,089, C4-C7=95.2%
|
||
- ✅ size_to_class / route_for_class は **完全削減済み**（LUT 効果）
|
||
- ✅ C4-C7 が 95% → ULTRA fast path が有効
|
||
- env_checks ≈ c7_calls → C7 ULTRA の ENV gate が毎回呼ばれる（構造的コスト）
|
||
- C6-heavy: total=11 → malloc_tiny_fast はほぼ通らない（mid/pool 主体）
|
||
|
||
**結論**:
|
||
- ✅ alloc gate は **既に十分最適化済み**（LUT + ULTRA で削減済み）
|
||
- ❌ さらなる最適化余地は小さい（env_checks は軽量化済み、数%以下の効果）
|
||
- 次フェーズでは **free dispatcher (29%)** や **C7 ULTRA refill (7%)** など、他のボトルネックを狙う
|
||
|
||
**詳細**: `docs/analysis/ALLOC_GATE_ANALYSIS.md` 参照
|
||
|
||
---
|
||
|
||
## Phase PERF-ULTRA-REBASE-4: 再計測と確認 (2025-12-11)
|
||
|
||
**目的**: dispatcher と alloc gate が既に最適化されていることを確認した後、実際に新しい perf profile を取得
|
||
|
||
**計測条件**:
|
||
- ENV: 全て OFF（デフォルト、stats 無しで baseline）
|
||
- ワークロード: Mixed 16-1024B, 10M iter, ws=8192
|
||
- perf record: cycles:u, F 5000, dwarf call-graph
|
||
|
||
### ホットパス分析 (self%, 1K samples)
|
||
|
||
| 順位 | 関数/パス | self% | 変化 |
|
||
|------|----------|-------|------|
|
||
| **#1** | **free** | **25.48%** | −0.74% vs REBASE-3 |
|
||
| **#2** | **malloc** | **21.13%** | −0% (同等) |
|
||
| **#3** | **tiny_c7_ultra_alloc** | **7.66%** | ±0% (同等) |
|
||
| #4 | tiny_c7_ultra_free | 3.50% | −0.6% (最適化効果) |
|
||
| #5 | so_free | 2.47% | (新規visible) |
|
||
| #6 | so_alloc_fast | 2.39% | (新規visible) |
|
||
| **#7** | **tiny_c7_ultra_page_of** | **1.78%** | **NEW: refill path** |
|
||
| #8 | so_alloc | 1.21% | (新規visible) |
|
||
| #9 | classify_ptr | 1.15% | (新規visible) |
|
||
|
||
### 統計情報（Mixed 1M iter, ws=400）
|
||
|
||
**Alloc Gate Stats**:
|
||
```
|
||
total=542,019 calls
|
||
size2class=0 calls ✅ (完全削減)
|
||
route_calls=0 calls ✅ (完全削減)
|
||
env_checks=275,089 (構造的コスト)
|
||
class分布: C7=50.8%, C6=25.3%, C5=12.7%, C4=6.4%, C2-C3=4.8%
|
||
```
|
||
|
||
**Free Dispatcher Stats**:
|
||
```
|
||
total=8,081 calls
|
||
tiny=0, mid=8,081, large=0 (全て mid パス)
|
||
ultra=0 (ULTRA が fre dispatcher を bypass している)
|
||
tiny_legacy=7, pool=0, v6=0
|
||
route_calls=267,954 (大部分は alloc 側から呼ばれている)
|
||
env_checks=9 (初期化時のみ)
|
||
```
|
||
|
||
### 分析
|
||
|
||
**確認事項**:
|
||
1. **Dispatcher (25.48%) は既に最適化済み**
|
||
- route_for_class は 9 回のみ（初期化時）
|
||
- 25% はファンクション呼び出しのコスト（architecture level）
|
||
|
||
2. **Alloc Gate (21.13%) は既に最適化済み**
|
||
- size_to_class = 0 calls (LUT)
|
||
- route_for_class = 0 calls (ULTRA enabled)
|
||
- env_checks = 275K はC7 ULTRA の enable check （unavoidable）
|
||
|
||
3. **新しいボトルネック**:
|
||
- C7 ULTRA refill (tiny_c7_ultra_page_of) が 1.78% で新規にvisible
|
||
- so_alloc/so_free が合計 ~5%
|
||
- classify_ptr が 1.15%
|
||
|
||
### スループット
|
||
|
||
- **Mixed 16-1024B**: 39.5M ops/s (iters=1M, ws=400)
|
||
- **比較**: REBASE-3 の 30.6M ops/s（iters=10M, ws=8192）とは別ワークロード
|
||
|
||
### 次フェーズ候補
|
||
|
||
**Option A: C7 ULTRA refill 最適化**
|
||
- tiny_c7_ultra_page_of が 1.78%
|
||
- Segment learning / page lookup の refill パスを最適化
|
||
- 期待: refill パス削減で全体 1-2%
|
||
|
||
**Option B: Architectural Level の最適化**
|
||
- free dispatcher (25%) + malloc dispatcher (21%) = 46%
|
||
- 現状は C API (malloc/free) の呼び出しコスト
|
||
- 例: ホットパス全体を inlined dispatcher で再設計
|
||
- リスク: 大規模な設計変更
|
||
|
||
**Option C: so_alloc/so_free 系 (~5%) の削減**
|
||
- v3 backend の最適化
|
||
- classify_ptr (1.15%) の削減
|
||
- 期待: 1-2M ops/s
|
||
|
||
**推奨**: Option A（C7 ULTRA refill）から着手。dispatcher/gate の 46% は architecture 的な必要コストで、難易度 vs 効果の観点から現状は受け入れるべき。
|
||
|
||
### 結論
|
||
|
||
- **dispatcher + gate**: 計 46% → 既に最適化済み（ENV/route snapshot 化完了）
|
||
- **C7 ULTRA 内部**: alloc 7.66% + free 3.50% + refill 1.78% = 12.94%
|
||
- **次のターゲット**: C7 ULTRA refill パス（1.78%）からの削減開始
|
||
|
||
---
|
||
|
||
## Phase PERF-ULTRA-REFILL-OPT-1a/1b 実装完了 (2025-12-11)
|
||
|
||
### 目的
|
||
|
||
C7 ULTRA refill パス（tiny_c7_ultra_page_of の 1.78%）を最適化し、全体のスループット向上を実現
|
||
|
||
### 実装内容
|
||
|
||
**Phase 1a: Page Size Macro化**
|
||
```c
|
||
// tiny_c7_ultra_segment.c に追加
|
||
#define TINY_C7_ULTRA_PAGE_SHIFT 16 // 64KiB = 2^16
|
||
|
||
// 修正: tiny_c7_ultra_page_of で division を shift に
|
||
uint32_t idx = (uint32_t)(offset >> TINY_C7_ULTRA_PAGE_SHIFT);
|
||
|
||
// 修正: refill/free で multiplication を shift に
|
||
tls->seg_end = tls->seg_base + ((size_t)seg->num_pages << TINY_C7_ULTRA_PAGE_SHIFT);
|
||
uint8_t* base = (uint8_t*)seg->base + ((size_t)chosen << TINY_C7_ULTRA_PAGE_SHIFT);
|
||
```
|
||
|
||
**Phase 1b: Segment Learning 移動**
|
||
```c
|
||
// 従来: free初回で segment_from_ptr() を呼び出して学習
|
||
if (unlikely(tls->seg_base == 0)) {
|
||
seg = tiny_c7_ultra_segment_from_ptr(ptr); // <- deleted
|
||
...
|
||
}
|
||
|
||
// 最適化後: segment learning は alloc refill時に移動
|
||
// free では seg_base/seg_end が既に埋まっている前提
|
||
// (normal pattern: alloc → free なので安全)
|
||
```
|
||
|
||
### ベンチマーク結果
|
||
|
||
**Mixed 16-1024B (1M iter, ws=400)**:
|
||
|
||
| フェーズ | Throughput | 改善 |
|
||
|---------|-----------|------|
|
||
| Baseline | 39.5M ops/s | baseline |
|
||
| Phase 1a | 39.5M ops/s | ±0% (誤差) |
|
||
| Phase 1b | 42.3M ops/s | +7.1% |
|
||
| **3回平均** | **43.9M ops/s** | **+11.1%** |
|
||
|
||
**実測:**
|
||
- Run 1: 42.9M ops/s
|
||
- Run 2: 45.0M ops/s
|
||
- Run 3: 43.7M ops/s
|
||
|
||
### 最適化の詳細
|
||
|
||
**1. Division → Bit Shift の効果**
|
||
- tiny_c7_ultra_page_of での `offset / seg->page_size` を `offset >> 16` に変更
|
||
- refill/free での `num_pages * page_size` を bit shift に変更
|
||
- 各 division ～2-3 cycles 削減 × 複数呼び出し = 累積効果
|
||
|
||
**2. Segment Learning 削除の効果**
|
||
- free 初回での tiny_c7_ultra_segment_from_ptr() call を削除
|
||
- segment learning は alloc refill時に既に実施済み
|
||
- 通常パターン（alloc → free）では全く影響なし
|
||
- per-thread 1 回の segment_from_ptr() call + 1 回の pointer comparison 削減
|
||
|
||
### 合算効果
|
||
|
||
- Phase 1a: 数% 削減（見えにくいが累積）
|
||
- Phase 1b: visible な削減（unlikely cold path 完全削除）
|
||
- **Total: +11.1%** = dispatch/gate 優化 (46%) の次に大きい改善
|
||
|
||
### 次フェーズ
|
||
|
||
現在の成功：
|
||
- C7 ULTRA 内部優化で +11% 達成
|
||
- dispatcher/gate (46%) は既に最適化済み
|
||
- 新規ボトルネック: so_alloc/so_free (合計 ~5%)
|
||
|
||
候補:
|
||
- **Option A**: so_alloc/so_free 最適化 → v3 backend
|
||
- **Option B**: classify_ptr (1.15%) 削減
|
||
- **Option C**: 新規サイズクラス (C3/C2 ULTRA) → TLS L1 汚染リスク
|
||
|
||
推奨: Option A（v3 backend 最適化）を検討
|
||
|