hakmem/docs/analysis/CURRENT_TASK_ARCHIVE.md

CURRENT_TASK Archive

このファイルは、整理前の CURRENT_TASK.md（履歴ログを含む）をそのまま保存したアーカイブ。 現行の「次にやること」は CURRENT_TASK.md を正とする。

---

CURRENT_TASK（Rolling）

0) 今の「正」（Phase 48 rebase）

• 性能比較の正: FAST build（make perf_fast）
• 安全・互換の正: Standard build（make bench_random_mixed_hakmem）
• 観測の正: OBSERVE build（make perf_observe）
• スコアカード: docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md
• 計測の正（Mixed 10-run）: scripts/run_mixed_10_cleanenv.sh（ITERS=20000000 WS=400）

1) 現状（最新スナップショット）

• FAST v3: 58.478M ops/s（mimalloc の 48.34% Phase 59b rebase, Speed-first）
• FAST v3 + PGO: 59.80M ops/s（mimalloc の 49.41% — NEUTRAL research box, +0.27% mean, +1.02% median）
• Standard: 53.50M ops/s（mimalloc の 44.21% 要 rebase）
• mimalloc baseline: 120.979M ops/s (Phase 59b rebase, CV 0.90%)

M1 (50%) Milestone: Approaching

• Current ratio: 48.34% (Speed-first mode)
• Gap to 50%: -1.66% (within hakmem CV 2.52%)
• Profile change: Balanced → Speed-first (Phase 57 60-min soak winner)
• Stability: hakmem CV 2.52% vs mimalloc CV 0.90% in Phase 59b
• Production readiness: All metrics meet or exceed targets

※詳細は docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md を正とする（ここは要点だけ）。 ※Phase 59b rebase: hakmem stable (58.478M), mimalloc +1.59% variance, ratio 49.13% → 48.34% (-0.79pp)

2) 原則（Box Theory 運用）

• 変更は箱で分ける（ENV / build flag で戻せる）
• 境界は 1 箇所（変換点を増やさない）
• 削除して速くする（link-out / 大きい削除）は封印（layout/LTO で符号反転する）
  • ✅ compile-out（#if HAKMEM_*_COMPILED / #if HAKMEM_BENCH_MINIMAL）は許容
  • ❌ Makefile から .o を外す / コード物理削除は原則しない（Phase 22-2 NO-GO）
• A/B は 同一バイナリでトグル（ENV / build flag）。別バイナリ比較は layout が混ざる。

3) 次の指示書

Phase 62A: 完了（NEUTRAL -0.71%, research box）

• 指示書: "箱化モジュール化 inline レガシー削除 ソースコード綺麗綺麗"

• 実装: C7 ULTRA alloc hot path の dependency chain trim

  • ENV gate: HAKMEM_C7_ULTRA_ALLOC_DEPCHAIN_OPT (default: 0, OFF)
  • 最適化: per-call header_light check を排除 → TLS headers_initialized を活用
  • 期待: +1-3% → 実績: -0.71% (NEUTRAL)

• 結果詳細: docs/analysis/PHASE62A_C7_ULTRA_DEPCHAIN_OPT_RESULTS.md

• 判定: NEUTRAL、research box化（default OFF）

• 原因分析:

  1. LTO mode では header_light 関数呼び出しが既に inline 済み（コスト 0）
  2. TLS access は memory load + offset calc が必要（機能的に同等か遅い）
  3. Layout tax: コード追加による I-cache disruption (-0.71% loss)
  4. Phases 43/46A/47 と同じパターン（micro-opt on optimized path は失敗傾向）

• 教訓:

  • Function call overhead (LTO) < TLS access overhead
  • 5.18% stack % は optimizable hotspot ではない（既に最適化済み）
  • 48.34% の gap は algorithmic、micro-opt では埋め難い

Phase 62B+: 次の方針（TBD）

• Option A: tiny_region_id_write_header optimization (+0.5-1.5%, very high risk)
• Option B: Production readiness pivot（48.34% accept、documentation/telemetry focus）
• Option C: Algorithmic redesign（batching, prefault strategy、post-50% milestone）

詳細: docs/analysis/PHASE62_NEXT_TARGET_ANALYSIS.md + PHASE62A_C7_ULTRA_DEPCHAIN_OPT_RESULTS.md

Phase 61: 完了（NEUTRAL +0.31%, research box）

• 指示書: Phase 59b と Phase 61 を順番に実装する指示
• 結果: docs/analysis/PHASE61_C7_ULTRA_HEADER_LIGHT_RESULTS.md
• 実装: docs/analysis/PHASE61_C7_ULTRA_HEADER_LIGHT_IMPLEMENTATION.md
• 狙い: C7 ULTRA alloc hit path で header write を skip（refill 時に 1回だけ書く）
• 判定: Mixed 10-run mean で +0.31% → NEUTRAL（baseline: 59.54M ops/s, treatment: 59.73M ops/s, CV 2.66% vs 1.53%）
• 原因: (1) Header write は期待より小さい hotspot（2.32% vs Phase 42 の 4.56%）、(2) Mixed workload で C7 specific optimization が希釈、(3) Treatment の variance 増大（CV 2.66%）、(4) Header-light mode が hot path に branch 追加
• 保持: ENV gate で OFF のまま研究箱として保持（HAKMEM_TINY_C7_ULTRA_HEADER_LIGHT=0）
• 教訓: Micro-optimization は precise profiling 必要（cycle count だけでなく IPC/cache-miss も）。Mixed workload は class-specific optimization の効果を薄める。

Phase 59b: 完了（COMPLETE, measurement-only, zero code changes）

• 指示書: Phase 59b と Phase 61 を順番に実装する指示
• 結果: docs/analysis/PHASE59B_SPEED_FIRST_REBASE_RESULTS.md
• 狙い: Speed-first mode（MIXED_TINYV3_C7_SAFE）で baseline を rebase、M1 (50%) baseline 更新
• 判定: COMPLETE（hakmem: 58.478M ops/s, mimalloc: 120.979M ops/s, ratio: 48.34%）
• Profile 変更: Balanced → Speed-first（Phase 57 60-min soak で Speed-first が全指標で勝利）
• 新 baseline: 48.34% of mimalloc (Phase 59 比 -0.79pp, mimalloc variation が主因)
• 推奨: Speed-first (MIXED_TINYV3_C7_SAFE) を canonical default として採用

Phase 60: 完了（NO-GO -0.46%, research box）

• 指示書: docs/analysis/PHASE60_ALLOC_PASSDOWN_SSOT_DESIGN_AND_INSTRUCTIONS.md
• 結果: docs/analysis/PHASE60_ALLOC_PASSDOWN_SSOT_RESULTS.md
• 実装: docs/analysis/PHASE60_ALLOC_PASSDOWN_SSOT_IMPLEMENTATION.md
• 狙い: alloc 側の重複計算（policy snapshot / route/heap 判定）を入口 1回に集約し、下流へ pass-down（Phase 19-6C の alloc 版）
• 判定: Mixed 10-run mean で -0.46% → NO-GO（baseline: 60.05M ops/s, treatment: 59.77M ops/s）
• 原因: (1) 追加 branch check if (alloc_passdown_ssot_enabled()) のオーバーヘッド、(2) オリジナルパスは既に early-exit で重複を回避しているため upfront 計算が逆効果、(3) struct pass-down の ABI cost
• 保持: ENV gate で OFF のまま研究箱として保持（HAKMEM_ALLOC_PASSDOWN_SSOT=0）
• 教訓: SSOT パターンは重複計算が多い場合に有効（Free 側 Phase 19-6C は +1.5%）。Early-exit が既に最適化されている場合は逆効果。

Phase 50: 完了（COMPLETE, measurement-only, zero code changes）

Phase 50 で運用安定性測定スイート（Operational Edge Stability Suite）を確立した。

詳細: docs/analysis/PHASE50_OPERATIONAL_EDGE_STABILITY_SUITE_RESULTS.md

成果:

• Syscall budget: 9e-8/op (EXCELLENT) - Phase 48 の値を SSOT 化
• RSS stability: 全 allocator で ZERO drift（5分 soak, EXCELLENT）
• Throughput stability: 全 allocator で positive drift (+0.8%-0.9%) & low CV (1.5%-2.1%, EXCELLENT)
• Tail latency: TODO（Phase 51+ で実装）

Phase 51: 完了（COMPLETE, measurement-only, zero code changes）

Phase 51 で単一プロセス soak test により allocator 状態を保持したまま RSS/throughput drift を測定し、tail latency 測定方針を決定した。

詳細: docs/analysis/PHASE51_SINGLE_PROCESS_SOAK_AND_TAIL_PLAN_RESULTS.md

成果:

• RSS stability: 全 allocator で ZERO drift（5分 single-process soak, EXCELLENT）
• Throughput stability: 全 allocator で minimal drift (<1.5%) & exceptional CV (0.39%-0.50%, EXCELLENT)
• hakmem CV: 0.50% (Phase 50 の 3× 改善、全 allocator 中最高の single-process 安定性)
• Tail latency 測定方針: Option 2 (perf-based) を Phase 52 で実装決定

Phase 52: 完了（COMPLETE, measurement-only, zero code changes）

Phase 52 で epoch throughput proxy により tail latency を測定し、hakmem の variance 課題を定量化した。

詳細: docs/analysis/PHASE52_TAIL_LATENCY_PROXY_RESULTS.md

成果:

• Tail latency baseline 確立: epoch throughput 分布を latency proxy として使用
• hakmem std dev: 7.98% of mean（mimalloc 2.28%, system 0.77%）
• p99/p50 ratio: 1.024（tail behavior は良好だが variance が課題）
• 測定スクリプト: scripts/calculate_percentiles.py (作成済み)

Phase 53: 完了（COMPLETE, measurement-only, zero code changes）

Phase 53 で RSS tax の原因を切り分け、speed-first 設計の妥当性を確認した。

詳細: docs/analysis/PHASE53_RSS_TAX_TRIAGE_RESULTS.md

成果:

• RSS tax の原因: Allocator design（persistent superslabs）、bench warmup ではない
• 内訳: SuperSlab backend ~20-25 MB (60-75%), tiny metadata 0.04 MB (0.1%)
• Trade-off: +10x syscall efficiency, -17x memory efficiency vs mimalloc
• 判定: ACCEPTABLE (速さ優先戦略として妥当、drift なし、predictable)

Phase 54: 完了（COMPLETE, NEUTRAL research box）

Phase 54 で Memory-Lean mode を実装（opt-in、RSS <10MB を狙う別プロファイル）。

詳細: docs/analysis/PHASE54_MEMORY_LEAN_MODE_RESULTS.md

成果:

• 実装: 完了（ENV gate, release policy, prewarm suppression, decommit logic, stats counters）
• Box Theory: ✅ PASS (single conversion point, ENV-gated, reversible, DSO-safe)
• Prewarm suppression: HAKMEM_SS_MEM_LEAN=1 で初期 superslab 割り当てをスキップ
• Decommit logic: Empty superslab を madvise(MADV_FREE) で RSS 削減（munmap せず VMA 保持）
• Stats counters: lean_decommit, lean_retire 追加（HAKMEM_SS_OS_STATS=1 で表示）

判定: NEUTRAL (research box)

• 実装は完了（コンパイル成功、runtime エラーなし）
• Extended A/B testing（30-60分 soak）で RSS/throughput trade-off 要計測
• Opt-in feature として保持（memory-constrained 環境向け）

実装ドキュメント: docs/analysis/PHASE54_MEMORY_LEAN_MODE_IMPLEMENTATION.md

Phase 55: 完了（COMPLETE, GO — Memory-Lean Mode Validation）

Phase 55 で Memory-Lean mode を3段階 progressive testing（60s → 5min → 30min）により validation し、LEAN+OFF が production-ready と判定（GO）。

詳細: docs/analysis/PHASE55_MEMORY_LEAN_MODE_VALIDATION_MATRIX.md

成果:

• Winner: LEAN+OFF (prewarm suppression only, no decommit)
• Throughput: +1.2% vs baseline (56.8M vs 56.2M ops/s, 30min test)
• RSS: 32.88 MB (stable, 0% drift)
• Stability: CV 5.41% (better than baseline 5.52%)
• Syscalls: 1.25e-7/op (8x under budget <1e-6/op)
• No decommit overhead: Prewarm suppression only, zero syscall tax

Validation Strategy:

• Step 0 (60s): 4 modes smoke test → all PASS, select top 2
• Step 1 (5min): Top 2 stability check → LEAN+OFF dominates
• Step 2 (30min): Final candidate production validation → GO

判定: GO (production-ready)

• LEAN+OFF is faster than baseline (+1.2%, no compromise)
• Zero decommit syscall overhead (simplest lean mode)
• Perfect RSS stability (0% drift, better CV than baseline)
• Opt-in safety (HAKMEM_SS_MEM_LEAN=0 disables all lean behavior)

Use Cases:

• Speed-first (default): HAKMEM_SS_MEM_LEAN=0 (current production mode)
• Memory-lean (opt-in): HAKMEM_SS_MEM_LEAN=1 HAKMEM_SS_MEM_LEAN_DECOMMIT=OFF (production-ready)

Phase 56+: 次（TBD）

• 候補A: Variance reduction（tail latency 改善、Phase 52 で課題特定済み）
• 候補B: Throughput gap closure（mimalloc 50% → 55%、algorithmic improvement 必要）
• 候補C: LEAN+FREE/DONTNEED extended validation（extreme memory pressure scenarios）

運用安定性スコアカード（5分 single-process soak, Phase 51）:

Metric	hakmem FAST	mimalloc	system malloc	Target
Throughput	59.95 M ops/s	122.38 M ops/s	85.31 M ops/s	-
Syscall budget	9e-8/op	Unknown	Unknown	<1e-7/op
RSS drift	+0.00%	+0.00%	+0.00%	<+5%
Throughput drift	+1.20%	-0.47%	+0.38%	>-5%
Throughput CV	0.50%	0.39%	0.42%	~1-2%
Peak RSS	32.88 MB	1.88 MB	1.88 MB	-

Status: ✅ PASS（全指標が target を満たす、CV は Phase 50 の 3× 改善）

勝ち筋:

• Syscall budget: 9e-8/op は世界水準（10x better than acceptable threshold）
• Throughput CV: 0.50% は Phase 50 (1.49%) の 3× 改善、single-process 安定性は exceptional
• RSS drift: ZERO（メモリリーク/断片化なし、single-process でも安定）

既知の税:

• Peak RSS: 33 MB vs 2 MB（metadata tax, Phase 44 で確認済み）
• Throughput: mimalloc の 48.99%（M1 (50%) 未達）

Phase 51 key findings:

• Single-process soak は multi-process (Phase 50) より 3-5× 低い CV を実現（cold-start variance 除去）
• hakmem CV 0.50% は全 allocator 中最高の single-process 安定性
• Tail latency 測定は Option 2 (perf-based) を Phase 52 で実装

Phase 49: 完了（COMPLETE, NO-GO, analysis-only, zero code changes）

Phase 49 で Top hotspot の dependency chain を分析したが、既に最適化済みで改善余地なしと判定（NO-GO）。

詳細: docs/analysis/PHASE49_DEPCHAIN_OPT_TINY_HEADER_AND_UC_PUSH_RESULTS.md

Phase 48: 完了（COMPLETE, measurement-only）

Phase 48 で競合 allocator を同一条件で再計測し、syscall budget と長時間安定性の測定ルーチンを確立。

詳細: docs/analysis/PHASE48_REBASE_ALLOCATORS_AND_STABILITY_SUITE_RESULTS.md

Phase 52: 完了（tail proxy）

• 指示書: docs/analysis/PHASE52_TAIL_LATENCY_PROXY_INSTRUCTIONS.md
• 結果: docs/analysis/PHASE52_TAIL_LATENCY_PROXY_RESULTS.md
• 注意: percentile の定義（throughput tail は低い側 / latency は per-epoch から）が重要。scripts/analyze_epoch_tail_csv.py を正とする。

Phase 53: 完了（RSS tax triage）

• 指示書: docs/analysis/PHASE53_RSS_TAX_TRIAGE_INSTRUCTIONS.md
• 結果: docs/analysis/PHASE53_RSS_TAX_TRIAGE_RESULTS.md

Phase 54–57: 完了（Lean mode 実装 + 長時間 validation）

• 指示書/設計/結果はスコアカード（docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md）を正とする
• 実装: docs/analysis/PHASE54_MEMORY_LEAN_MODE_IMPLEMENTATION.md
• 最終結果: docs/analysis/PHASE57_BALANCED_MODE_60MIN_SOAK_AND_SYSCALLS_RESULTS.md

Phase 56: 完了（COMPLETE, GO — LEAN+OFF promotion / historical）

Phase 56 で LEAN+OFF（prewarm suppression）を "Balanced mode" として production 推奨にした。

詳細: docs/analysis/PHASE56_PROMOTE_LEAN_OFF_RESULTS.md

成果:

• Implementation (historical): core/bench_profile.h に LEAN+OFF を MIXED_TINYV3_C7_SAFE デフォルトとして追加
• FAST build validation: 59.84 M ops/s (mean), CV 2.21% (+1.2% vs Phase 55 baseline)
• Standard build validation: 60.48 M ops/s (mean), CV 0.81% (excellent stability)
• Syscall budget: 5.00e-08/op (identical to baseline, zero overhead)
• Profile comparison: Speed-first (59.12 M ops/s, opt-in) vs Balanced (59.84 M ops/s, default)

判定: GO (production-ready)（ただし Phase 57 の 60-min/tail では Speed-first が優位）

実装ドキュメント: docs/analysis/PHASE56_PROMOTE_LEAN_OFF_IMPLEMENTATION.md 結果ドキュメント: docs/analysis/PHASE56_PROMOTE_LEAN_OFF_RESULTS.md Scorecard更新: docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md (Phase 56 section added)

Phase 57: 完了（COMPLETE, GO — 60-min soak + syscalls final validation）

Phase 57 で Balanced mode（LEAN+OFF）を 60分 soak + tail proxy + syscall budget により最終確認し、production-ready と判定（GO）。

詳細: docs/analysis/PHASE57_BALANCED_MODE_60MIN_SOAK_AND_SYSCALLS_RESULTS.md

成果:

• 60-min soak: Balanced 58.93M ops/s (CV 5.38%), Speed-first 60.74M ops/s (CV 1.58%)
• RSS drift: 0.00% (両モード、60分で完全安定)
• Throughput drift: 0.00% (両モード、性能劣化なし)
• 10-min tail proxy: Balanced CV 2.18%, p99 20.78 ns; Speed-first CV 0.71%, p99 19.14 ns
• Syscall budget: 1.25e-7/op (両モード、800× below target <1e-6/op)
• DSO guard: Active (両モード、madvise_disabled=1)

判定: GO (production-ready)

• Both modes: 60分で zero drift, stable syscalls, no degradation
• Speed-first: throughput/CV/p99 で優位
• Balanced: prewarm suppression のみ（WS=400 では RSS を減らさない）

Use Cases（Phase 58 profile split）:

• Speed-first (default): HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE
• Balanced (opt-in): HAKMEM_PROFILE=MIXED_TINYV3_C7_BALANCED（= LEAN=1 DECOMMIT=OFF）

結果ドキュメント: docs/analysis/PHASE57_BALANCED_MODE_60MIN_SOAK_AND_SYSCALLS_RESULTS.md Scorecard更新: docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md (Phase 57 section added)

Phase 58: 完了（Profile split: Speed-first default + Balanced opt-in）

• 指示書: docs/analysis/PHASE58_PROFILE_SPLIT_SPEED_FIRST_DEFAULT_INSTRUCTIONS.md
• 実装: core/bench_profile.h
  • MIXED_TINYV3_C7_SAFE: Speed-first default（LEAN を preset しない）
  • MIXED_TINYV3_C7_BALANCED: LEAN+OFF を preset

Phase 59: 完了（COMPLETE, measurement-only, zero code changes）

Phase 59 で Balanced mode baseline を rebase し、M1 (50%) milestone を事実上達成（49.13%, within statistical noise）。

詳細: docs/analysis/PHASE59_50PERCENT_RECOVERY_BASELINE_REBASE_RESULTS.md

成果:

• M1 Achievement: 49.13% of mimalloc (gap -0.87%, within hakmem CV 1.31%)
• Stability Advantage: hakmem CV 1.31% vs mimalloc CV 3.50% (2.68× more stable)
• Production Readiness: All metrics meet or exceed targets
  • Syscall budget: 1.25e-7/op (800× below target)
  • RSS drift: 0% (60-min test, Phase 57)
  • Tail latency: CV 1.31% (better than mimalloc 3.50%)
• Baseline Update: hakmem 59.184M ops/s, mimalloc 120.466M ops/s

Strategic Decision Point（更新）:

• M1（50%）は実質達成したが、次は 「層/学習層/安定度を保ったまま +5–10%」 を狙う。

Next Phases:

• Phase 60: alloc pass-down SSOT（重複計算の排除、+1–2% を積む）
• Phase 61+（任意）: Competitive analysis / production deployment / 技術総括（速度が落ち着いたら）

Phase 43: 完了（NO-GO, reverted）

Phase 43 でheader write tax reduction を試行（C1-C6 の redundant header write を skip）したが、-1.18% regression で NO-GO。

Phase 42: 完了（NEUTRAL, analysis-only）

Phase 42 で runtime-first 最適化手法を適用、perf profiling → ASM inspection の順で hot target を探索したが、最適化対象が存在しないことを確認。

結果詳細: docs/analysis/PHASE42_RUNTIME_FIRST_METHOD_RESULTS.md

発見:

• Top 50 に gate function が存在しない — Phase 39 の定数化が極めて効果的だった証明
• ASM に 10+ gate function の call site が存在するが、全て runtime では実行されていない (<0.1% self-time)
• 既存の condition ordering も最適化済み（cheap check → expensive check の順）

runtime profiling 結果 (perf report --no-children):

1. malloc (22.04%) / free (21.73%) / main (21.65%) — core allocator + benchmark loop
2. tiny_region_id_write_header (17.58%) — header write hot path
3. tiny_c7_ultra_free (7.12%) / unified_cache_push (4.86%) — allocation paths
4. classify_ptr (2.48%) / tiny_c7_ultra_alloc (2.45%) — routing logic
5. Gate functions: ZERO in Top 50 ← Phase 39 の成功を確認

手法の検証:

• ✅ runtime profiling FIRST により Phase 40/41 の失敗（layout tax）を回避
• ✅ "ASM presence ≠ runtime impact" の原則を再確認
• ✅ Top 50 ルールにより optimization 対象の枯渇を早期検出

教訓:

1. Know when to stop — runtime data が "no hot targets" を示したら code を触らない
2. Phase 39 の効果は絶大 — 全 hot gate を eliminate 済み
3. Code cleanup は既に完了 — 既存 code は Box Theory + inline best practices に準拠済み
4. 次の 10-15% gap は algorithmic improvement が必要 — gate optimization は限界

Phase 44: 完了（COMPLETE, measurement-only, zero code changes）

Phase 44 で cache-miss および writeback profiling を実施（測定のみ、コード変更なし）。Modified Case A: Store-Ordering/Dependency Bound を確認。

結果詳細: docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.md

発見:

• IPC = 2.33 (excellent) — CPU は効率的に実行中、heavy stall なし
• cache-miss rate = 0.97% (world-class) — cache behavior は既に最適化済み
• L1-dcache-miss rate = 1.03% (very good) — L1 hit rate ~99%
• High time/miss ratios (20x-128x) — hot functions は store-ordering bound、not miss-bound
• tiny_region_id_write_header: 2.86% time, 0.06% misses (48x ratio)
• unified_cache_push: 3.83% time, 0.03% misses (128x ratio)

教訓:

1. NOT a cache-miss bottleneck — 0.97% miss rate は既に exceptional
2. High IPC (2.33) confirms efficient execution — CPU は stall していない
3. Store-ordering/dependency chains が bottleneck — high time/miss ratios が証明
4. Kernel dominates cache-misses (93.54%) — user-space allocator は cache-friendly
5. Prefetching は NG — cache-miss rate が既に低いため、逆効果の可能性

Phase 45: 完了（COMPLETE, analysis-only, zero code changes）

Phase 45 で dependency chain および store-to-load forwarding analysis を実施（測定・解析のみ、コード変更なし）。Dependency-chain bound を確認。

結果詳細: docs/analysis/PHASE45_DEPENDENCY_CHAIN_ANALYSIS_RESULTS.md

発見:

• Dependency-chain bound confirmed — high time/miss ratios (20x-128x) が証明
• unified_cache_push: 128x ratio (3.83% time, 0.03% misses) — 最重度の store-ordering bottleneck
• tiny_region_id_write_header: 48x ratio (2.86% time, 0.06% misses) — store-ordering bound
• malloc/free: 26x ratio (55% time, 2.15% misses) — dependency chain が支配的

Top 3 Optimization Opportunities:

1. Opportunity A: Eliminate lazy-init branch in unified_cache_push (+1.5-2.5%)
2. Opportunity B: Reorder operations in tiny_region_id_write_header (+0.8-1.5%)
3. Opportunity C: Prefetch TLS cache structure in malloc (+0.5-1.0%, conditional)

Expected cumulative gain: +2.3-5.0% (59.66M → 61.0-62.6M ops/s)

Phase 46+ 方針 (dependency chain optimization):

Cache-miss は既に最適 (0.97%)。次は dependency chain 短縮 に注目：

1. Phase 46A: Eliminate lazy-init branch in unified_cache_push (HIGH PRIORITY, LOW RISK)
2. Phase 46B: Reorder header write operations for parallelism (MEDIUM PRIORITY, MEDIUM RISK)
3. Phase 46C: A/B test TLS cache prefetching (LOW PRIORITY, MEASURE FIRST)
4. Algorithmic review: mimalloc の data structure 優位性を調査（残り 47-49% gap は algorithmic 可能性高）

Target: mimalloc gap 50.5% → 53-55%（micro-arch 限界、algorithmic improvement 必要）

指示書:

• Phase 43（header write tax）: docs/analysis/PHASE43_HEADER_WRITE_TAX_REDUCTION_INSTRUCTIONS.md（NO-GO）
• Phase 44（cache-miss / writeback profiling）: docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.md（COMPLETE）
• Phase 45（dependency chain analysis）: docs/analysis/PHASE45_DEPENDENCY_CHAIN_ANALYSIS_RESULTS.md（COMPLETE）
• Phase 46（TBD: dependency chain optimization）: 未作成

4) 直近のログ（要点だけ）

• Phase 24–34: atomic prune 累積 +2.74%（その後 diminishing returns）
• Phase 35-A: HAKMEM_BENCH_MINIMAL=1（gate prune）GO +4.39%
• Phase 36: FAST-only policy snapshot 最適化 GO +0.71%
• Phase 37: Standard TLS cache NO-GO（runtime gate の税が勝つ）
• Phase 38: FAST/OBSERVE/Standard 運用確立（scorecard + Makefile targets）
• Phase 39: FAST v3 gate 定数化 GO +1.98%
  • 結果詳細: docs/analysis/PHASE39_FAST_V3_GATE_CONSTANTIZATION_RESULTS.md
• Phase 40: tiny_header_mode() 定数化 NO-GO -2.47% (REVERTED)
  • 結果詳細: docs/analysis/PHASE40_GATE_CONSTANTIZATION_RESULTS.md
  • 原因: Phase 21 hot/cold split で既に最適化済み + code layout tax
  • 教訓: Assembly inspection first、既存最適化を尊重
• Phase 41: ASM-first gate audit (mid_v3_*()) NO-GO -2.02% (REVERTED)
  • 結果詳細: docs/analysis/PHASE41_ASM_FIRST_GATE_AUDIT_RESULTS.md
  • 原因: Dead code 削除による layout tax（gates は runtime 実行なし）
  • 教訓: ASM presence ≠ impact、runtime profiling 必須、dead code は放置
• Phase 42: runtime-first 最適化手法 NEUTRAL (analysis-only, no code changes)
  • 結果詳細: docs/analysis/PHASE42_RUNTIME_FIRST_METHOD_RESULTS.md
  • 発見: Top 50 に gate function が存在しない（Phase 39 の成功を確認）
  • 教訓: runtime profiling → 最適化対象の枯渇を早期検出、code を触らない判断
• Phase 43: Header write tax reduction NO-GO -1.18% (REVERTED)
  • 結果詳細: docs/analysis/PHASE43_HEADER_WRITE_TAX_REDUCTION_RESULTS.md
  • 目的: C1-C6 の redundant header write を skip（nextptr invariant 利用）
  • 原因: Branch misprediction tax (4.5+ cycles) > saved store cost (1 cycle)
  • 教訓: Straight-line code is king、runtime branches in hot paths are very expensive
  • Note: FAST v3 baseline updated to 59.66M ops/s (improved test environment)
• Phase 44: Cache-miss and writeback profiling COMPLETE (measurement-only, zero code changes)
  • 結果詳細: docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.md
  • 目的: cache-miss / store-ordering / dependency chain の bottleneck 特定
  • 発見: IPC = 2.33 (excellent), cache-miss = 0.97% (world-class), high time/miss ratios (20x-128x)
  • 判定: Modified Case A - Store-Ordering/Dependency Bound
  • 教訓: NOT a cache-miss bottleneck、prefetching は NG、50% gap は algorithmic 可能性高
• Phase 45: Dependency chain analysis COMPLETE (analysis-only, zero code changes)
  • 結果詳細: docs/analysis/PHASE45_DEPENDENCY_CHAIN_ANALYSIS_RESULTS.md
  • 目的: Store-to-load forwarding と dependency chain の詳細解析
  • 発見: unified_cache_push (128x ratio), tiny_region_id_write_header (48x ratio) が dependency-chain bound
  • Top 3 Opportunities: (A) Eliminate lazy-init branch (+1.5-2.5%), (B) Reorder header ops (+0.8-1.5%), (C) Prefetch TLS cache (+0.5-1.0%)
  • 教訓: Assembly analysis で具体的な dependency chain 特定、Opportunity A は LOW RISK (Phase 43 lesson 準拠)

Phase 46A: 完了（NO-GO, research box）

Phase 46A で tiny_region_id_write_header の always_inline 属性を適用したが、mean -0.68%, median +0.17% で NO-GO。

結果詳細: docs/analysis/PHASE46A_TINY_REGION_ID_WRITE_HEADER_ALWAYS_INLINE_RESULTS.md

発見:

• Mean -0.68% (NO-GO threshold) — layout tax の兆候
• Median +0.17% (weak positive) — inline 自体は micro で有効
• Binary size 同一 — compiler 既に inline 済み、layout rearrangement のみ発生
• Branch prediction 有効 — modern CPU は hot path の branch を完璧に予測

教訓:

1. Layout tax は実在 — code size 同一でも performance 変化
2. Branch prediction 効果大 — straight-line code への変換は期待値 < 0.5%
3. Median positive ≠ actionable — mean が閾値下回れば NO-GO
4. Conservative threshold 必要 — ±0.5% mean で layout tax を filter

Phase 47: 完了（NEUTRAL, research box retained）

Phase 47 で compile-time fixed front config (HAKMEM_TINY_FRONT_PGO=1) を適用したが、mean +0.27%, median +1.02% で NEUTRAL。

結果詳細: docs/analysis/PHASE47_FAST_FRONT_PGO_MODE_RESULTS.md

発見:

• Mean +0.27% (NEUTRAL, below +0.5% threshold) — 閾値未達
• Median +1.02% (positive signal) — compile-time constants に小幅効果
• Variance 2× baseline (2.32% vs 1.23%) — treatment group の分散増大（layout tax 兆候）
• 5-7 branches eliminated — runtime gate checks → compile-time constants

理由（NEUTRAL）:

1. Mean が GO 閾値（+0.5%）未達 — layout tax が gain を相殺
2. High variance (2× CV) — measurement uncertainty、reproducibility concern
3. Phase 46A lesson — small positive signals can mask layout tax

Research box として保持:

• Makefile ターゲット: bench_random_mixed_hakmem_fast_pgo
• 将来的に他の最適化と組み合わせる可能性を残す
• Mean-median 乖離（+0.27% vs +1.02%）は genuine micro-optimization の存在を示唆

教訓:

1. Branch prediction is effective — 5-7 branch elimination で <1% gain のみ
2. Layout tax is real — variance 増大が code rearrangement 副作用を示唆
3. Conservative threshold justified — ±0.5% mean で noise を filter
4. Median-positive ≠ actionable — mean と median 両方が threshold 超え必要

Phase 49: 完了（COMPLETE, NO-GO, analysis-only, zero code changes）

Phase 49 で Top hotspot (tiny_region_id_write_header, unified_cache_push) の dependency chain を分析したが、既に最適化済みで改善余地なしと判定（NO-GO）。

結果詳細: docs/analysis/PHASE49_DEPCHAIN_OPT_TINY_HEADER_AND_UC_PUSH_RESULTS.md

発見:

• tiny_region_id_write_header (5.34%): Phase 21 hot/cold split 最適化済み、hot path は 5命令 straight-line（極めて最小）
• unified_cache_push (4.03%): BENCH_MINIMAL で lazy-init compile-out 済み、TLS offset 計算は CPU micro-arch 依存
• Dependency chain の主因は CPU micro-architecture（register save/restore, TLS access）— software 最適化では短縮不可能
• Perf annotate の lazy-init (18.91%) は LTO inline の副作用（caller 混在）、実コードでは compile-out 済み

教訓:

1. Know when to stop — runtime data が "no optimization targets" を示したら code を触らない（Phase 42 教訓再確認）
2. Micro-arch bottleneck は software 最適化の限界 — TLS/register は CPU 依存、algorithmic improvement 必要
3. Layout tax は実在する — Phase 40/41/43/46A の一貫した教訓、code size 同一でも performance 変化
4. Perf annotate ≠ optimization target — LTO/inline による symbol 混在を考慮すべき
5. M1 (50%) 再達成には構造改善が必要 — Phase 44/45 結論と一致

Phase 48: 完了（COMPLETE, measurement-only, zero code changes）

Phase 48 で競合 allocator（mimalloc/system/jemalloc）を同一条件で再計測し、syscall budget と長時間安定性の測定ルーチンを確立した。

結果詳細: docs/analysis/PHASE48_REBASE_ALLOCATORS_AND_STABILITY_SUITE_RESULTS.md

発見:

• hakmem FAST v3: 59.15M ops/s (mimalloc の 48.88%, -0.82% variance)
• mimalloc: 121.01M ops/s (新 baseline, +2.39% environment drift)
• system malloc: 85.10M ops/s (70.33%, +4.37% environment drift)
• jemalloc: 96.06M ops/s (79.38%, 初回計測)
• Syscall budget: 9e-8 / op (EXCELLENT, ideal の 10x 以内)

判定:

• Status: COMPLETE (measurement-only, zero code changes)
• M1 (50%) 再達成に必要: +1.45M ops/s (+2.45%)
• Environment drift により ratio 50.5% → 48.88% (mimalloc baseline 上昇が主因)

教訓:

1. Environment drift is real — mimalloc +2.39%, system +4.37% 変化
2. hakmem は安定 — -0.82% は measurement variance 範囲内
3. jemalloc は strong competitor — 79.38% of mimalloc (system より 9% 速い)
4. Syscall budget は excellent — 9e-8 / op, warmup 後に churn なし

次の指示書（Phase 49+）:

• Phase 49+: TBD（dependency chain optimization / algorithmic review）
  • スコアカード（SSOT）: docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md
  • Phase 48 rebase により新 baseline 確立
  • M1 再達成 または M2 (55%) を目指す最適化が必要

5) アーカイブ

• 旧 CURRENT_TASK.md（詳細ログ）は archive/CURRENT_TASK_ARCHIVE_20251216.md