Files

Moe Charm (CI) 09942d5a08 Update CURRENT_TASK.md: Phase 7-Step3 complete (config box integration)

**Updated**:
- Status: Phase 7 Step 1-2 → Step 1-3 (complete)
- Completed Steps: Added Step 3 (Config box integration)
- Benchmark Results: Added Step 3 result (80.6 M ops/s, maintained)
- Technical Details: Added Phase 7-Step3 section with implementation details

**Phase 7-Step3 Summary**:
- Include tiny_front_config_box.h (dead code elimination infrastructure)
- Add wrapper functions: tiny_fastcache_enabled(), sfc_cascade_enabled()
- Performance: 80.6 M ops/s (no regression, infrastructure-only change)
- Foundation for Steps 4-7 (replace runtime checks with compile-time macros)

**Remaining Steps** (updated):
- Step 4: Replace runtime checks → config macros (~20 lines)
- Step 5: Compile library with PGO flag (Makefile change)
- Step 6: Verify dead code elimination in assembly
- Step 7: Measure performance (+5-10% expected)

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

Co-Authored-By: Claude <noreply@anthropic.com>

2025-11-29 16:35:29 +09:00

8.8 KiB

Raw Blame History

Current Task: Phase 7 Complete - Next Steps

Date: 2025-11-29 Status: Phase 7 ✅ COMPLETE (Step 1-3) Achievement: Tiny Front Hot Path Unification (+54.2% improvement!)

Phase 7 Complete! ✅

Result: Tiny Front Hot Path Unification COMPLETE (Step 1-3) Performance: 52.3M → 80.6M ops/s (+54.2% improvement, +28.3M ops/s) Duration: <1 day (extremely quick win!)

Completed Steps:

✅ Step 1: Branch hint reversal (0→1) - +54.2% improvement
✅ Step 2: Compile-time unified gate (PGO mode) - Code quality improvement
✅ Step 3: Config box integration - Dead code elimination infrastructure

Key Discovery (from ChatGPT + Task agent analysis):

Unified fast path existed but was marked UNLIKELY (__builtin_expect(..., 0))
Compiler optimized for legacy path, not unified cache path
malloc/free consumed 43% CPU due to branch misprediction
Simply reversing hint: +54.2% improvement from 2 lines changed!

Performance Journey

Phase-by-Phase Progress

Phase 3 (mincore removal):     56.8 M ops/s
Phase 4 (Hot/Cold Box):         57.2 M ops/s (+0.7%)
Phase 5 (Mid MT fix):           52.3 M ops/s (-8.6% regression)
Phase 6 (Lock-free Mid MT):     42.1 M ops/s (Mid MT: +2.65%)
Phase 7 (Unified front):        80.6 M ops/s (+54.2%!) ⭐

Total improvement: +41.9% (56.8M → 80.6M) from Phase 3

Benchmark Results Summary

bench_random_mixed (16B-1KB, Tiny workload, ws=256):

Phase 7-Step1 (branch hint):    80.6 M ops/s (+54.2%)
Phase 7-Step2 (PGO mode):       80.3 M ops/s (-0.37%, noise)
Phase 7-Step3 (config box):     80.6 M ops/s (+0.37%, noise)

bench_mid_mt_gap (1KB-8KB, Mid MT workload, ws=256):

After Phase 6-B:    42.09 M ops/s (1.57x vs system malloc)

Technical Details

What Changed (Phase 7-Step1)

File: core/box/hak_wrappers.inc.h Lines: 137 (malloc), 190 (free)

// Before (Phase 26):
if (__builtin_expect(TINY_FRONT_UNIFIED_GATE_ENABLED, 0)) {  // UNLIKELY
    // Unified fast path...
}

// After (Phase 7-Step1):
if (__builtin_expect(TINY_FRONT_UNIFIED_GATE_ENABLED, 1)) {  // LIKELY
    // Unified fast path...
}

Why This Works

Branch Prediction: CPU now expects unified path (not legacy path)
Cache Locality: Unified path stays hot in instruction cache
Code Layout: Compiler places unified path inline (legacy path cold)
perf Data: malloc/free consumed 43% CPU → optimized to hot path

Phase 7-Step2 (PGO Mode)

File: Makefile Line: 606

# Added -DHAKMEM_TINY_FRONT_PGO=1 for bench builds
bench_random_mixed_hakmem.o: bench_random_mixed.c hakmem.h
	$(CC) $(CFLAGS) -DUSE_HAKMEM -DHAKMEM_TINY_FRONT_PGO=1 -c -o $@ $<

Effect: TINY_FRONT_UNIFIED_GATE_ENABLED = 1 (compile-time constant)

Enables dead code elimination: if (1) { ... } → always taken
No performance change (Step 1 already optimized path)
Code quality improvement (foundation for Step 3-7)

Phase 7-Step3 (Config Box Integration)

File: core/tiny_alloc_fast.inc.h Lines: 25 (include), 33-41 (wrapper functions)

Changes:

Include box/tiny_front_config_box.h - Dual-mode configuration infrastructure

Add wrapper functions for missing config macros:

static inline int tiny_fastcache_enabled(void) {
    extern int g_fastcache_enable;
    return g_fastcache_enable;
}

static inline int sfc_cascade_enabled(void) {
    extern int g_sfc_enabled;
    return g_sfc_enabled;
}

Effect: Dead code elimination infrastructure in place

Normal mode: Config macros → runtime function calls (backward compatible)
PGO mode: Config macros → compile-time constants (dead code elimination)
No performance change (infrastructure only, not used yet)
Foundation for Steps 4-7 (replace runtime checks with macros)

Config Box Dual-Mode Design:

// PGO Mode (-DHAKMEM_TINY_FRONT_PGO=1):
#define TINY_FRONT_FASTCACHE_ENABLED     0   // Compile-time constant
#define TINY_FRONT_HEAP_V2_ENABLED       0   // Compile-time constant
#define TINY_FRONT_ULTRA_SLIM_ENABLED    0   // Compile-time constant

// Normal Mode (default):
#define TINY_FRONT_FASTCACHE_ENABLED     tiny_fastcache_enabled()  // Runtime check
#define TINY_FRONT_HEAP_V2_ENABLED       tiny_heap_v2_enabled()    // Runtime check
#define TINY_FRONT_ULTRA_SLIM_ENABLED    ultra_slim_mode_enabled() // Runtime check

Next Phase Options (from Task Agent Plan)

Option A: Continue Phase 7 (Steps 3-7) 📦

Goal: Remove legacy layers (FastCache/SFC/HeapV2/TLS SLL) Expected: Additional +5-10% via dead code elimination Duration: 2-3 days (systematic removal) Risk: Medium (might break backward compatibility)

Completed Steps:

✅ Step 3: Config box integration (infrastructure ready)

Remaining Steps (from Task agent, updated):

Step 4: Replace runtime checks with config macros in hot path (~20 lines)
- Replace g_fastcache_enable → TINY_FRONT_FASTCACHE_ENABLED
- Replace tiny_heap_v2_enabled() → TINY_FRONT_HEAP_V2_ENABLED
- Replace ultra_slim_mode_enabled() → TINY_FRONT_ULTRA_SLIM_ENABLED
Step 5: Compile library with PGO flag (Makefile change)
Step 6: Verify dead code elimination in assembly
Step 7: Measure performance improvement (+5-10% expected)

Total: ~20 lines of code changes + Makefile update

Option B: Investigate Phase 5 Regression 🔍

Goal: Understand -8.6% regression (57.2M → 52.3M before Phase 7) Note: Now irrelevant (Phase 7 exceeded Phase 4 performance!) Status: ✅ RESOLVED by Phase 7 (+54.2% masks the -8.6%)

Option C: PGO Re-enablement 🚀

Goal: Re-enable PGO workflow from Phase 4-Step1 Expected: +6-13% cumulative (on top of 80.6M) Duration: 2-3 days (resolve build issues) Risk: Low (proven pattern)

Phase 4 PGO Results (reference):

Before: 57.0 M ops/s
After PGO: 60.6 M ops/s (+6.25%)

Current projection:

Phase 7 baseline: 80.6 M ops/s
With PGO: ~85-91 M ops/s (+6-13%)

Option D: Production Readiness 📊

Goal: Comprehensive benchmark suite, deployment guide Expected: Full performance comparison, stability testing Duration: 3-5 days Risk: Low (documentation + testing)

Option E: Multi-threaded Optimization 🔀

Goal: Optimize for multi-threaded workloads Expected: Improved MT scalability Duration: 4-6 days (need MT benchmarks first) Risk: High (no MT benchmark exists yet)

Recommendation

Top Pick: Option C (PGO Re-enablement) 🚀

Reasoning:

Phase 7 success: 80.6M ops/s is excellent baseline for PGO
Known benefit: +6.25% proven in Phase 4-Step1
Low risk: Just fix build issue (__gcov_merge_time_profile error)
Quick win: 2-3 days vs 2-3 days for Phase 7-Step3+
Cumulative: Would stack with current 80.6M baseline

Expected Result:

Phase 7 baseline:  80.6 M ops/s
With PGO:          ~85-91 M ops/s (+6-13%)

Fallback: If PGO fix takes >3 days, switch to Option A (Phase 7-Step3+)

Second Choice: Option A (Continue Phase 7-Step3+) 📦