Files
hakmem/docs/analysis/PHASE3_C1_TLS_PREFETCH_1_DESIGN.md
Moe Charm (CI) 19056282b6 Phase 3 D2: Wrapper Env Cache - [DECISION: NO-GO]
Target: Reduce wrapper_env_cfg() overhead in malloc/free hot path
- Strategy: Cache wrapper env configuration pointer in TLS
- Approach: Fast pointer cache (TLS caches const wrapper_env_cfg_t*)

Implementation:
- core/box/wrapper_env_cache_env_box.h: ENV gate (HAKMEM_WRAP_ENV_CACHE)
- core/box/wrapper_env_cache_box.h: TLS cache layer (wrapper_env_cfg_fast)
- core/box/hak_wrappers.inc.h: Integration into malloc/free hot paths
- ENV gate: HAKMEM_WRAP_ENV_CACHE=0/1 (default OFF)

A/B Test Results (Mixed, 10-run, 20M iters):
- Baseline (D2=0): 46.52M ops/s (avg), 46.47M ops/s (median)
- Optimized (D2=1): 45.85M ops/s (avg), 45.98M ops/s (median)
- Improvement: avg -1.44%, median -1.05% (DECISION: NO-GO)

Analysis:
- Regression cause: TLS cache adds overhead (branch + TLS access)
- wrapper_env_cfg() is already minimal (pointer return after simple check)
- Adding TLS caching layer makes it worse, not better
- Branch prediction penalty outweighs any potential savings

Cumulative Phase 2-3:
- B3: +2.89%, B4: +1.47%, C3: +2.20%
- D1: +1.06% (opt-in), D2: -1.44% (NO-GO)
- Total: ~7.2% (excluding D2)

Decision: FREEZE as research box (default OFF, regression confirmed)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-13 22:03:27 +09:00

3.3 KiB
Raw Blame History

Phase 3 C1: TLS PrefetchTiny alloc hot path設計メモ

目的

Phase 2-3B3/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/1default 0
  • 目的: prefetch の on/off を即切替(回帰時に即戻せる)

L1: PrefetchBox境界: 1 箇所)

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

候補 APIheader-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 等で無駄撃ちしない)

実装指示(小パッチ順)

  1. Prefetch 実装(最小)

    • 追加箇所: core/front/malloc_tiny_fast.hmalloc_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 回だけ)
  2. Optional勝ち筋が見えたら

    • TinyUnifiedCache* cache = &g_unified_cache[class_idx];
    • if (cache->slots) __builtin_prefetch(&cache->slots[cache->head], 0, 3);
    • ※ ただしロードが増えるので、まずは 1. の最小で A/B
  3. ドキュメント

    • docs/specs/ENV_VARS_COMPLETE.mdHAKMEM_TINY_PREFETCH を追記
    • docs/analysis/PHASE3_CACHE_LOCALITY_NEXT_INSTRUCTIONS.md の C1 をこの設計に合わせて更新

A/BGO/NO-GO

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

期待値の現実

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


結果A/B

判定: 🔬 NEUTRAL研究箱維持、default OFF

  • Mixed 10-run:
    • HAKMEM_TINY_PREFETCH=0: avg 39.34M
    • HAKMEM_TINY_PREFETCH=1: avg 39.20Mavg -0.34% / median +1.28%

補足:

  • 既存実装は “LEGACY 分岐の直前” に prefetch を入れており lead time が短い。
  • 再挑戦するなら、prefetch 位置を より早い入口malloc_tiny_fast_for_class() 冒頭など)に動かして A/B を取り直す。