Phase 68: PGO training set diversification (seed/WS expansion)

Changes:
- scripts/box/pgo_fast_profile_config.sh: Expanded WS patterns (3→5) and seeds (1→3)
  for reduced overfitting and better production workload representativeness
- PERFORMANCE_TARGETS_SCORECARD.md: Phase 68 baseline promoted (61.614M = 50.93%)
- CURRENT_TASK.md: Phase 68 marked complete, Phase 67a (layout tax forensics) set Active

Results:
- 10-run verification: +1.19% vs Phase 66 baseline (GO, >+1.0% threshold)
- M1 milestone: 50.93% of mimalloc (target 50%, exceeded by +0.93pp)
- Stability: 10-run mean/median with <2.1% CV

🤖 Generated with Claude Code

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit is contained in:
Moe Charm (CI)
2025-12-17 21:08:17 +09:00
parent 10fb0497e2
commit 84f5034e45
44 changed files with 1520 additions and 583 deletions

View File

@ -1,561 +1,57 @@
# CURRENT_TASKRolling
# CURRENT_TASKRolling, SSOT
## 0) 今の「正」Phase 48 rebase
## 0) 今の「正」
- **性能比較の正**: **FAST build**`make perf_fast`
- **性能比較の正**: FAST PGO build`make pgo-fast-full``bench_random_mixed_hakmem_minimal_pgo`)✓ **Phase 68 昇格済み** (seed/WS diversified)
- **安全・互換の正**: Standard build`make bench_random_mixed_hakmem`
- **観測の正**: OBSERVE build`make perf_observe`
- **スコアカード**: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md`
- **スコアカード**: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md`M1 達成・超過: 50.93% vs 50% target
- **計測の正Mixed 10-run**: `scripts/run_mixed_10_cleanenv.sh``ITERS=20000000 WS=400`
## 1) 現状(最新スナップショット
## 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%)
- Phase 64backend prune / DCE: **NO-GO**-4.05% → layout tax 由来
- Phase 63FAST_PROFILE_FIXED: **研究用ビルド**として保持FAST の gate を compile-time 固定
- Phase 65Hot Symbol Ordering: **BLOCKED**GCC+LTO の制約で不公平/不可能)→ `docs/analysis/PHASE65_HOT_SYMBOL_ORDERING_1_RESULTS.md`
- Phase 66PGO, 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 68PGO training set 最適化): **GO & 昇格完了**
- 検証: 10-run で +1.19% vs Phase 66 (GO: +1.0% threshold超過)
- 新 baseline: `bench_random_mixed_hakmem_minimal_pgo` (upgraded) = 61.614M ops/s = **50.93%** (50% target 超過、+0.93pp)
**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
## 2) 次の指示書Active
※詳細は `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md` を正とする(ここは要点だけ)。
※Phase 59b rebase: hakmem stable (58.478M), mimalloc +1.59% variance, ratio 49.13% → 48.34% (-0.79pp)
**Phase 68: PGO training set 最適化****完了**
## 2) 原則Box Theory 運用)
- ✓ 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 更新完了
- 変更は箱で分ける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 67a推奨: layout tax 法医学調査**
**Phase 62A: 完了NEUTRAL -0.71%, research box**
- **狙い**: Phase 64 NO-GO (-4.05%) の根本原因を「再現可能な手順」に固定
- **やること**: perf stat (cycles/IPC/branch-miss/cache-miss/iTLB) を差分テンプレ化 → docs に添付
- Binary diff: Phase 66 baseline vs Phase 64 attempt
- perf drill-down: Hot function の IPC drop / branch miss rate 増加を定量化
- 実装変更なし(法医学ドキュメント化のみ)
- **成果物**: `docs/analysis/PHASE67A_LAYOUT_TAX_FORENSICS_RESULTS.md`
- 指示書: "箱化モジュール化 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)
**Phase 67b後続: 境界inline/unrollチューニング**
- **注意**: layout tax リスク高いPhase 64 reference
- **前提**: Top 50 実行確認が必須
- 触るなら最小限・高確度だけ(例: C0 allocator inline candidates のみ)
- **結果詳細**: `docs/analysis/PHASE62A_C7_ULTRA_DEPCHAIN_OPT_RESULTS.md`
- **判定**: NEUTRAL、research box化default OFF
**注記**: 研究箱の削除は今やらないlink-out/削除が layout tax を起こす前例が強いので、compile-out維持が正解
- **原因分析**:
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 は失敗傾向)
**M2 への道 (55% target)**:
- PGO はもう +1% 程度の改善上限に達した可能性profile training set 枯渇
- 次のレバーは: (1) layout tax 排除 / (2) structural changesbox design / (3) compiler flags tuning
- **教訓**:
- Function call overhead (LTO) < TLS access overhead
- 5.18% stack % optimizable hotspot ではない既に最適化済み
- 48.34% gap algorithmicmicro-opt では埋め難い
## 3) アーカイブ
**Phase 62B+: 次の方針TBD**
- Option A: tiny_region_id_write_header optimization (+0.5-1.5%, very high risk)
- Option B: Production readiness pivot48.34% acceptdocumentation/telemetry focus
- Option C: Algorithmic redesignbatching, prefault strategypost-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 skiprefill 時に 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 は期待より小さい hotspot2.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 modeMIXED_TINYV3_C7_SAFE baseline rebaseM1 (50%) baseline 更新
- 判定: **COMPLETE**hakmem: 58.478M ops/s, mimalloc: 120.979M ops/s, ratio: 48.34%
- Profile 変更: Balanced Speed-firstPhase 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-downPhase 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 drift5分 soak, EXCELLENT
- **Throughput stability**: allocator positive drift (+0.8%-0.9%) & low CV (1.5%-2.1%, EXCELLENT)
- **Tail latency**: TODOPhase 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 drift5分 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 meanmimalloc 2.28%, system 0.77%
- **p99/p50 ratio**: 1.024tail 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 designpersistent 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-inRSS <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 testing30-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 testing60s 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 reductiontail latency 改善Phase 52 で課題特定済み
- 候補B: Throughput gap closuremimalloc 50% 55%、algorithmic improvement 必要
- 候補C: LEAN+FREE/DONTNEED extended validationextreme 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 MBmetadata 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 5457: 完了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+OFFprewarm 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 modeLEAN+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 CasesPhase 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 defaultLEAN 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更新**:
- M150%は実質達成したが次は **/学習層/安定度を保ったまま +510%」** を狙う
**Next Phases**:
- **Phase 60**: alloc pass-down SSOT重複計算の排除、+12% を積む
- **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 boundnot 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 43header write tax: `docs/analysis/PHASE43_HEADER_WRITE_TAX_REDUCTION_INSTRUCTIONS.md`NO-GO
- Phase 44cache-miss / writeback profiling: `docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.md`COMPLETE
- Phase 45dependency chain analysis: `docs/analysis/PHASE45_DEPENDENCY_CHAIN_ANALYSIS_RESULTS.md`COMPLETE
- Phase 46TBD: dependency chain optimization: 未作成
## 4) 直近のログ(要点だけ)
- Phase 2434: 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 taxgates runtime 実行なし
- 教訓: ASM presence impactruntime 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 skipnextptr 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 uncertaintyreproducibility 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-architectureregister 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 で競合 allocatormimalloc/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+: TBDdependency 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`
- 詳細ログ: `CURRENT_TASK_ARCHIVE_20251210.md`
- 直近整理前スナップショット: `docs/analysis/CURRENT_TASK_ARCHIVE.md`

View File

@ -357,7 +357,7 @@ bench_tiny_hot_hakmem.o: bench_tiny_hot.c hakmem.h
bench_tiny_hot_system.o: bench_tiny_hot.c
$(CC) $(CFLAGS) -c -o $@ $<
bench_tiny_hot_hakmem: $(filter-out bench_allocators_hakmem.o bench_allocators_system.o,$(BENCH_HAKMEM_OBJS)) bench_tiny_hot_hakmem.o
bench_tiny_hot_hakmem: bench_tiny_hot_hakmem.o $(TINY_BENCH_OBJS)
$(CC) -o $@ $^ $(LDFLAGS)
bench_tiny_hot_system: bench_tiny_hot_system.o
@ -659,6 +659,73 @@ bench_random_mixed_hakmem_minimal:
$(MAKE) bench_random_mixed_hakmem EXTRA_CFLAGS='-DHAKMEM_BENCH_MINIMAL=1'
mv bench_random_mixed_hakmem bench_random_mixed_hakmem_minimal
# Phase 63: FAST profile fixed target (BENCH_MINIMAL + FAST_PROFILE_FIXED)
# Usage: make bench_random_mixed_hakmem_fast_fixed
# Note: This rebuilds all objects with BENCH_MINIMAL + FAST_PROFILE_FIXED.
# Purpose: FAST build with compile-time constant gates matching MIXED_TINYV3_C7_SAFE defaults.
.PHONY: bench_random_mixed_hakmem_fast_fixed
bench_random_mixed_hakmem_fast_fixed:
$(MAKE) clean
$(MAKE) bench_random_mixed_hakmem EXTRA_CFLAGS='-DHAKMEM_BENCH_MINIMAL=1 -DHAKMEM_FAST_PROFILE_FIXED=1'
mv bench_random_mixed_hakmem bench_random_mixed_hakmem_fast_fixed
# Phase 65: Hot Symbol Ordering was investigated but is BLOCKED under the current
# GCC+LTO toolchain constraints (see docs/analysis/PHASE65_HOT_SYMBOL_ORDERING_1_RESULTS.md).
# We intentionally do not provide a build target that disables LTO or swaps linkers,
# because it makes baseline comparisons unfair and tends to introduce layout tax.
# Phase 64: Backend pruning target (BENCH_MINIMAL + FAST_PROFILE_FIXED + FAST_PROFILE_PRUNE_BACKENDS)
# Usage: make bench_random_mixed_hakmem_fast_pruned
# Note: This rebuilds all objects with BENCH_MINIMAL + FAST_PROFILE_FIXED + FAST_PROFILE_PRUNE_BACKENDS.
# Purpose: LTO DCE optimization - makes MID_V3, POOL_V2 unreachable at compile-time for +5-10% gain
.PHONY: bench_random_mixed_hakmem_fast_pruned
bench_random_mixed_hakmem_fast_pruned:
$(MAKE) clean
$(MAKE) bench_random_mixed_hakmem EXTRA_CFLAGS='-DHAKMEM_BENCH_MINIMAL=1 -DHAKMEM_FAST_PROFILE_FIXED=1 -DHAKMEM_FAST_PROFILE_PRUNE_BACKENDS=1'
mv bench_random_mixed_hakmem bench_random_mixed_hakmem_fast_pruned
# Phase 66: PGO (Profile-Guided Optimization) for FAST minimal build (keeps GCC+LTO)
# Usage: make pgo-fast-full
.PHONY: pgo-fast-profile pgo-fast-collect pgo-fast-build pgo-fast-full
pgo-fast-profile:
@echo "========================================="
@echo "Phase 66: Building PGO Profile Binaries (FAST minimal)"
@echo "========================================="
$(MAKE) clean
$(MAKE) PROFILE_GEN=1 bench_random_mixed_hakmem bench_tiny_hot_hakmem EXTRA_CFLAGS='-DHAKMEM_BENCH_MINIMAL=1'
@echo ""
@echo "✓ PGO profile binaries built (FAST minimal)"
@echo "Next: make pgo-fast-collect"
@echo ""
pgo-fast-collect:
@echo "========================================="
@echo "Phase 66: Collecting PGO Profile Data (FAST minimal)"
@echo "========================================="
PGO_CONFIG=pgo_fast_profile_config.sh ./scripts/box/pgo_tiny_profile_box.sh
@echo ""
@echo "✓ PGO profile collection complete"
@echo "Next: make pgo-fast-build"
@echo ""
pgo-fast-build:
@echo "========================================="
@echo "Phase 66: Building PGO-Optimized Binary (FAST minimal)"
@echo "========================================="
$(MAKE) clean
$(MAKE) PROFILE_USE=1 bench_random_mixed_hakmem EXTRA_CFLAGS='-DHAKMEM_BENCH_MINIMAL=1'
mv bench_random_mixed_hakmem bench_random_mixed_hakmem_minimal_pgo
@echo ""
@echo "✓ PGO-optimized FAST minimal binary built: bench_random_mixed_hakmem_minimal_pgo"
@echo "Next: BENCH_BIN=./bench_random_mixed_hakmem_minimal_pgo scripts/run_mixed_10_cleanenv.sh"
@echo ""
pgo-fast-full: pgo-fast-profile pgo-fast-collect pgo-fast-build
@echo "========================================="
@echo "Phase 66: PGO Full Workflow Complete (FAST minimal)"
@echo "========================================="
BENCH_BIN=./bench_random_mixed_hakmem_minimal_pgo scripts/run_mixed_10_cleanenv.sh
# Phase 47: FAST+PGO target (BENCH_MINIMAL + TINY_FRONT_PGO)
# Usage: make bench_random_mixed_hakmem_fast_pgo
# Note: This rebuilds all objects with BENCH_MINIMAL + TINY_FRONT_PGO

View File

@ -25,7 +25,8 @@ core/box/carve_push_box.o: core/box/carve_push_box.c \
core/box/../hakmem_tiny_integrity.h core/box/../hakmem_tiny.h \
core/box/../tiny_region_id.h core/box/../tiny_box_geometry.h \
core/box/../ptr_track.h core/box/../tiny_debug_api.h \
core/box/../box/tiny_header_hotfull_env_box.h core/box/carve_push_box.h \
core/box/../box/tiny_header_hotfull_env_box.h \
core/box/../box/../hakmem_build_flags.h core/box/carve_push_box.h \
core/box/capacity_box.h core/box/tls_sll_box.h \
core/box/../hakmem_internal.h core/box/../hakmem.h \
core/box/../hakmem_config.h core/box/../hakmem_features.h \
@ -87,6 +88,7 @@ core/box/../tiny_box_geometry.h:
core/box/../ptr_track.h:
core/box/../tiny_debug_api.h:
core/box/../box/tiny_header_hotfull_env_box.h:
core/box/../box/../hakmem_build_flags.h:
core/box/carve_push_box.h:
core/box/capacity_box.h:
core/box/tls_sll_box.h:

View File

@ -19,6 +19,7 @@
#include <stdatomic.h>
#include <stdlib.h>
#include "../hakmem_build_flags.h"
// ENV control: cached flag for fastlane_direct_enabled()
// -1: uninitialized, 0: disabled, 1: enabled
@ -30,6 +31,9 @@ extern _Atomic int g_fastlane_direct_enabled;
// Returns: 1 if enabled, 0 if disabled
// Hot path: Single atomic load (after first call)
static inline int fastlane_direct_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
int val = atomic_load_explicit(&g_fastlane_direct_enabled, memory_order_relaxed);
if (__builtin_expect(val == -1, 0)) {
// Cold path: Initialize from ENV

View File

@ -30,6 +30,7 @@
#include <stdatomic.h>
#include <stdlib.h>
#include "../hakmem_build_flags.h"
// Forward declaration for cross-box includes
static inline int free_tiny_direct_enabled(void);
@ -41,6 +42,9 @@ static inline int free_tiny_direct_enabled(void);
// Lazy init: Check ENV variable on first call, cache result
// Thread-safe: Read-only after init (atomic store, relaxed load)
static inline int free_tiny_direct_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
static _Atomic int cached = -1; // -1 = uninitialized
int val = atomic_load_explicit(&cached, memory_order_relaxed);

View File

@ -14,6 +14,9 @@
#include "../hakmem_build_flags.h"
static inline int hak_free_tiny_fast_hotcold_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
static int g = -1;
static int g_probe_left = 64; // tolerate early getenv() instability (bench_profile putenv)

View File

@ -4,6 +4,7 @@
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include "../hakmem_build_flags.h"
// Phase 9: FREE-TINY-FAST MONO DUALHOT ENV gate
//
@ -16,6 +17,9 @@
// - A/B: Same binary, flip ENV for immediate rollback
static inline int free_tiny_fast_mono_dualhot_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
static int g_enabled = -1; // -1: unknown, 0: off, 1: on
static int g_probe_left = 64; // Probe window (tolerate early putenv)

View File

@ -22,6 +22,9 @@
// ============================================================================
static inline int free_tiny_fast_mono_legacy_direct_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
static int g = -1;
static int g_probe_left = 64; // tolerate early getenv() instability (bench_profile putenv)

View File

@ -44,6 +44,9 @@ extern __thread struct free_wrapper_env_snapshot g_free_wrapper_env;
// ENV gate: Enable/disable snapshot optimization (default: OFF, research box)
static inline int free_wrapper_env_snapshot_enabled(void)
{
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
static __thread int s_enabled = -1;
if (__builtin_expect(s_enabled == -1, 0)) {
const char* env = getenv("HAKMEM_FREE_WRAPPER_ENV_SNAPSHOT");

View File

@ -3,6 +3,7 @@
// ============================================================================
#include "front_fastlane_alloc_legacy_direct_env_box.h"
#include "../hakmem_build_flags.h"
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
@ -19,6 +20,11 @@ _Atomic int g_front_fastlane_alloc_legacy_direct_enabled = -1;
// ============================================================================
int front_fastlane_alloc_legacy_direct_env_init(void) {
#if HAKMEM_FAST_PROFILE_FIXED
// Fixed OFF in FAST profile fixed builds.
atomic_store_explicit(&g_front_fastlane_alloc_legacy_direct_enabled, 0, memory_order_relaxed);
return 0;
#else
const char* env = getenv("HAKMEM_FRONT_FASTLANE_ALLOC_LEGACY_DIRECT");
int enabled = 0; // default: OFF (opt-in)
@ -37,6 +43,7 @@ int front_fastlane_alloc_legacy_direct_env_init(void) {
}
return enabled;
#endif
}
// ============================================================================
@ -45,11 +52,15 @@ int front_fastlane_alloc_legacy_direct_env_init(void) {
// LTO fallback: Non-inline version for cases where LTO can't inline
int front_fastlane_alloc_legacy_direct_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 0;
#else
int val = atomic_load_explicit(&g_front_fastlane_alloc_legacy_direct_enabled, memory_order_relaxed);
if (__builtin_expect(val == -1, 0)) {
val = front_fastlane_alloc_legacy_direct_env_init();
}
return val;
#endif
}
// ============================================================================
@ -57,7 +68,12 @@ int front_fastlane_alloc_legacy_direct_enabled(void) {
// ============================================================================
void front_fastlane_alloc_legacy_direct_env_refresh_from_env(void) {
#if HAKMEM_FAST_PROFILE_FIXED
// Keep fixed OFF.
atomic_store_explicit(&g_front_fastlane_alloc_legacy_direct_enabled, 0, memory_order_relaxed);
#else
// Reset to uninitialized state (-1)
// Next call to front_fastlane_alloc_legacy_direct_enabled() will re-read ENV
atomic_store_explicit(&g_front_fastlane_alloc_legacy_direct_enabled, -1, memory_order_relaxed);
#endif
}

View File

@ -35,6 +35,7 @@
#define FRONT_FASTLANE_ALLOC_LEGACY_DIRECT_ENV_BOX_H
#include <stdatomic.h>
#include "../hakmem_build_flags.h"
// ============================================================================
// Global State (L0)

View File

@ -35,6 +35,7 @@
#include <stdatomic.h>
#include <stdlib.h>
#include <stdint.h>
#include "../hakmem_build_flags.h"
// Forward declaration for cross-box includes
static inline int front_fastlane_enabled(void);
@ -48,6 +49,9 @@ static inline int front_fastlane_free_dedup_enabled(void);
// Lazy init: Check ENV variable on first call, cache result
// Thread-safe: Read-only after init (atomic store, relaxed load)
static inline int front_fastlane_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
static _Atomic int cached = -1; // -1 = uninitialized
int val = atomic_load_explicit(&cached, memory_order_relaxed);
@ -71,6 +75,9 @@ static inline int front_fastlane_enabled(void) {
// Get class mask for gradual rollout (default: 0xFF = all classes)
static inline uint8_t front_fastlane_class_mask(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return (uint8_t)0xFF;
#endif
static _Atomic int cached = -1; // -1 = uninitialized
int val = atomic_load_explicit(&cached, memory_order_relaxed);
@ -100,6 +107,9 @@ static inline uint8_t front_fastlane_class_mask(void) {
// When enabled, front_fastlane_try_free() directly calls free_tiny_fast()
// instead of doing its own header validation.
static inline int front_fastlane_free_dedup_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
static _Atomic int cached = -1; // -1 = uninitialized
int val = atomic_load_explicit(&cached, memory_order_relaxed);

View File

@ -11,6 +11,7 @@
#include "tiny_c7_hotbox.h" // tiny_c7_alloc_fast wrapper
#include "mid_hotbox_v3_box.h" // Phase MID-V3: Mid/Pool HotBox v3 types
#include "mid_hotbox_v3_env_box.h" // Phase MID-V3: ENV gate for v3
#include "../hakmem_build_flags.h" // Phase 64: For backend pruning
#ifdef HAKMEM_POOL_TLS_PHASE1
#include "../pool_tls.h"
@ -79,6 +80,7 @@ inline void* hak_alloc_at(size_t size, hak_callsite_t site) {
// Design: TLS lane cache with page-based allocation, RegionIdBox integration
// NOTE: Must come BEFORE Tiny to intercept specific size classes
// PERF: C6 shows +11% improvement, Mixed (257-768B) shows +19.8% improvement
#if !HAKMEM_FAST_PROFILE_PRUNE_BACKENDS
if (__builtin_expect(mid_v3_enabled() && size >= 257 && size <= 768, 0)) {
static _Atomic int entry_log_count = 0;
if (mid_v3_debug_enabled() && atomic_fetch_add(&entry_log_count, 1) < 3) {
@ -115,6 +117,7 @@ inline void* hak_alloc_at(size_t size, hak_callsite_t site) {
}
}
}
#endif
// Phase 16: Dynamic Tiny max size (ENV: HAKMEM_TINY_MAX_CLASS)
// Default: 1023B (C0-C7), reduced to 255B (C0-C5) when Small-Mid enabled

View File

@ -239,6 +239,7 @@ void hak_free_at(void* ptr, size_t size, hak_callsite_t site) {
g_free_dispatch_ssot = (env && *env == '1') ? 1 : 0;
}
#if !HAKMEM_FAST_PROFILE_PRUNE_BACKENDS
if (g_free_dispatch_ssot && __builtin_expect(mid_v3_enabled(), 0)) {
// SSOT=1: Single lookup, then dispatch
extern RegionLookupV6 region_id_lookup_cached_v6(void* ptr);
@ -279,6 +280,7 @@ void hak_free_at(void* ptr, size_t size, hak_callsite_t site) {
goto done;
}
}
#endif
{
extern int hak_pool_mid_lookup(void* ptr, size_t* out_size);

View File

@ -60,7 +60,8 @@ extern int g_hakmem_env_snapshot_ctor_mode;
// ENV gate: default OFF (research box, set =1 to enable)
// E3-4: Dual-mode - constructor init (fast) or legacy lazy init (fallback)
// Phase 18 v2: BENCH_MINIMAL conditional (constant return when HAKMEM_BENCH_MINIMAL=1)
#if HAKMEM_BENCH_MINIMAL
// Phase 63: FAST_PROFILE_FIXED conditional (constant return for FAST profile builds)
#if HAKMEM_BENCH_MINIMAL || HAKMEM_FAST_PROFILE_FIXED
// In bench mode, snapshot is always enabled (one-time cost, compile-away benefit)
static inline bool hakmem_env_snapshot_enabled(void) {
return 1;

View File

@ -11,9 +11,14 @@
#pragma once
#include "../hakmem_config.h"
#include "../hakmem_build_flags.h"
#include <stdlib.h>
static inline int hak_learner_env_should_run(void) {
#if HAKMEM_BENCH_MINIMAL || HAKMEM_FAST_PROFILE_FIXED || HAKMEM_FAST_PROFILE_PRUNE_BACKENDS
// Phase 63/64: Disable learning layer in FAST profile-fixed/pruned builds
return 0;
#endif
static int g_inited = 0;
static int g_effective = 0;
if (__builtin_expect(!g_inited, 0)) {
@ -30,4 +35,3 @@ static inline int hak_learner_env_should_run(void) {
}
return g_effective;
}

View File

@ -30,6 +30,7 @@
#include <stdatomic.h>
#include <stdlib.h>
#include "../hakmem_build_flags.h"
// Forward declaration for cross-box includes
static inline int malloc_tiny_direct_enabled(void);
@ -41,6 +42,9 @@ static inline int malloc_tiny_direct_enabled(void);
// Lazy init: Check ENV variable on first call, cache result
// Thread-safe: Read-only after init (atomic store, relaxed load)
static inline int malloc_tiny_direct_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 0;
#endif
static _Atomic int cached = -1; // -1 = uninitialized
int val = atomic_load_explicit(&cached, memory_order_relaxed);

View File

@ -44,6 +44,9 @@ extern __thread struct malloc_wrapper_env_snapshot g_malloc_wrapper_env;
// ENV gate: Enable/disable snapshot optimization (default: OFF, research box)
static inline int malloc_wrapper_env_snapshot_enabled(void)
{
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
static __thread int s_enabled = -1;
if (__builtin_expect(s_enabled == -1, 0)) {
const char* env = getenv("HAKMEM_MALLOC_WRAPPER_ENV_SNAPSHOT");

View File

@ -6,12 +6,18 @@
#include <stdlib.h>
#include "../hakmem_tiny_config.h"
#include "../hakmem_build_flags.h"
// ============================================================================
// HAKMEM_MID_V3_ENABLED: Master switch for MID v3
// ============================================================================
static inline int mid_v3_enabled(void) {
#if HAKMEM_FAST_PROFILE_PRUNE_BACKENDS
// Phase 64: Backend pruning - disable MID_V3 in Mixed workload
// Compile-time constant for DCE (unreachable code elimination)
return 0;
#else
static int g_enable = -1;
if (__builtin_expect(g_enable == -1, 0)) {
const char* e = getenv("HAKMEM_MID_V3_ENABLED");
@ -23,6 +29,7 @@ static inline int mid_v3_enabled(void) {
}
}
return g_enable;
#endif
}
// ============================================================================

View File

@ -8,6 +8,7 @@
#define POOL_CONFIG_BOX_H
#include "tiny_heap_env_box.h" // TinyHeap profile (C7_SAFE modes)
#include "../hakmem_build_flags.h"
#include <stdlib.h>
#include <string.h>
@ -17,12 +18,18 @@
// Pool v2 is experimental. Default OFF (use legacy v1 path).
static inline int hak_pool_v2_enabled(void) {
#if HAKMEM_FAST_PROFILE_PRUNE_BACKENDS
// Phase 64: Backend pruning - disable POOL_V2 in Mixed workload
// Compile-time constant for DCE (unreachable code elimination)
return 0;
#else
static int g = -1;
if (__builtin_expect(g == -1, 0)) {
const char* e = getenv("HAKMEM_POOL_V2_ENABLED");
g = (e && *e && *e != '0') ? 1 : 0;
}
return g;
#endif
}
// Fine-grained switches (only used when v2 is enabled).

View File

@ -35,6 +35,7 @@ core/box/superslab_expansion_box.o: core/box/superslab_expansion_box.c \
core/box/../tiny_region_id.h core/box/../tiny_box_geometry.h \
core/box/../ptr_track.h core/box/../tiny_debug_api.h \
core/box/../box/tiny_header_hotfull_env_box.h \
core/box/../box/../hakmem_build_flags.h \
core/box/../hakmem_tiny_integrity.h core/box/../box/tiny_next_ptr_box.h \
core/hakmem_tiny_config.h core/tiny_nextptr.h core/hakmem_build_flags.h \
core/tiny_region_id.h core/superslab/superslab_inline.h \
@ -93,6 +94,7 @@ core/box/../tiny_box_geometry.h:
core/box/../ptr_track.h:
core/box/../tiny_debug_api.h:
core/box/../box/tiny_header_hotfull_env_box.h:
core/box/../box/../hakmem_build_flags.h:
core/box/../hakmem_tiny_integrity.h:
core/box/../box/tiny_next_ptr_box.h:
core/hakmem_tiny_config.h:

View File

@ -15,6 +15,7 @@
#include <stdatomic.h>
#include <stdlib.h>
#include <stdio.h>
#include "../hakmem_build_flags.h"
// Global state for free static route ENV gate (defined in .c file)
// -1 = uninitialized, 0 = disabled, 1 = enabled
@ -28,6 +29,9 @@ void tiny_free_static_route_refresh_from_env(void);
// Returns: 1 if enabled, 0 if disabled (default)
// ENV: HAKMEM_FREE_STATIC_ROUTE=0/1
static inline int tiny_free_static_route_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
int current = atomic_load_explicit(&g_free_static_route_enabled, memory_order_relaxed);
if (__builtin_expect(current >= 0, 1)) {
return current;

View File

@ -30,7 +30,8 @@ extern int g_tiny_front_v3_snapshot_ready;
// ENV gate: default ON (set HAKMEM_TINY_FRONT_V3_ENABLED=0 to disable)
// Phase 35-A: BENCH_MINIMAL mode - compile-time constant (default ON)
#if HAKMEM_BENCH_MINIMAL
// Phase 63: FAST_PROFILE_FIXED - compile-time constant (FAST profile defaults)
#if HAKMEM_BENCH_MINIMAL || HAKMEM_FAST_PROFILE_FIXED
static inline bool tiny_front_v3_enabled(void) {
return true; // Fixed ON in bench mode (default behavior)
}
@ -51,6 +52,9 @@ static inline bool tiny_front_v3_enabled(void) {
// Optional: size→class LUT gate (default ON, set HAKMEM_TINY_FRONT_V3_LUT_ENABLED=0 to disable)
static inline bool tiny_front_v3_lut_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return true;
#endif
static int g = -1;
if (__builtin_expect(g == -1, 0)) {
const char* e = getenv("HAKMEM_TINY_FRONT_V3_LUT_ENABLED");
@ -65,6 +69,9 @@ static inline bool tiny_front_v3_lut_enabled(void) {
// Optional: route fast path (Tiny LUT→1 switch). Default OFF for easy rollback.
static inline bool tiny_front_v3_route_fast_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return false;
#endif
static int g = -1;
if (__builtin_expect(g == -1, 0)) {
const char* e = getenv("HAKMEM_TINY_FRONT_V3_ROUTE_FAST_ENABLED");
@ -75,6 +82,9 @@ static inline bool tiny_front_v3_route_fast_enabled(void) {
// C7 v3 free 専用 ptr fast classify gate (default OFF)
static inline bool tiny_ptr_fast_classify_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return true;
#endif
static int g = -1;
if (__builtin_expect(g == -1, 0)) {
const char* e = getenv("HAKMEM_TINY_PTR_FAST_CLASSIFY_ENABLED");
@ -89,6 +99,9 @@ static inline bool tiny_ptr_fast_classify_enabled(void) {
// C7/C6 v4 free 用 fast classify gate (default OFF)
static inline bool tiny_ptr_fast_classify_v4_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return false;
#endif
static int g = -1;
if (__builtin_expect(g == -1, 0)) {
const char* e = getenv("HAKMEM_TINY_PTR_FAST_CLASSIFY_V4_ENABLED");
@ -99,6 +112,9 @@ static inline bool tiny_ptr_fast_classify_v4_enabled(void) {
// Optional stats gate
static inline bool tiny_front_v3_stats_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return false;
#endif
static int g = -1;
if (__builtin_expect(g == -1, 0)) {
const char* e = getenv("HAKMEM_TINY_FRONT_V3_STATS");
@ -109,6 +125,9 @@ static inline bool tiny_front_v3_stats_enabled(void) {
// Header v3 experimental gate (default OFF)
static inline bool tiny_header_v3_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return false;
#endif
static int g = -1;
if (__builtin_expect(g == -1, 0)) {
const char* e = getenv("HAKMEM_TINY_HEADER_V3_ENABLED");

View File

@ -20,6 +20,7 @@
#include <stdatomic.h>
#include <stdlib.h>
#include "../hakmem_build_flags.h"
// ENV control: cached flag for tiny_header_hotfull_enabled()
// -1: uninitialized, 0: disabled (opt-out), 1: enabled (default)
@ -31,6 +32,9 @@ extern _Atomic int g_tiny_header_hotfull_enabled;
// Returns: 1 if enabled (default), 0 if disabled (opt-out with HAKMEM_TINY_HEADER_HOTFULL=0)
// Hot path: Single atomic load (after first call)
static inline int tiny_header_hotfull_enabled(void) {
#if HAKMEM_FAST_PROFILE_FIXED
return 1;
#endif
int val = atomic_load_explicit(&g_tiny_header_hotfull_enabled, memory_order_relaxed);
if (__builtin_expect(val == -1, 0)) {
// Cold path: Initialize from ENV

View File

@ -19,7 +19,8 @@
extern bool small_learner_v2_enabled(void);
// Phase 35-A: BENCH_MINIMAL mode - compile-time constant (default OFF)
#if HAKMEM_BENCH_MINIMAL
// Phase 63: FAST_PROFILE_FIXED - compile-time constant (FAST profile defaults)
#if HAKMEM_BENCH_MINIMAL || HAKMEM_FAST_PROFILE_FIXED
static inline int tiny_metadata_cache_enabled(void) {
return 0; // Fixed OFF in bench mode (default behavior)
}

View File

@ -221,6 +221,28 @@
# define HAKMEM_ROUTE 0
#endif
// Phase 63: FAST Profile-Fixed Build (compile-time constant gates)
// HAKMEM_FAST_PROFILE_FIXED: Fix all MIXED_TINYV3_C7_SAFE gates to compile-time constants
// When =1: Top 5-8 gates (tiny_front_v3_enabled, front_fastlane_enabled, etc.)
// return compile-time constants, learning layer disabled (DCE expected +5-10%)
// When =0: Normal runtime gate behavior (default, backward compatible)
// Usage: Build with -DHAKMEM_FAST_PROFILE_FIXED=1 for speed-first FAST binaries
// Only for FAST builds; Standard/OBSERVE keep runtime gates unchanged
#ifndef HAKMEM_FAST_PROFILE_FIXED
# define HAKMEM_FAST_PROFILE_FIXED 0
#endif
// Phase 64: Backend Pruning (compile-time unreachable code elimination)
// HAKMEM_FAST_PROFILE_PRUNE_BACKENDS: Disable unused backends in Mixed workload
// When =1: Backend gates (mid_v3_enabled, pool_v2_enabled, etc.) return false at compile-time
// LTO DCE eliminates unreachable code paths (expected +5-10%)
// When =0: Normal runtime gate behavior (default, backward compatible)
// Usage: Build with -DHAKMEM_FAST_PROFILE_PRUNE_BACKENDS=1 for ultra-fast FAST binaries
// Backends disabled: MID_V3, POOL_V2, SMALL_HEAP_V4, LEARNER, etc.
#ifndef HAKMEM_FAST_PROFILE_PRUNE_BACKENDS
# define HAKMEM_FAST_PROFILE_PRUNE_BACKENDS 0
#endif
// Bench-only knobs (default values; can be overridden via build flags)
#ifndef HAKMEM_TINY_BENCH_REFILL
# define HAKMEM_TINY_BENCH_REFILL 8

View File

@ -247,7 +247,8 @@ uint32_t small_learner_v2_retire_efficiency_pct(uint32_t class_idx) {
// ============================================================================
// Phase 36: BENCH_MINIMAL mode - learner is disabled (bench profiles don't use learner)
#if HAKMEM_BENCH_MINIMAL
// Phase 63: FAST_PROFILE_FIXED - learner disabled in fixed FAST profile builds
#if HAKMEM_BENCH_MINIMAL || HAKMEM_FAST_PROFILE_FIXED
bool small_learner_v2_enabled(void) {
return false; // Fixed OFF in bench mode
}

View File

@ -21,7 +21,8 @@ static SmallLearnerStatsV7 g_small_learner_stats_v7;
static int g_learner_v7_enabled = -1; // -1: uninit, 0: disabled, 1: enabled
// Phase 36: BENCH_MINIMAL mode - learner is disabled (bench profiles don't use learner)
#if HAKMEM_BENCH_MINIMAL
// Phase 63: FAST_PROFILE_FIXED - learner disabled in fixed FAST profile builds
#if HAKMEM_BENCH_MINIMAL || HAKMEM_FAST_PROFILE_FIXED
static inline int learner_v7_enabled(void) {
return 0; // Fixed OFF in bench mode
}

View File

@ -0,0 +1,568 @@
# CURRENT_TASK Archive
このファイルは、整理前の `CURRENT_TASK.md`(履歴ログを含む)をそのまま保存したアーカイブ。
現行の「次にやること」は `CURRENT_TASK.md` を正とする。
---
# CURRENT_TASKRolling
## 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 algorithmicmicro-opt では埋め難い
**Phase 62B+: 次の方針TBD**
- Option A: tiny_region_id_write_header optimization (+0.5-1.5%, very high risk)
- Option B: Production readiness pivot48.34% acceptdocumentation/telemetry focus
- Option C: Algorithmic redesignbatching, prefault strategypost-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 skiprefill 時に 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 は期待より小さい hotspot2.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 modeMIXED_TINYV3_C7_SAFE baseline rebaseM1 (50%) baseline 更新
- 判定: **COMPLETE**hakmem: 58.478M ops/s, mimalloc: 120.979M ops/s, ratio: 48.34%
- Profile 変更: Balanced Speed-firstPhase 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-downPhase 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 drift5分 soak, EXCELLENT
- **Throughput stability**: allocator positive drift (+0.8%-0.9%) & low CV (1.5%-2.1%, EXCELLENT)
- **Tail latency**: TODOPhase 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 drift5分 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 meanmimalloc 2.28%, system 0.77%
- **p99/p50 ratio**: 1.024tail 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 designpersistent 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-inRSS <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 testing30-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 testing60s 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 reductiontail latency 改善Phase 52 で課題特定済み
- 候補B: Throughput gap closuremimalloc 50% 55%、algorithmic improvement 必要
- 候補C: LEAN+FREE/DONTNEED extended validationextreme 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 MBmetadata 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 5457: 完了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+OFFprewarm 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 modeLEAN+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 CasesPhase 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 defaultLEAN 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更新**:
- M150%は実質達成したが次は **/学習層/安定度を保ったまま +510%」** を狙う
**Next Phases**:
- **Phase 60**: alloc pass-down SSOT重複計算の排除、+12% を積む
- **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 boundnot 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 43header write tax: `docs/analysis/PHASE43_HEADER_WRITE_TAX_REDUCTION_INSTRUCTIONS.md`NO-GO
- Phase 44cache-miss / writeback profiling: `docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.md`COMPLETE
- Phase 45dependency chain analysis: `docs/analysis/PHASE45_DEPENDENCY_CHAIN_ANALYSIS_RESULTS.md`COMPLETE
- Phase 46TBD: dependency chain optimization: 未作成
## 4) 直近のログ(要点だけ)
- Phase 2434: 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 taxgates runtime 実行なし
- 教訓: ASM presence impactruntime 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 skipnextptr 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 uncertaintyreproducibility 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-architectureregister 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 で競合 allocatormimalloc/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+: TBDdependency 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`

View File

@ -11,22 +11,29 @@
mimalloc との比較は **FAST build** で行うStandard は fixed tax を含むため公平でない)。
## Current snapshot2025-12-17, Phase 59b rebase
## Current snapshot2025-12-17, Phase 68 PGO — 新 baseline
計測条件(再現の正):
- Mixed: `scripts/run_mixed_10_cleanenv.sh``ITERS=20000000 WS=400`
- 10-run mean/median
- Git: master (Phase 59b)
- Git: master (Phase 68 PGO, seed/WS diversified profile)
- **Baseline binary**: `bench_random_mixed_hakmem_minimal_pgo` (Phase 68 upgraded)
- **Stability**: Phase 66: 3 iterations, +3.0% mean, variance <±1% | Phase 68: 10-run, +1.19% vs Phase 66 (GO)
### hakmem Build Variants同一バイナリレイアウト
| Build | Mean (M ops/s) | Median (M ops/s) | vs mimalloc | 備考 |
|-------|----------------|------------------|-------------|------|
| **FAST v3** | 58.478 | 58.876 | **48.34%** | 性能評価の正Phase 59b rebase, `MIXED_TINYV3_C7_SAFE` Speed-first |
| FAST v3 | 58.478 | 58.876 | 48.34% | 旧 baselinePhase 59b rebase)。性能評価の正から昇格 → Phase 66 PGO へ |
| FAST v3 + PGO | 59.80 | 60.25 | 49.41% | Phase 47: NEUTRAL (+0.27% mean, +1.02% median, research box) |
| **FAST v3 + PGO (Phase 66)** | **60.89** | **61.35** | **50.32%** | **GO: +3.0% mean (3回検証済み、安定 <±1%)**。Phase 66 PGO initial baseline |
| **FAST v3 + PGO (Phase 68)** | **61.614** | **61.924** | **50.93%** | **GO: +1.19% vs Phase 66** ✓ (seed/WS diversification) → **昇格済み 新 FAST baseline** ✓ |
| Standard | 53.50 | - | 44.21% | 安全・互換基準Phase 48 前計測、要 rebase |
| OBSERVE | TBD | - | - | 診断カウンタ ON |
補足:
- Phase 63: `make bench_random_mixed_hakmem_fast_fixed``HAKMEM_FAST_PROFILE_FIXED=1`)は research buildGO 未達時は SSOT に載せない)。結果は `docs/analysis/PHASE63_FAST_PROFILE_FIXED_BUILD_RESULTS.md`
**FAST vs Standard delta: +10.6%**Standard 側は Phase 48 前計測、mimalloc baseline 変更で ratio 調整)
**Phase 59b Notes:**
@ -58,26 +65,33 @@ Notes:
推奨マイルストーンMixed 161024B, FAST build
| Milestone | Target | Current (FAST v3) | Status |
|-----------|--------|-------------------|--------|
| M1 | mimalloc の **50%** | 49.13% | 🟢 **ACHIEVED** (Phase 59, within statistical noise) |
| Milestone | Target | Current (FAST v3 + PGO Phase 68) | Status |
|-----------|--------|-----------------------------------|--------|
| M1 | mimalloc の **50%** | 50.93% | 🟢 **EXCEEDED** (Phase 68 PGO, 10-run verified) |
| M2 | mimalloc の **55%** | - | 🔴 未達(構造改造必要)|
| M3 | mimalloc の **60%** | - | 🔴 未達(構造改造必要)|
| M4 | mimalloc の **6570%** | - | 🔴 未達(構造改造必要)|
**現状:** FAST v3 = 59.184M ops/s = mimalloc の 49.13%Phase 59 rebase, Balanced mode
**現状:** FAST v3 + PGO (Phase 68) = 61.614M ops/s = mimalloc の 50.93%seed/WS diversified, 10-run 検証済み
**Phase 59 rebase 影響:**
- hakmem: 59.15M → 59.184M (+0.06%, stable within noise)
- mimalloc: 121.01M → 120.466M (-0.45%, minor environment drift)
- Ratio: 48.88% → 49.13% (+0.25pp, steady progress)
- M1 (50%) gap: -0.87% (within statistical noise, effectively achieved)
**Phase 68 PGO 昇格Phase 66 → Phase 68 upgrade:**
- Phase 66 baseline: 60.89M ops/s = 50.32% (+3.0% mean, 3-run stable)
- Phase 68 baseline: 61.614M ops/s = 50.93% (+1.19% vs Phase 66, 10-run verified)
- Profile change: seed/WS diversification (WS 3種 → 5種, seed 1種 → 3種)
- M1 (50%) achievement: **EXCEEDED** (+0.93pp above target, vs +0.32pp in Phase 66)
**M1 Achievement Analysis:**
- Gap to 50%: 0.87% (smaller than hakmem CV 1.31% and mimalloc drift 0.45%)
- Production perspective: 49.13% vs 50.00% is indistinguishable
- Stability advantage: hakmem CV 1.31% vs mimalloc CV 3.50% (2.68x more stable)
- **Verdict**: M1 effectively achieved, ready for production deployment
- Phase 66: Gap to 50%: +0.32% (EXCEEDED target, first time above 50%)
- Phase 68: Gap to 50%: +0.93% (further improved via seed/WS diversification)
- Production perspective: 50.93% vs 50.00% is robustly statistically achieved
- Stability advantage: Phase 66 (3-run <±1%) → Phase 68 (10-run +1.19%, improved reproducibility)
- **Verdict**: M1 **EXCEEDED** (+0.93pp), M2 (55%) に向けて次フェーズ検討
**Phase 68 Benefits Over Phase 66:**
- Reduced PGO overfitting via seed/WS diversification
- +1.19% improvement from better profile representation
- More representative of production workload variance
- Higher confidence in baseline stability
※注意: `mimalloc/system/jemalloc` の参照値は環境ドリフトでズレるため、定期的に再ベースラインする。
- Phase 48 完了: `docs/analysis/PHASE48_REBASE_ALLOCATORS_AND_STABILITY_SUITE_RESULTS.md`

View File

@ -0,0 +1,96 @@
# Phase 63: FAST Profile-Fixed Buildcompile-time 定数化で +510% を狙う)
背景:
- Phase 60 / 62A が示した通り、alloc/free hot path は LTO で既にかなり最適化されており、**micro-opt は layout tax で負けやすい**。
- +510% を狙うには「同じ層を保ったまま、**実行時 gate を compile-time 定数に落として DCE**」が最も現実的。
- これは Box Theory に反しない:**“FAST専用の build profile 箱”**として分離し、Standard/OBSERVE は維持する。
目的:
- FAST build でのみ、主要ノブを compile-time 定数化して分岐・lazy-init を消し、**+510%** を狙う。
- 学習層は存在を保持しつつ **FAST では FROZEN常に false**に落とすStandard/OBSERVE は従来どおり)。
成功基準:
- FAST build の Mixed 10-run mean で **+2.0% 以上 = GO**
- build 変更は layout も動くため閾値を上げる(過去の -2% precedent を踏まえる)。
- ±2.0% = NEUTRALfreeze
- -2.0% 以下 = NO-GOrevert
計測の正:
- `BENCH_BIN=./bench_random_mixed_hakmem_minimal scripts/run_mixed_10_cleanenv.sh`
- profile は `MIXED_TINYV3_C7_SAFE`Speed-firstを正にする
---
## Step 1: Build flagSSOT
`core/hakmem_build_flags.h` に追加:
- `HAKMEM_FAST_PROFILE_FIXED=0/1`default 0
FAST 専用ターゲットで `-DHAKMEM_FAST_PROFILE_FIXED=1` を渡す。
---
## Step 2: “固定すべき gate” のリスト化(まず 5〜8 個に限定)
候補(例):
- `tiny_front_v3_enabled()` → 1
- `tiny_front_v3_lut_enabled()` → 1
- `tiny_front_v3_c7_ultra_enabled()` → 1
- `tiny_metadata_cache_enabled()` → 0FAST正では不要なら
- `small_learner_v2_enabled()` / `learner_v7_enabled()` → 0
- `front_fastlane_enabled()` → 1既にプリセットで 1
- `fastlane_direct_enabled()` → 1既にプリセットで 1
ルール:
- “FASTプリセットで常にON/OFF” が確定しているものだけを固定化する。
- それ以外は runtime gate を維持(符号反転を避ける)。
---
## Step 3: 各 gate を build flag で定数化
方針:
- `#if HAKMEM_FAST_PROFILE_FIXED` のときだけ `return true/false;`
- それ以外は既存実装ENV snapshot / lazy initを維持
注意:
- 新しい関数分割は増やさないlayout tax 回避)。
- `__builtin_expect` は “ENVで変わる条件” には付けないPhase 19 の教訓)。
---
## Step 4: FAST v4 ターゲット追加(別バイナリ)
`Makefile`:
- `bench_random_mixed_hakmem_fast_fixed` などの新ターゲットを追加
- `bench_random_mixed_hakmem_minimal` をベースに、追加 CFLAGS で `HAKMEM_FAST_PROFILE_FIXED=1`
例:
- `make bench_random_mixed_hakmem_fast_fixed`
- `BENCH_BIN=./bench_random_mixed_hakmem_fast_fixed scripts/run_mixed_10_cleanenv.sh`
---
## Step 5: A/B10-run
Abaseline:
- `bench_random_mixed_hakmem_minimal`
Btreatment:
- `bench_random_mixed_hakmem_fast_fixed`
判定:
- GO: +2.0% 以上
- NEUTRAL: ±2.0%
- NO-GO: -2.0% 以下
必須で併記:
- mean / median / CV
- `perf stat -e cycles,instructions,branches,branch-misses,iTLB-load-misses,dTLB-load-misses,cache-misses`200M iters
---
## Rollback
- `HAKMEM_FAST_PROFILE_FIXED=0`(既定)
- FAST v4 ターゲットは research として残してよいが、Standard/OBSERVE への影響を出さない。

View File

@ -0,0 +1,50 @@
# Phase 63: FAST Profile-Fixed Build結果
目的:
- FASTベンチ専用で、MIXED_TINYV3_C7_SAFE の「常時ON/OFFが確定している gate」を compile-time 定数に落として DCE を狙う。
- link-out/物理削除は避け、compile-time 分岐のみで可逆にするlayout tax 回避の方針維持)。
## 実装
- Build flag: `HAKMEM_FAST_PROFILE_FIXED=0/1`default 0
- 新ターゲット: `make bench_random_mixed_hakmem_fast_fixed`
- `-DHAKMEM_BENCH_MINIMAL=1 -DHAKMEM_FAST_PROFILE_FIXED=1`
- baseline は `bench_random_mixed_hakmem_minimal`
主な定数化FAST fixed のみ):
- `front_fastlane_enabled()` → 1
- `front_fastlane_class_mask()` → 0xFF
- `front_fastlane_free_dedup_enabled()` → 1
- `fastlane_direct_enabled()` → 1
- `tiny_free_static_route_enabled()` → 1
- `free_tiny_direct_enabled()` → 1
- `malloc_wrapper_env_snapshot_enabled()` / `free_wrapper_env_snapshot_enabled()` → 1
- `tiny_header_hotfull_enabled()` → 1
- `malloc_tiny_direct_enabled()` → 0research box
- `front_fastlane_alloc_legacy_direct_enabled()` → 0research box
- `hak_learner_env_should_run()` → 0
補足:
- `front_fastlane_alloc_legacy_direct_env_refresh_from_env()` はリンク整合のためシンボルは保持しつつ、FAST fixed では no-op/固定OFFにした。
## A/BMixed 10-run, clean env
- Baseline: `BENCH_BIN=./bench_random_mixed_hakmem_minimal scripts/run_mixed_10_cleanenv.sh`
- Treatment: `BENCH_BIN=./bench_random_mixed_hakmem_fast_fixed scripts/run_mixed_10_cleanenv.sh`
結果:
- Baseline mean: 61.997 M ops/s
- Treatment mean: 62.387 M ops/s
- Delta (mean): **+0.63%**
- Baseline median: 62.055 M ops/s
- Treatment median: 62.457 M ops/s
判定:
- **NEUTRAL**Phase 63 の GO 基準: +2.0% mean 以上には未達)
- ただし正方向のシグナルはあるため、FAST fixed build は research build として維持。
## 次の判断
- 追加の gate 定数化は「実行確認perf runtime」が取れたものだけを対象にする。
- 触っても 0.5% 未満が続く場合は、Phase 63 を打ち切り(“固定税削減”は Phase 2439 で概ね枯渇済み)として、別の軸へ移行する。

View File

@ -0,0 +1,180 @@
# Phase 64: Backend Pruning via Compile-time Constants (DCE)
**Status**: ❌ NO-GO (Regression: -4.05%)
## Executive Summary
Phase 64 attempted to optimize hakmem by making unused backend allocation paths (MID_V3, POOL_V2) unreachable at compile-time, enabling LTO Dead Code Elimination (DCE) to remove them entirely from the binary. The expected target was **+5-10% performance gain** via code size reduction and improved I-cache locality.
**Result**: The strategy achieved significant instruction reduction (-26%, from 3.87B to 2.87B per operation) but produced a **-4.05% throughput regression** on the Mixed workload, failing the +2.0% GO threshold.
## Implementation
### Build Flags Added
- `HAKMEM_FAST_PROFILE_PRUNE_BACKENDS=1`: Master switch to activate backend pruning
### Code Changes
1. **hak_alloc_api.inc.h** (lines 83-120): Wrapped MID_V3 alloc dispatch with `#if !HAKMEM_FAST_PROFILE_PRUNE_BACKENDS`
2. **hak_free_api.inc.h** (lines 242-283): Wrapped MID_V3 free dispatch (both SSOT=1 and SSOT=0 paths)
3. **mid_hotbox_v3_env_box.h** (lines 15-33): Added compile-time constant `mid_v3_enabled()` returning 0
4. **pool_config_box.h** (lines 20-33): Added compile-time constant `hak_pool_v2_enabled()` returning 0
5. **learner_env_box.h** (lines 18-20): Added pruning flag to learning layer disable condition
6. **Makefile** (lines 672-680): Added target `bench_random_mixed_hakmem_fast_pruned`
## A/B Test Results (10 runs each)
### Baseline: bench_random_mixed_hakmem_minimal
```
Run 1: 60,022,164 ops/s
Run 2: 57,772,821 ops/s
Run 3: 59,633,856 ops/s
Run 4: 60,658,837 ops/s
Run 5: 58,595,231 ops/s
Run 6: 59,376,766 ops/s
Run 7: 58,661,246 ops/s
Run 8: 58,110,953 ops/s
Run 9: 58,952,756 ops/s
Run 10: 59,331,245 ops/s
Average: 59,111,588 ops/s
Median: 59,142,000 ops/s
Stdev: 875,766 ops/s
Range: 57,772,821 - 60,658,837 ops/s
```
### Treatment: bench_random_mixed_hakmem_fast_pruned
```
Run 1: 55,339,952 ops/s
Run 2: 56,847,444 ops/s
Run 3: 58,161,283 ops/s
Run 4: 58,645,002 ops/s
Run 5: 55,615,903 ops/s
Run 6: 55,984,988 ops/s
Run 7: 56,979,027 ops/s
Run 8: 55,851,054 ops/s
Run 9: 57,196,418 ops/s
Run 10: 56,529,372 ops/s
Average: 56,715,044 ops/s
Median: 56,688,408 ops/s
Stdev: 1,082,600 ops/s
Range: 55,339,952 - 58,645,002 ops/s
```
### Performance Delta
- **Average Change**: -4.05% ❌
- **Median Change**: -4.15% ❌
- **GO Threshold**: +2.0%
- **Verdict**: NO-GO (regression exceeds negative tolerance)
## Performance Counter Analysis (perf stat, 5 runs each)
### Baseline: bench_random_mixed_hakmem_minimal
```
Cycles: 1,703,775,790 (baseline)
Instructions: 3,866,028,123 (baseline)
IPC: 2.27 insns/cycle
Branches: 945,213,995
Branch-misses: 23,682,440 (2.51% of branches)
Cache-misses: 420,262
```
### Treatment: bench_random_mixed_hakmem_fast_pruned
```
Cycles: 1,608,678,889 (-5.6% vs baseline)
Instructions: 2,870,328,700 (-25.8% vs baseline) ✓
IPC: 1.78 insns/cycle (-21.6%)
Branches: 629,997,382 (-33.3% vs baseline) ✓
Branch-misses: 23,622,772 (-0.3% count, but +3.75% rate vs baseline)
Cache-misses: 501,446 (+19.3% vs baseline)
```
## Analysis
### Success: Instruction Reduction
The compile-time backend pruning achieved excellent dead code elimination:
- **-26% instruction count**: Massive reduction from 3.87B to 2.87B instructions/op
- **-33% branch count**: Reduction from 945M to 630M branches/op
- **-5.6% cycle count**: Modest cycle reduction despite heavy pruning
This confirms that LTO DCE is working correctly and removing the MID_V3 and POOL_V2 code paths.
### Failure: Throughput Regression
Despite massive code reduction, throughput regressed by -4.05%, indicating:
**Hypothesis 1: Bad I-Cache Locality**
- Treatment has fewer branches (-33%) but higher branch-miss rate (3.75% vs 2.51%)
- This suggests code layout became worse during linker optimization
- Remaining critical paths may have been scattered across memory
- Similar to Phase 62A "layout tax" pattern
**Hypothesis 2: Critical Path Changed**
- IPC dropped from 2.27 to 1.78 instructions/cycle (-21.6%)
- This indicates the CPU is less efficient at executing the pruned code
- Cache hierarchy may be stressed despite fewer instructions (confirmed: +19% cache-misses)
- Reduced instruction diversity may confuse branch prediction
**Hypothesis 3: Microarchitecture Sensitivity**
- The pruned code path may have different memory access patterns
- Allocation patterns route through different backends (all Tiny now)
- Contention on TLS caches may be higher without MID_V3 pressure relief
### Why +5-10% Didn't Materialize
The expected +5-10% gain assumed:
1. Code size reduction → I-cache improvement ✗ (layout tax negative)
2. Fewer branches → Better prediction ✗ (branch-miss rate increased)
3. Simplified dispatch logic → Reduced overhead ✗ (IPC decreased)
The Mixed workload (257-768B allocations) benefits from MID_V3's specialized TLS lane caching. By removing it, all those allocations now route through the Tiny fast path, which:
- May have reduced TLS cache efficiency
- Increases contention on shared structures
- Affects memory layout and I-cache behavior
## Related Patterns
### Phase 62A: "Layout Tax" Pattern
- Phase 62A (C7 ULTRA Alloc DepChain Trim): -0.71% regression
- Both Phases showed code size improvements but IPC/layout deterioration
- This confirms that LTO + function-level optimizations create layout tax
### Successful Similar Phases
- None found that achieved code elimination + performance gain simultaneously
## Recommendations
### Path Forward Options
**Option A: Abandon Backend Pruning (Recommended)**
- The layout tax pattern is consistent across phases
- Removing code paths without architectural restructuring doesn't help
- Focus on algorithmic improvements instead
**Option B: Research Backend Pruning + Linker Optimizations**
- Try `--gc-sections` + section reordering (Phase 18 NO-GO, but different context)
- Experiment with PGO-guided section layout
- May require significant research investment
**Option C: Profile-Guided Backend Selection**
- Instead of compile-time removal, use runtime PGO to select optimal backend
- Keep both MID_V3 and Tiny, but bias allocation based on profile
- Trade size for flexibility (likely not worth it)
## Conclusion
Phase 64 successfully implemented compile-time backend pruning and achieved 26% instruction reduction through LTO DCE. However, the strategy backfired due to layout tax and microarchitecture sensitivity, producing a -4.05% throughput regression.
This phase validates an important insight: **code elimination alone is insufficient**. Hakmem's performance depends on:
1. **Hot path efficiency** (IPC, branch prediction)
2. **Memory layout** (I-cache, D-cache)
3. **Architectural symmetry** (balanced pathways reduce contention)
Removing entire backends disrupts this balance, despite reducing instruction count.
---
**Artifacts**:
- Baseline: `bench_random_mixed_hakmem_minimal` (BENCH_MINIMAL=1)
- Treatment: `bench_random_mixed_hakmem_fast_pruned` (BENCH_MINIMAL=1 + FAST_PROFILE_FIXED=1 + FAST_PROFILE_PRUNE_BACKENDS=1)
**Next Phase**: Back to algorithm-level optimizations or investigate why IPC dropped despite simpler code.

View File

@ -0,0 +1,79 @@
# Phase 65: Hot Symbol Orderinglayout tax を狙い撃ち)
背景:
- Phase 64 が示した通り「コードを減らす/DCEする」だけでは、layout tax で IPC/branch/cache が悪化し得る。
- `-ffunction-sections/--gc-sections` は Phase 18 precedent で破壊的になりやすい。
- そこで Phase 65 は **“削らずに並べる”**:リンカの symbol ordering を使い、hot text を連続配置して I-cache/BTB を安定化させる。
目的:
- Mixed FAST`bench_random_mixed_hakmem_minimal`)に対して、**+1〜5%** を狙う。
- link-out/物理削除はしないBox Theory の「戻せる」「境界1箇所」と layout 安定を両立)。
成功基準:
- Mixed 10-run mean **+2.0% 以上 = GO**build-level 変更のため閾値は高め)
- ±2.0% = NEUTRALresearch build として保持)
- -2.0% 以下 = NO-GOrevert
---
## Step 0: 事前条件
- baseline build:
- `make bench_random_mixed_hakmem_minimal`
- baseline run:
- `BENCH_BIN=./bench_random_mixed_hakmem_minimal scripts/run_mixed_10_cleanenv.sh`
---
## Step 1: hot symbol list を作る手作業でOK
1) `mkdir -p build`
2) `build/hot_syms.txt` を作る(例:
```
malloc
free
front_fastlane_try_malloc
front_fastlane_try_free
malloc_tiny_fast
free_tiny_fast
tiny_c7_ultra_alloc
tiny_c7_ultra_free
tiny_region_id_write_header
unified_cache_push
unified_cache_pop
small_policy_v7_snapshot
```
ルール:
- perf の self% 上位から 10〜30 個に限定(増やしすぎると order file 自体がノイズになる)
- “wrapper 名だけ” ではなく **本当に hot な leaf** を含める
- 関数名は `nm -n ./bench_random_mixed_hakmem_minimal | rg ' T '` などで確認
---
## Step 2: ordered FAST build
- `make bench_random_mixed_hakmem_fast_ordered`
---
## Step 3: A/BMixed 10-run
baseline:
- `BENCH_BIN=./bench_random_mixed_hakmem_minimal scripts/run_mixed_10_cleanenv.sh`
treatment:
- `BENCH_BIN=./bench_random_mixed_hakmem_fast_ordered scripts/run_mixed_10_cleanenv.sh`
必須で perf stat200M iters 推奨):
- `perf stat -e cycles,instructions,branches,branch-misses,iTLB-load-misses,dTLB-load-misses,cache-misses -- ...`
---
## Rollback
- `make bench_random_mixed_hakmem_minimal` に戻すorder build は research のまま残してよい)
- `build/hot_syms.txt` を削除してもよい(ただし削除による layout 差の罠はベンチ比較では踏まないこと)

View File

@ -0,0 +1,105 @@
# Phase 65: Hot Symbol Ordering — 技術的制約により中止
**Status**: ⚠️ BLOCKED (技術的制約)
## Executive Summary
Phase 65 は linker の symbol ordering file を使用して hot function を連続配置し、layout tax を減らすアプローチを試みた。しかし、GCC + LTO 環境では技術的に実現不可能であることが判明した。
## 試行内容
1. **perf profiling** で hot function を特定:
- malloc (27.84%)
- free (24.75%)
- main (22.33%)
- free_tiny_fast_compute_route_and_heap (3.94%)
- tiny_region_id_write_header.lto_priv.0 (3.59%)
- tiny_c7_ultra_alloc.constprop.0 (3.47%)
- unified_cache_push (3.37%)
2. **`build/hot_syms.txt`** を作成17 symbols
3. **Makefile target** `bench_random_mixed_hakmem_fast_ordered` を追加:
```make
EXTRA_LDFLAGS='-fuse-ld=lld -Wl,--symbol-ordering-file=build/hot_syms.txt'
```
## 遭遇した技術的制約
### 問題 1: GNU ld は `--symbol-ordering-file` をサポートしない
```
/usr/bin/ld: 認識できないオプション '--symbol-ordering-file=build/hot_syms.txt' です
```
`--symbol-ordering-file` は LLVM lld linker 固有の機能。
### 問題 2: GCC LTO と lld は非互換
```
ld.lld: error: undefined symbol: main
>>> referenced by Scrt1.o:(_start)
```
GCC は独自の LTO format (GIMPLE IR) を使用するため、lld が理解できない。
### 問題 3: LTO が hot function をインライン化
`nm` の出力を見ると、バイナリにエクスポートされるシンボルは僅か 33 個:
- hot function の多くは internal (`t`) であり、LTO によってインライン化/マージされる
- `.lto_priv.0`, `.constprop.0` などの suffix は LTO が生成した内部シンボル
- これらは ordering file で参照しても効果がない
### 問題 4: LTO なしだと baseline と条件が違う
LTO を無効にして lld を使う場合:
- Symbol ordering は可能
- しかし LTO の性能向上5-10%)を失う
- A/B 比較が unfair になる
## 結論
**Phase 65 は技術的制約により中止。**
Symbol ordering アプローチは GCC + LTO 環境では以下の理由で非実現的:
1. **Linker 非互換**: `--symbol-ordering-file` は lld 専用
2. **LTO 非互換**: GCC LTO format と lld は互換性がない
3. **Symbol 消失**: LTO が hot function をインライン化し、ordering 対象が消える
4. **Trade-off**: LTO を諦めると symbol ordering 以上の性能低下が発生
## Alternative Strategies
Phase 65 の教訓を踏まえ、以下のアプローチを推奨:
### Option A: PGO (Profile-Guided Optimization) - 推奨
GCC の `-fprofile-generate` + `-fprofile-use` を使用:
- Compiler が hot path を自動で最適配置
- LTO との組み合わせが可能
- Symbol ordering より強力
### Option B: `-fno-inline` + Symbol Ordering (研究用)
特定の hot function に `__attribute__((noinline))` を付与:
- LTO によるインライン化を防止
- Symbol として残るため ordering 可能
- 性能 trade-off の検証が必要
### Option C: Clang/LLVM に移行 (大規模変更)
全ビルドを Clang に移行:
- lld と完全互換
- Symbol ordering + LTO が両立可能
- Migration cost が高い
## 次のステップ
1. **Phase 66 (PGO)**: `-fprofile-generate` / `-fprofile-use` を試行
2. **Phase 67 (alternative)**: 他の layout tax 削減手法を調査
---
**Artifacts**:
- `build/hot_syms.txt`: Hot symbol list (残存、将来の参照用)
- Makefile target: `bench_random_mixed_hakmem_fast_ordered` (USE_LTO=0 でのみ動作)

View File

@ -0,0 +1,51 @@
# Phase 66: PGO (FAST minimal, GCC+LTO) — Instructions
## Goal
Use GCC PGO **without changing the toolchain** (keep GCC + `-flto`) to reduce layout tax and improve inline/layout decisions for the FAST minimal benchmark binary.
## Principles (Box Theory)
- No “link-out” pruning for performance (layout tax risk).
- A/B must remain fair: same compiler/linker/LTO; only PGO profile differs.
- Fail-fast: profile collection failures abort.
## Workflow (Makefile SSOT)
### Full pipeline
```sh
make pgo-fast-full
```
This runs:
1. `make pgo-fast-profile` — builds profile-gen binaries (FAST minimal)
2. `make pgo-fast-collect` — collects `.gcda` by running deterministic workloads
3. `make pgo-fast-build` — builds PGO-optimized binary and renames it to `bench_random_mixed_hakmem_minimal_pgo`
4. Runs Mixed 10-run with `BENCH_BIN=./bench_random_mixed_hakmem_minimal_pgo`
### Manual steps (debug)
```sh
make pgo-fast-profile
make pgo-fast-collect
make pgo-fast-build
BENCH_BIN=./bench_random_mixed_hakmem_minimal_pgo scripts/run_mixed_10_cleanenv.sh
```
## Profile workloads (SSOT)
- Config file: `scripts/box/pgo_fast_profile_config.sh`
- Collector: `scripts/box/pgo_tiny_profile_box.sh`
The collector enforces a per-workload timeout and verifies `.gcda` generation.
Important:
- PGO は **training workload と benchmark preset/ENV の一致**が生命線。
- `scripts/box/pgo_fast_profile_config.sh``scripts/run_mixed_10_cleanenv.sh` 経由で profile を取るmismatch を避ける)。
## GO / NO-GO
- GO: Mixed 10-run mean **+1.0%** or more vs `bench_random_mixed_hakmem_minimal`
- NEUTRAL: ±1.0% → keep as research target (do not promote)
- NO-GO: -1.0% or worse → investigate profile mismatch / layout tax / workload coverage

View File

@ -0,0 +1,45 @@
# Phase 66: PGO (FAST minimal, GCC+LTO) — Results
## TL;DR
PGO は **GO**`BENCH_MINIMAL` の Mixed 10-run で **+6.58%**meanを達成。
## What changed
- Makefile: `pgo-fast-*` の PGO ワークフローを追加GCC + `-flto` を維持)
- `scripts/box/pgo_tiny_profile_box.sh`: `PGO_CONFIG` 切替対応 + workload を `bash -lc` で実行
- `scripts/box/pgo_fast_profile_config.sh`: FAST minimal 用の PGO 代表ワークロードcleanenv 前提)
- Makefile: `bench_tiny_hot_hakmem``$(TINY_BENCH_OBJS)` でリンクLTO 時の未解決参照を解消)
## A/B (Mixed 10-run, cleanenv)
計測の正:
- `scripts/run_mixed_10_cleanenv.sh``ITERS=20000000 WS=400`
- baseline: `bench_random_mixed_hakmem_minimal`
- treatment: `bench_random_mixed_hakmem_minimal_pgo`
結果n=10:
- Baseline mean: `61.718839M ops/s` / median: `61.672012M ops/s`
- PGO mean: `65.780056M ops/s` / median: `66.227247M ops/s`
- Delta: **+6.58% mean** / **+7.38% median**
Verdict: ✅ **GO**build-level のため +1.0% 以上で十分)
## Key lesson (important)
PGO は **profile mismatch で簡単に NO-GO になる**
- NG 例: `bench_random_mixed_hakmem` を “直起動” で profile 収集
- preset/ENV が一致せず、`FASTLANE_DIRECT` 等が OFF のプロファイルが混ざる
- 結果: PGO が逆方向に最適化して -5% 級の regression になり得る
- OK 例(本 Phase 66: **cleanenv 経由で profile 収集**
- `scripts/box/pgo_fast_profile_config.sh``scripts/run_mixed_10_cleanenv.sh` を使う
## How to reproduce
```sh
make pgo-fast-full
```
(手動手順は `docs/analysis/PHASE66_PGO_FAST_WITH_LTO_INSTRUCTIONS.md`

View File

@ -25,8 +25,8 @@ hakmem.o: core/hakmem.c core/hakmem.h core/hakmem_build_flags.h \
core/box/tiny_next_ptr_box.h core/hakmem_tiny_config.h \
core/tiny_nextptr.h core/tiny_region_id.h core/tiny_box_geometry.h \
core/ptr_track.h core/tiny_debug_api.h \
core/box/tiny_header_hotfull_env_box.h core/box/tiny_layout_box.h \
core/box/../hakmem_tiny_config.h core/box/../hakmem_build_flags.h \
core/box/tiny_header_hotfull_env_box.h core/box/../hakmem_build_flags.h \
core/box/tiny_layout_box.h core/box/../hakmem_tiny_config.h \
core/box/tiny_header_box.h core/box/tiny_layout_box.h \
core/box/../tiny_region_id.h core/box/tiny_header_write_once_env_box.h \
core/hakmem_elo.h core/hakmem_ace_stats.h core/hakmem_batch.h \
@ -232,9 +232,9 @@ core/tiny_box_geometry.h:
core/ptr_track.h:
core/tiny_debug_api.h:
core/box/tiny_header_hotfull_env_box.h:
core/box/../hakmem_build_flags.h:
core/box/tiny_layout_box.h:
core/box/../hakmem_tiny_config.h:
core/box/../hakmem_build_flags.h:
core/box/tiny_header_box.h:
core/box/tiny_layout_box.h:
core/box/../tiny_region_id.h:

View File

@ -20,7 +20,8 @@ hakmem_learner.o: core/hakmem_learner.c core/hakmem_learner.h \
core/superslab/../box/ss_pt_env_box.h \
core/superslab/../box/ss_pt_env_box.h core/tiny_debug_ring.h \
core/tiny_remote.h core/hakmem_tiny_superslab_constants.h \
core/box/learner_env_box.h core/box/../hakmem_config.h
core/box/learner_env_box.h core/box/../hakmem_config.h \
core/box/../hakmem_build_flags.h
core/hakmem_learner.h:
core/hakmem_internal.h:
core/hakmem.h:
@ -60,3 +61,4 @@ core/tiny_remote.h:
core/hakmem_tiny_superslab_constants.h:
core/box/learner_env_box.h:
core/box/../hakmem_config.h:
core/box/../hakmem_build_flags.h:

View File

@ -14,10 +14,10 @@ hakmem_pool.o: core/hakmem_pool.c core/hakmem_pool.h \
core/box/pool_api.inc.h core/box/pagefault_telemetry_box.h \
core/box/pool_hotbox_v2_box.h core/box/tiny_heap_env_box.h \
core/box/c7_hotpath_env_box.h core/box/pool_zero_mode_box.h \
core/box/pool_config_box.h core/box/pool_stats_box.h \
core/box/pool_config_box.h core/box/pool_mid_desc_cache_box.h \
core/box/pool_free_v1_box.h core/box/pool_stats_box.h \
core/box/pool_mid_desc_cache_box.h \
core/box/pool_config_box.h core/box/../hakmem_build_flags.h \
core/box/pool_stats_box.h core/box/pool_config_box.h \
core/box/pool_mid_desc_cache_box.h core/box/pool_free_v1_box.h \
core/box/pool_stats_box.h core/box/pool_mid_desc_cache_box.h \
core/box/pool_mid_inuse_deferred_box.h \
core/box/pool_mid_inuse_deferred_env_box.h \
core/box/pool_mid_inuse_tls_pagemap_box.h \
@ -62,6 +62,7 @@ core/box/tiny_heap_env_box.h:
core/box/c7_hotpath_env_box.h:
core/box/pool_zero_mode_box.h:
core/box/pool_config_box.h:
core/box/../hakmem_build_flags.h:
core/box/pool_stats_box.h:
core/box/pool_config_box.h:
core/box/pool_mid_desc_cache_box.h:

View File

@ -23,8 +23,8 @@ hakmem_shared_pool.o: core/hakmem_shared_pool.c \
core/ptr_track.h core/hakmem_tiny.h core/hakmem_trace.h \
core/hakmem_tiny_mini_mag.h core/box/hak_lane_classify.inc.h \
core/box/ptr_type_box.h core/tiny_debug_api.h \
core/box/tiny_header_hotfull_env_box.h core/box/tiny_layout_box.h \
core/box/../hakmem_tiny_config.h core/box/../hakmem_build_flags.h \
core/box/tiny_header_hotfull_env_box.h core/box/../hakmem_build_flags.h \
core/box/tiny_layout_box.h core/box/../hakmem_tiny_config.h \
core/box/tiny_header_box.h core/box/tiny_layout_box.h \
core/box/../tiny_region_id.h core/box/tiny_header_write_once_env_box.h \
core/box/ss_hot_cold_box.h core/box/pagefault_telemetry_box.h \
@ -94,9 +94,9 @@ core/box/hak_lane_classify.inc.h:
core/box/ptr_type_box.h:
core/tiny_debug_api.h:
core/box/tiny_header_hotfull_env_box.h:
core/box/../hakmem_build_flags.h:
core/box/tiny_layout_box.h:
core/box/../hakmem_tiny_config.h:
core/box/../hakmem_build_flags.h:
core/box/tiny_header_box.h:
core/box/tiny_layout_box.h:
core/box/../tiny_region_id.h:

View File

@ -23,8 +23,8 @@ hakmem_tiny_magazine.o: core/hakmem_tiny_magazine.c \
core/hakmem_whale.h core/box/tiny_next_ptr_box.h \
core/hakmem_tiny_config.h core/tiny_nextptr.h core/tiny_region_id.h \
core/tiny_box_geometry.h core/ptr_track.h core/tiny_debug_api.h \
core/box/tiny_header_hotfull_env_box.h core/box/tiny_layout_box.h \
core/box/../hakmem_tiny_config.h core/box/../hakmem_build_flags.h \
core/box/tiny_header_hotfull_env_box.h core/box/../hakmem_build_flags.h \
core/box/tiny_layout_box.h core/box/../hakmem_tiny_config.h \
core/box/tiny_header_box.h core/box/tiny_layout_box.h \
core/box/../tiny_region_id.h core/box/tiny_header_write_once_env_box.h \
core/box/tiny_mem_stats_box.h
@ -71,9 +71,9 @@ core/tiny_box_geometry.h:
core/ptr_track.h:
core/tiny_debug_api.h:
core/box/tiny_header_hotfull_env_box.h:
core/box/../hakmem_build_flags.h:
core/box/tiny_layout_box.h:
core/box/../hakmem_tiny_config.h:
core/box/../hakmem_build_flags.h:
core/box/tiny_header_box.h:
core/box/tiny_layout_box.h:
core/box/../tiny_region_id.h:

View File

@ -0,0 +1,46 @@
#!/bin/bash
# Box: PGO Profile Configuration (FAST minimal)
# Purpose: Define representative workloads for FAST minimal PGO collection.
# Contract:
# - Only deterministic workloads (fixed args/seeds).
# - Must complete quickly per workload (PGO box enforces timeout).
# - Keep baseline toolchain consistent (GCC + LTO; profile-generate/use handled by Makefile).
# Binaries to profile (must exist after `make pgo-fast-profile`)
PGO_BINARIES=(
"./bench_random_mixed_hakmem"
"./bench_tiny_hot_hakmem"
)
# Representative workloads (deterministic).
#
# Notes:
# - Keep these as shell strings: pgo_tiny_profile_box.sh runs them via `bash -lc`.
# - Prefer the same (iter, ws, seed) shape as the canonical Mixed 10-run, but shorter.
#
# Phase 68 Update: Diversify WS and seeds to reduce overfitting.
# - Mixed WS: Added 100, 256, 512, 1024 to existing 400 (5 patterns total).
# - Tiny hot: Added seed variants 60001, 60002 to 60000 (3 seeds total).
PGO_WORKLOADS=(
# Mixed: run via cleanenv to match benchmark presets (prevents PGO mismatch).
# Keep runs small; collector enforces per-workload timeout.
# Expanded WS range: 100, 256, 400, 512, 1024 (was: 128, 400, 800)
"HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE RUNS=2 ITERS=20000000 WS=100 BENCH_BIN=./bench_random_mixed_hakmem scripts/run_mixed_10_cleanenv.sh"
"HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE RUNS=2 ITERS=20000000 WS=256 BENCH_BIN=./bench_random_mixed_hakmem scripts/run_mixed_10_cleanenv.sh"
"HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE RUNS=2 ITERS=20000000 WS=400 BENCH_BIN=./bench_random_mixed_hakmem scripts/run_mixed_10_cleanenv.sh"
"HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE RUNS=2 ITERS=20000000 WS=512 BENCH_BIN=./bench_random_mixed_hakmem scripts/run_mixed_10_cleanenv.sh"
"HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE RUNS=2 ITERS=20000000 WS=1024 BENCH_BIN=./bench_random_mixed_hakmem scripts/run_mixed_10_cleanenv.sh"
# Tiny hot: C0-ish (16B) and C3-ish (64B) patterns with seed diversification.
# Extended seed set: 60000, 60001, 60002 (was: 60000 only)
"./bench_tiny_hot_hakmem 16 100 60000"
"./bench_tiny_hot_hakmem 16 100 60001"
"./bench_tiny_hot_hakmem 16 100 60002"
"./bench_tiny_hot_hakmem 64 100 60000"
"./bench_tiny_hot_hakmem 64 100 60001"
"./bench_tiny_hot_hakmem 64 100 60002"
)
# Configuration summary
PGO_WORKLOAD_COUNT=${#PGO_WORKLOADS[@]}
PGO_BINARY_COUNT=${#PGO_BINARIES[@]}

View File

@ -10,7 +10,8 @@
set -e # Fail fast on errors
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
source "${SCRIPT_DIR}/pgo_tiny_profile_config.sh"
PGO_CONFIG_BASENAME="${PGO_CONFIG:-pgo_tiny_profile_config.sh}"
source "${SCRIPT_DIR}/${PGO_CONFIG_BASENAME}"
echo "========================================="
echo "Box: PGO Profile Collection (Tiny Front)"
@ -18,6 +19,7 @@ echo "========================================="
echo "Date: $(date)"
echo "Workloads: $PGO_WORKLOAD_COUNT"
echo "Binaries: $PGO_BINARY_COUNT"
echo "Config: $PGO_CONFIG_BASENAME"
echo ""
# Validate binaries exist and are executable
@ -58,7 +60,7 @@ for workload in "${PGO_WORKLOADS[@]}"; do
echo "-------------------------------------------"
# Execute with timeout (30s per workload)
if timeout 30 $workload; then
if timeout 30 bash -lc "$workload"; then
echo " ✓ Success"
else
EXIT_CODE=$?