hakmem/CURRENT_TASK.md

CURRENT_TASK（Rolling, SSOT）

0) 今の「正」

• 性能比較の正: FAST PGO build（make pgo-fast-full → bench_random_mixed_hakmem_minimal_pgo）✓ Phase 69 昇格済み (Warm Pool Size=16)
• 安全・互換の正: Standard build（make bench_random_mixed_hakmem）
• 観測の正: OBSERVE build（make perf_observe）
• スコアカード: docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md（M1 達成・超過: 51.77% vs 50% target、M2 まで残り +3.23pp）
• 計測の正（Mixed 10-run）: scripts/run_mixed_10_cleanenv.sh（ITERS=20000000 WS=400、HAKMEM_WARM_POOL_SIZE=16 デフォルト）

1) 現状（要点）

• Phase 64（backend prune / DCE）: NO-GO（-4.05%） → layout tax 由来
• Phase 63（FAST_PROFILE_FIXED）: 研究用ビルドとして保持（FAST の gate を compile-time 固定）
• Phase 65（Hot Symbol Ordering）: BLOCKED（GCC+LTO の制約で不公平/不可能）→ docs/analysis/PHASE65_HOT_SYMBOL_ORDERING_1_RESULTS.md
• Phase 66（PGO, GCC+LTO）: GO ✓
  • 検証: 3回独立実行で +3.0% mean, all >+2.89%, 分散 <±1%
  • Baseline: bench_random_mixed_hakmem_minimal_pgo = 60.89M ops/s = 50.32% (initial PGO)
• Phase 68（PGO training set 最適化）: GO & 昇格完了 ✓
  • 検証: 10-run で +1.19% vs Phase 66 (GO: +1.0% threshold超過)
  • Baseline (upgraded): bench_random_mixed_hakmem_minimal_pgo = 61.614M ops/s = 50.93% (50% target 超過、+0.93pp)
• Phase 69（Refill tuning: Warm Pool Size 最適化）: 強GO & 昇格完了 ✓✓✓
  • 検証: 10-run で +3.26% vs Phase 68 (強GO: +3.0% threshold超過)
  • 新 baseline: bench_random_mixed_hakmem_minimal_pgo (upgraded) = 62.63M ops/s = 51.77% (M1 超過、+1.77pp、M2 まで残り +3.23pp)

2) 次の指示書（Active）

Phase 68: PGO training set 最適化 ✅ 完了

• ✓ seed/WS diversification: WS (3→5パターン), seed (1→3パターン)
• ✓ 10-run 検証: +1.19% vs Phase 66 (GO threshold +1.0% 超過)
• ✓ Baseline 昇格: 61.614M ops/s = 50.93% (M1 target 50% を +0.93pp 超過)
• ✓ スコアカード・CURRENT_TASK 更新完了

---

Phase 67a: Layout Tax 法医学（変更最小） ✅ 完了・実運用可能

• ✓ scripts/box/layout_tax_forensics_box.sh 新規（測定ハーネス）

  • Baseline vs Treatment の 10-run throughput 比較
  • perf stat 自動収集（cycles, IPC, branches, branch-misses, cache-misses, iTLB/dTLB）
  • Binary metadata（サイズ、セクション構成）

• ✓ docs/analysis/PHASE67A_LAYOUT_TAX_FORENSICS_SSOT.md 新規（診断ガイド）

  • 判定ルール: GO (+1% 以上) / NEUTRAL (±1%) / NO-GO (-1% 以下)
  • "症状→原因候補" マッピング表
    • IPC 低下 3%↑ → I-cache miss / code layout dispersal
    • branch-misses ↑10%↑ → branch prediction penalty
    • dTLB-misses ↑100%↑ → data layout fragmentation
  • Phase 64 case study（-4.05% の root cause: IPC 2.05 → 1.98）
  • 運用ガイドライン

使用例:

./scripts/box/layout_tax_forensics_box.sh \
    ./bench_random_mixed_hakmem_minimal_pgo \
    ./bench_random_mixed_hakmem_fast_pruned  # or Phase 64 attempt

成果: 「削る系」NO-GO が出た時に、どの指標が悪化しているかを 1回で診断可能 → 以後の link-out/大削除を事前に止められる

---

Phase 69: "refill頻度×固定税" を削る（M2への最短距離）

Phase 69-0: パラメータ sweep 設計メモ ✅ 完了

• ✓ docs/analysis/PHASE69_REFILL_TUNING_0_DESIGN.md 作成
• ✓ Tunable parameters 特定:
  • HAKMEM_TINY_REFILL_COUNT_MID / HAKMEM_TINY_REFILL_COUNT_HOT（refill 量の実体, ENV-only）
  • Unified Cache C5-C7 capacity (128 → 256/512)
  • Warm Pool size (12 → 16/24)
• ✓ Sweep 計画立案（single-parameter → combined optimization）
• ✓ Risk assessment & 判定基準定義

Phase 69-1: Sweep 実行 ✅ 完了

• ✓ Baseline (Phase 68 PGO): 60.65M ops/s (10-run mean)
• ✓ Warm Pool Size sweep:
  • Size=16: 62.63M ops/s (+3.26%, 強GO) ✓✓✓ Winner
  • Size=24: 62.37M ops/s (+2.84%, GO)
• ✓ Unified Cache C5-C7 sweep:
  • Cache=256: 61.92M ops/s (+2.09%, GO)
  • Cache=512: 61.80M ops/s (+1.89%, GO)
• ✓ Combined optimization check:
  • Warm=16 + Cache=256: 62.35M ops/s (+2.81%, non-additive)
• ✓ “Refill Batch Size sweep” は無効（knob 未接続）:
  • TINY_REFILL_BATCH_SIZE は現行 Tiny front に call site が無く、性能 knob として成立していない
  • 参照: docs/analysis/PHASE69_REFILL_TUNING_3C_REFILL_BATCH_KNOB_AUDIT.md
• 結果: docs/analysis/PHASE69_REFILL_TUNING_1_RESULTS.md
• 勝ち設定: Warm Pool Size=16 (ENV-only, +3.26%, 強GO)

Phase 69-2: 勝ち設定を baseline に反映 ✅ 完了

• ✓ scripts/run_mixed_10_cleanenv.sh に HAKMEM_WARM_POOL_SIZE=16 デフォルト追加
• ✓ core/bench_profile.h の MIXED_TINYV3_C7_SAFE preset に bench_setenv_default("HAKMEM_WARM_POOL_SIZE","16") 追加
• ✓ PERFORMANCE_TARGETS_SCORECARD.md に新 baseline 追加:
  • Phase 69 baseline: 62.63M ops/s = 51.77% of mimalloc
  • M1 (50%) achievement: EXCEEDED (+1.77pp above target)
  • M2 (55%) progress: Gap reduced to +3.23pp
• ✓ Rollback: HAKMEM_WARM_POOL_SIZE=12 or ENV 変数削除

新 baseline: 62.63M ops/s = mimalloc の 51.77% (Phase 68 から +3.26%、M2 まで残り +3.23pp)

---

Phase 69-3（次候補）: refill 量（ENV-only）sweep OR 次の sweep

• 選択肢 A（推奨）: Refill count の ENV sweep（コード変更なし）

  • HAKMEM_TINY_REFILL_COUNT_MID（C4–C7）を 64/96/128/160… で sweep
  • HAKMEM_TINY_REFILL_COUNT_HOT（C0–C3）も同様に sweep（ただし WarmPool/UnifiedCache と相互作用あり）
  • 判定: 10-run mean で GO(+1.0%) / 強GO(+3.0%) / NO-GO(-1.0%)

• 選択肢 B: Unified Cache の fine sweep（ENV-only）

  • C5/C6/C7 を 192/256/320… などで sweep（Phase 69-1 の 256/512 は coarse）
  • WarmPool=16 との非加算性を “原因切り分け” する

• 選択肢 C: compile-time knob の新設（後回し）

  • TINY_REFILL_BATCH_SIZE は未接続なので、そのまま追わない
  • 必要なら別途 SSOT を作って実装する（Phase 70+）

• 選択肢 D: 別方向の最適化（M2: 55% への最短距離）

  • 残り gap: +3.23pp (51.77% → 55%)
  • Phase 67b（境界 inline/unroll チューニング）
  • Top 50 hot functions の最適化
  • PGO profile の再調整

---

Phase 67b（後続・保険）: 境界inline/unrollチューニング

• 注意: layout tax リスク高い（Phase 64 reference）
• 前提: Top 50 実行確認が必須
• Phase 69 が外れた時の保険として後回し推奨

---

Phase 70（観測の前提固め）: Refill/WarmPool 最適化の Step 0 を SSOT 化

• 目的: “経路が踏まれていない最適化” を防ぐ（Phase 40/41/64 の layout tax 前例）
• 注意: Route assignments: LEGACY は「Unified Cache 未使用」を意味しない（backend route kind）
• SSOT: docs/analysis/PHASE70_REFILL_OBSERVABILITY_PREREQS_SSOT.md
  • Mixed SSOT（WS=400）で unified_cache_refill() / WarmPool pop が有意に起きているかを OBSERVE で確定してから Phase 70 を進める

注記: 研究箱の削除は今やらない（link-out/削除が layout tax を起こす前例が強いので、compile-out維持が正解）

3) アーカイブ

• 詳細ログ: CURRENT_TASK_ARCHIVE_20251210.md
• 直近整理前スナップショット: docs/analysis/CURRENT_TASK_ARCHIVE.md