Files

Moe Charm (CI) d0b931b197 Phase 3 C1: TLS Prefetch Implementation - NEUTRAL Result (Research Box)

Step 1 & 2 Complete:
- Implemented: core/front/malloc_tiny_fast.h prefetch (lines 264-267, 331-334)
  - LEGACY path prefetch of g_unified_cache[class_idx] to L1
  - ENV gate: HAKMEM_TINY_PREFETCH=0/1 (default OFF)
  - Conditional: only when prefetch enabled + route_kind == LEGACY

- A/B test (Mixed 10-run): PREFETCH=0 (39.33M) → =1 (39.20M) = -0.34% avg
  - Median: +1.28% (within ±1.0% neutral range)
  - Result: 🔬 NEUTRAL (research box, default OFF)

Decision: FREEZE as research box
- Average -0.34% suggests prefetch overhead > benefit
- Prefetch timing too late (after route_kind selection)
- TLS cache access is already fast (head/tail indices)
- Actual memory wait happens at slots[] array access (after prefetch)

Technical Learning:
- Prefetch effectiveness depends on L1 miss rate at access time
- Inserting prefetch after route selection may be too late
- Future approach: move prefetch earlier or use different target

Next: Phase 3 C2 (Metadata Cache Optimization, expected +5-10%)

🤖 Generated with Claude Code

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

2025-12-13 19:01:57 +09:00

2.9 KiB

Raw Blame History

Phase 3 C1: TLS Prefetch（Tiny alloc hot path）設計メモ

目的

Phase 2-3（B3/B4/C3）で「形（分岐・I-cache）」は勝ち形に寄った。次は L1D miss / pointer chase を減らすための “軽い prefetch” を A/B する。

対象は policy ではなく、実際の alloc が触る TLS cache:

TinyUnifiedCache g_unified_cache[class]（core/front/tiny_unified_cache.h）
必要なら cache->slots[] の先頭付近（head/tail 周辺）

非目標

ルーティングやアルゴリズム変更はしない（prefetch は “ヒント” のみ）
常時ログは禁止（必要なら HAKMEM_DEBUG_COUNTERS のみ）
“当たり前に速い” ことは期待しない（NO-GO なら即 freeze）

Box Theory（箱割り）

L0: Env（戻せる）

既存 ENV を使用: HAKMEM_TINY_PREFETCH=0/1（default 0）
目的: prefetch の on/off を即切替（回帰時に即戻せる）

L1: PrefetchBox（境界: 1 箇所）

責務: malloc の hot path で 1 回だけ prefetch を実行する。実装場所は “入口” に固定（malloc_tiny_fast_for_class()）。

候補 API（header-only で OK）:

tiny_alloc_prefetch_tls_cache(class_idx, route_kind)
- route_kind == SMALL_ROUTE_LEGACY のときだけ g_unified_cache[class_idx] を prefetch
- 余計な prefetch を避ける（C6=MID 等で無駄撃ちしない）

実装指示（小パッチ順）

Prefetch 実装（最小）
- 追加箇所: core/front/malloc_tiny_fast.h の malloc_tiny_fast_for_class()
- 条件:
  - tiny_env_cfg()->tiny_prefetch == 1
  - route_kind == SMALL_ROUTE_LEGACY
- 実行:
  - __builtin_prefetch(&g_unified_cache[class_idx], 0, 3);
- 注意:
  - g_unified_cache は TLS なので “当たる” 前提で入れすぎない（1 回だけ）
Optional（勝ち筋が見えたら）
- TinyUnifiedCache* cache = &g_unified_cache[class_idx];
- if (cache->slots) __builtin_prefetch(&cache->slots[cache->head], 0, 3);
- ※ ただしロードが増えるので、まずは 1. の最小で A/B
ドキュメント
- docs/specs/ENV_VARS_COMPLETE.md に HAKMEM_TINY_PREFETCH を追記
- docs/analysis/PHASE3_CACHE_LOCALITY_NEXT_INSTRUCTIONS.md の C1 をこの設計に合わせて更新

A/B（GO/NO-GO）

Mixed（HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE）10-run
- 比較: HAKMEM_TINY_PREFETCH=0 vs =1
- GO: +1.0% 以上
- NO-GO: -1.0% 以下 → freeze
- ±1% は “研究箱維持”（デフォルトOFFのまま）

期待値の現実

prefetch は “刺さるときだけ刺さる”。勝ち筋は「route 形の整理（B3/B4/C3）で instruction が減った結果、メモリ待ちが相対的に目立つ」状態になっていること。もし勝てないなら、次は C2（metadata locality）へ進む。

2.9 KiB Raw Blame History Unescape Escape