## Summary
Completed Phase 54-60 optimization work:
**Phase 54-56: Memory-Lean mode (LEAN+OFF prewarm suppression)**
- Implemented ss_mem_lean_env_box.h with ENV gates
- Balanced mode (LEAN+OFF) promoted as production default
- Result: +1.2% throughput, better stability, zero syscall overhead
- Added to bench_profile.h: MIXED_TINYV3_C7_BALANCED preset
**Phase 57: 60-min soak finalization**
- Balanced mode: 60-min soak, RSS drift 0%, CV 5.38%
- Speed-first mode: 60-min soak, RSS drift 0%, CV 1.58%
- Syscall budget: 1.25e-7/op (800× under target)
- Status: PRODUCTION-READY
**Phase 59: 50% recovery baseline rebase**
- hakmem FAST (Balanced): 59.184M ops/s, CV 1.31%
- mimalloc: 120.466M ops/s, CV 3.50%
- Ratio: 49.13% (M1 ACHIEVED within statistical noise)
- Superior stability: 2.68× better CV than mimalloc
**Phase 60: Alloc pass-down SSOT (NO-GO)**
- Implemented alloc_passdown_ssot_env_box.h
- Modified malloc_tiny_fast.h for SSOT pattern
- Result: -0.46% (NO-GO)
- Key lesson: SSOT not applicable where early-exit already optimized
## Key Metrics
- Performance: 49.13% of mimalloc (M1 effectively achieved)
- Stability: CV 1.31% (superior to mimalloc 3.50%)
- Syscall budget: 1.25e-7/op (excellent)
- RSS: 33MB stable, 0% drift over 60 minutes
## Files Added/Modified
New boxes:
- core/box/ss_mem_lean_env_box.h
- core/box/ss_release_policy_box.{h,c}
- core/box/alloc_passdown_ssot_env_box.h
Scripts:
- scripts/soak_mixed_single_process.sh
- scripts/analyze_epoch_tail_csv.py
- scripts/soak_mixed_rss.sh
- scripts/calculate_percentiles.py
- scripts/analyze_soak.py
Documentation: Phase 40-60 analysis documents
## Design Decisions
1. Profile separation (core/bench_profile.h):
- MIXED_TINYV3_C7_SAFE: Speed-first (no LEAN)
- MIXED_TINYV3_C7_BALANCED: Balanced mode (LEAN+OFF)
2. Box Theory compliance:
- All ENV gates reversible (HAKMEM_SS_MEM_LEAN, HAKMEM_ALLOC_PASSDOWN_SSOT)
- Single conversion points maintained
- No physical deletions (compile-out only)
3. Lessons learned:
- SSOT effective only where redundancy exists (Phase 60 showed limits)
- Branch prediction extremely effective (~0 cycles for well-predicted branches)
- Early-exit pattern valuable even when seemingly redundant
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
3.1 KiB
3.1 KiB
Phase 44 — Cache-miss / writeback profiling(次の芯を “測ってから” 決める)
Phase 42 の結論: gate は打ち止め(Top50 圏外)。
Phase 43 の結論: header write を branch で削るのは負け筋(straight-line が強い)。
次は “どこで stall しているか” を定量化してから攻める。
目的
FAST build(make perf_fast)の Mixed で、
tiny_region_id_write_header(alloc)unified_cache_push/tiny_c7_ultra_free(free)
が L1/L2/LLC/DTLB/ストアバッファのどれで詰まっているかを特定する。
この Phase は 計測のみ(コード変更ゼロ)でOK。
Step 0: 固定条件
- バイナリ:
./bench_random_mixed_hakmem_minimal - 条件:
ITERS=200000000 WS=400(短すぎるとノイズが増える) - clean env:
scripts/run_mixed_10_cleanenv.shは A/B 用。ここでは単発 perf 用に直接叩いてよい。
Step 1: perf stat(メモリ系カウンタ)
例(環境によってイベント名が違うので、まずは一般的なものを試す):
perf stat -e \
cycles,instructions,branches,branch-misses, \
cache-references,cache-misses, \
L1-dcache-loads,L1-dcache-load-misses, \
LLC-loads,LLC-load-misses, \
dTLB-loads,dTLB-load-misses, \
iTLB-loads,iTLB-load-misses \
-- ./bench_random_mixed_hakmem_minimal 200000000 400 1
記録するもの(最低限):
- IPC(instructions / cycles)
- cache-misses / cache-references
- L1-dcache-load-misses
- LLC-load-misses
- dTLB-load-misses / iTLB-load-misses
Step 2: perf record(どの関数が miss を起こしているか)
perf record -F 99 -g -- ./bench_random_mixed_hakmem_minimal 200000000 400 1
perf report --no-children | head -120
可能なら(環境が許す場合):
perf record -e cache-misses -F 99 -g -- ./bench_random_mixed_hakmem_minimal 200000000 400 1
perf report --no-children | head -120
目的:
- “時間が掛かっている関数” と “cache-miss を出している関数” が一致しているか確認。
Step 3: 次の Phase を決める(分岐)
Case A: tiny_region_id_write_header が store-bound
兆候:
- cache-miss は少ないのに IPC が低い
perf recordで header write が支配的
次:
- Phase 45: “branch を増やさずに store を減らす”案だけ検討(例: まとめ書き、別境界への移動)
Case B: unified_cache_push / tiny_c7_ultra_free が miss-bound
兆候:
- L1/LLC/DTLB miss が支配的
- cache-misses のホットが free 側に寄る
次:
- Phase 45: prefetch / データ配置(struct packing / align)を検討
Case C: iTLB/i-cache が支配的
兆候:
- iTLB-load-misses が相対的に多い
次:
- “削除”ではなく hot text の clustering(ただし Phase 18 v1 の section-splitting は禁止)
ログ
docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.mdを作り、- perf stat(数値)
- perf report Top(時間と miss の Top)
- 判定(Case A/B/C) を書いて次の Phase を確定する。