hakmem/docs/analysis/PHASE62A_C7_ULTRA_DEPCHAIN_OPT_RESULTS.md

Phase 62A: C7 ULTRA Alloc Dependency Chain Trim - Results

Date: 2025-12-17 Status: NEUTRAL (-0.71%, research box) Baseline: 48.34% of mimalloc (Phase 59b Speed-first)

---

Executive Summary

Phase 62A attempted to optimize tiny_c7_ultra_alloc() hot path by eliminating per-call tiny_front_v3_c7_ultra_header_light_enabled() checks and using TLS headers_initialized flag instead. The optimization resulted in -0.71% regression (NEUTRAL), indicating the approach does not yield the expected +1-3% gain.

Conclusion: Research box (default OFF, HAKMEM_C7_ULTRA_ALLOC_DEPCHAIN_OPT=0)

---

A/B Test Results (Mixed benchmark, 10-run)

Baseline (HAKMEM_C7_ULTRA_ALLOC_DEPCHAIN_OPT=0)

Runs (M ops/s):

59.553, 59.906, 60.134, 59.533, 56.265, 59.368, 60.045, 58.487, 60.141, 59.569

Statistics:

• Mean: 59.300 M ops/s
• Median: 59.561 M ops/s
• StdDev: 1.173 M ops/s
• CV: 1.98%

---

Treatment (HAKMEM_C7_ULTRA_ALLOC_DEPCHAIN_OPT=1)

Runs (M ops/s):

56.352, 58.924, 58.946, 60.109, 58.630, 58.689, 59.609, 58.160, 59.939, 59.430

Statistics:

• Mean: 58.879 M ops/s
• Median: 58.935 M ops/s
• StdDev: 1.079 M ops/s
• CV: 1.83%

---

Comparison

Metric	Baseline	Treatment	Delta
Mean	59.300	58.879	-0.71%
Median	59.561	58.935	-1.05%
StdDev	1.173	1.079	-8.0%
CV	1.98%	1.83%	-0.15pp

Verdict: NEUTRAL (-0.71% within ±1.0% threshold, but negative)

---

Implementation Details

Optimization Strategy

Original Code (tiny_c7_ultra_alloc hot path):

void* tiny_c7_ultra_alloc(size_t size) {
    tiny_c7_ultra_tls_t* tls = &g_tiny_c7_ultra_tls;
    const bool header_light = tiny_front_v3_c7_ultra_header_light_enabled();  // Per-call check

    uint16_t n = tls->count;
    if (n > 0) {
        void* base = tls->freelist[n - 1];
        tls->count = n - 1;

        if (header_light) {  // Per-call branch
            return (uint8_t*)base + 1;
        }
        return tiny_region_id_write_header(base, 7);
    }
    // ... refill and retry
}

Optimized Code (Phase 62A):

void* tiny_c7_ultra_alloc(size_t size) {
    tiny_c7_ultra_tls_t* tls = &g_tiny_c7_ultra_tls;
    // No per-call header_light check - use TLS flag instead

    uint16_t n = tls->count;
    if (n > 0) {
        void* base = tls->freelist[n - 1];
        tls->count = n - 1;

        if (tls->headers_initialized) {  // TLS flag set during refill
            return (uint8_t*)base + 1;
        }
        return tiny_region_id_write_header(base, 7);
    }
    // ... refill and retry
}

Intended Benefits:

1. Eliminate per-call tiny_front_v3_c7_ultra_header_light_enabled() function call
2. Replace with TLS field access (already in cache from count/freelist)
3. Reduce dependency chain length

---

Root Cause Analysis

Why No Improvement?

1. LTO Optimization Already In Place

   • In HAKMEM_BENCH_MINIMAL (-flto), tiny_front_v3_c7_ultra_header_light_enabled() is likely already inlined
   • Function call overhead may already be zero at compile time
   • Replacing with TLS field access doesn't improve latency (still L1 cache hit)

2. TLS Access Not Cheaper Than Expected

   • TLS field headers_initialized requires offset calculation + memory access
   • Function call overhead may actually be lower (register-based, already predicted)
   • Branch prediction on if (header_light) may be extremely accurate (99.99%+)

3. Layout Tax from Added Code

   • Phases 43, 46A, 47 precedent: adding code branches can cause I-cache/alignment disruption
   • Added if-dispatch at function entry (if (!c7_ultra_alloc_depchain_opt_enabled())) may affect code layout
   • Result: -0.71% regression consistent with pattern

4. Hot Path May Already Be Optimal

   • Phase 61 profiling showed tiny_c7_ultra_alloc at 5.18% stack %
   • But function-level optimization attempts (Phase 43/46A/47) all showed negative or marginal returns
   • Suggests hot path is already well-optimized by compiler

---

Lessons Learned

1. Function Call Overhead is Negligible in LTO Mode

With -flto and link-time optimization, function calls to simple getters are aggressively inlined. Removing them doesn't necessarily improve performance because:

• Compiler already determined optimal inlining
• Instruction fetch overhead may not be the bottleneck
• Replacing call with memory access can have similar latency

2. Layout Tax is Real and Persistent

This is the third time (Phase 43: -1.18%, Phase 46A: -0.68%, Phase 62A: -0.71%) that code addition/reorganization has resulted in regressions despite targeting hot functions. Pattern suggests:

• I-cache alignment matters more than instruction count
• Code layout disruptions can negate micro-optimization gains
• Box Theory "minimal code change" principle is well-justified

3. Per-Call Flags May Be Faster Than Per-TLS State

Counter-intuitive finding: accessing a per-call computed flag (via function inlining) may be faster than accessing TLS state, because:

• Function results are likely in registers (temporary)
• TLS access requires memory load + offset calculation
• Branch predictor handles pattern well

4. 5.18% Stack % ≠ Optimizable Hotspot

Phase 61 profiling showed tiny_c7_ultra_alloc at 5.18% combined stack overhead, but this is misleading because:

• Much of the time is in malloc/free wrappers and benchmark loop (not C7 ultra itself)
• Self time is likely 2-3% (actual function execution)
• Micro-optimizations on already-optimized paths yield diminishing returns

---

Decision

NEUTRAL (research box):

• Set default to HAKMEM_C7_ULTRA_ALLOC_DEPCHAIN_OPT=0 (OFF)
• Keep code with ENV gate for future reference
• Do not adopt as production default

Next Steps:

1. Phase 62B: Try secondary target (tiny_region_id_write_header reordering) - higher risk
2. Or pivot to Phase 62C: Accept 48.34% as performance ceiling, focus on production readiness
3. Or Phase 62D: Algorithmic redesign (batching, prefault strategy) - very high cost/risk

---

Box Theory Compliance

Principle	Status	Notes
Single Conversion Point	✅ Yes	tiny_c7_ultra_alloc() boundary
Clear Boundary	✅ Yes	Env gate HAKMEM_C7_ULTRA_ALLOC_DEPCHAIN_OPT
Reversible	✅ Yes	Can switch via ENV or compile flag
No Side Effects	✅ Yes	Pure optimization attempt, no new data structures
Performance	❌ No	-0.71% regression, NO-GO

Overall: Box Theory compliant but performance non-compliant.

---

Appendix: Raw Data

Baseline (10-run, M ops/s)

59.553099
59.906197
60.134051
59.533090
56.265139
59.367898
60.044922
58.486467
60.141028
59.568791

Treatment (10-run, M ops/s)

56.351851
58.923605
58.946089
60.109441
58.629557
58.689160
59.609485
58.160391
59.939368
59.430088

---

End of Phase 62A Report