hakmem/docs/analysis/PHASE40_GATE_CONSTANTIZATION_RESULTS.md

Phase 40: BENCH_MINIMAL Gate Constantization Results

Date: 2025-12-16 Verdict: NO-GO (-2.47%) Status: Reverted

Executive Summary

Phase 40 attempted to constantize tiny_header_mode() in BENCH_MINIMAL mode, following the proven success pattern from Phase 39 (+1.98%). However, A/B testing revealed an unexpected -2.47% regression, leading to a NO-GO verdict and full revert of changes.

Hypothesis

Building on Phase 39's success with gate function constantization (+1.98%), Phase 40 targeted tiny_header_mode() as the next highest-impact candidate based on FAST v3 perf profiling:

• Location: core/tiny_region_id.h:180-211
• Pattern: Lazy-init with static int g_header_mode = -1 + getenv()
• Call site: Hot path in tiny_region_id_write_header() (4.56% self-time)
• Expected gain: +0.3~0.8% (similar to Phase 39 targets)

Implementation

Change: tiny_header_mode() Constantization

File: /mnt/workdisk/public_share/hakmem/core/tiny_region_id.h

static inline int tiny_header_mode(void)
{
#if HAKMEM_BENCH_MINIMAL
  // Phase 40: BENCH_MINIMAL → 固定 FULL (header write enabled)
  // Rationale: Eliminates lazy-init gate check in alloc hot path
  // Expected: +0.3~0.8% (TBD after A/B test)
  return TINY_HEADER_MODE_FULL;
#else
  static int g_header_mode = -1;
  if (__builtin_expect(g_header_mode == -1, 0))
  {
    const char* e = getenv("HAKMEM_TINY_HEADER_MODE");
    // ... [original lazy-init logic] ...
  }
  return g_header_mode;
#endif
}

Rationale:

• In BENCH_MINIMAL mode, always return constant TINY_HEADER_MODE_FULL (0)
• Eliminates branch + lazy-init overhead in hot path
• Matches default benchmark behavior (FULL mode)

A/B Test Results

Test Configuration

• Benchmark: bench_random_mixed_hakmem_minimal
• Test harness: scripts/run_mixed_10_cleanenv.sh
• Parameters: ITERS=20000000 WS=400
• Method: Git stash A/B (baseline vs treatment)

Baseline (FAST v3 without Phase 40)

Run 1/10:  56789069 ops/s
Run 2/10:  56274671 ops/s
Run 3/10:  56513942 ops/s
Run 4/10:  56133590 ops/s
Run 5/10:  56634961 ops/s
Run 6/10:  54943677 ops/s
Run 7/10:  57088883 ops/s
Run 8/10:  56337157 ops/s
Run 9/10:  55930637 ops/s
Run 10/10: 56590285 ops/s

Mean: 56,323,700 ops/s

Treatment (FAST v4 with Phase 40)

Run 1/10:  54355307 ops/s
Run 2/10:  56936372 ops/s
Run 3/10:  54694629 ops/s
Run 4/10:  54504756 ops/s
Run 5/10:  55137468 ops/s
Run 6/10:  52434980 ops/s
Run 7/10:  52438841 ops/s
Run 8/10:  54966798 ops/s
Run 9/10:  56834583 ops/s
Run 10/10: 57034821 ops/s

Mean: 54,933,856 ops/s

Delta Analysis

Baseline:  56,323,700 ops/s
Treatment: 54,933,856 ops/s
Delta:     -1,389,844 ops/s (-2.47%)

Verdict: NO-GO (threshold: -0.5% or worse)

Root Cause Analysis

Why did Phase 40 fail when Phase 39 succeeded?

1. Code Layout Effects (Phase 22-2 Precedent)

The regression is likely caused by compiler code layout changes rather than the logic change itself:

• LTO reordering: Adding #if HAKMEM_BENCH_MINIMAL block changes function layout
• Instruction cache: Small layout changes can significantly impact icache hit rates
• Branch prediction: Modified code placement affects CPU branch predictor state

Evidence from Phase 22-2:

• Physical code deletion caused -5.16% regression despite removing "dead" code
• Reason: Layout changes disrupted hot path alignment and icache behavior
• Lesson: "Deleting to speed up" is unreliable with LTO

2. Hot Path Already Optimized

Unlike Phase 39 targets, tiny_header_mode() may already be effectively optimized:

Phase 21 Hot/Cold Split:

// Phase 21: Hot/cold split for FULL mode (ENV-gated)
if (tiny_header_hotfull_enabled()) {
    int header_mode = tiny_header_mode();
    if (__builtin_expect(header_mode == TINY_HEADER_MODE_FULL, 1)) {
        // Hot path: straight-line code (no existing_header read, no guard call)
        uint8_t desired_header = (uint8_t)(HEADER_MAGIC | (class_idx & HEADER_CLASS_MASK));
        *header_ptr = desired_header;
        // ... fast path ...
        return user;
    }
    // Cold path
    return tiny_region_id_write_header_slow(base, class_idx, header_ptr);
}

Key observation:

• The hot path at line 349 calls tiny_header_mode() and checks for TINY_HEADER_MODE_FULL
• This call is already once per allocation and highly predictable (always FULL in benchmarks)
• The __builtin_expect hint ensures the FULL branch is predicted correctly
• Compiler may already be inlining and optimizing away the branch

Phase 39 difference:

• Phase 39 targeted gates called on every path without existing optimization
• Those gates had no Phase 21-style hot/cold split
• Constantization provided genuine branch elimination

3. Snapshot Caching Interaction

The TinyFrontV3Snapshot mechanism caches tiny_header_mode() value:

// core/box/tiny_front_v3_env_box.h:13
uint8_t header_mode;  // tiny_header_mode() の値をキャッシュ

// core/hakmem_tiny.c:83
.header_mode = (uint8_t)tiny_header_mode(),

If most allocations use the cached value from snapshot rather than calling tiny_header_mode() directly, constantizing the function provides minimal benefit while still incurring layout disruption costs.

Lessons Learned

1. Not All Gates Are Created Equal

Phase 39 success criteria (gates that benefit from constantization):

• Called on every hot path without optimization
• No existing hot/cold split or branch prediction hints
• No snapshot caching mechanism
• Examples: g_alloc_front_gate_enabled, g_alloc_prewarm_enabled

Phase 40 failure indicators (gates that DON'T benefit):

• Already optimized with hot/cold split (Phase 21)
• Protected by __builtin_expect branch hints
• Cached in snapshot structures
• Infrequently called (once per allocation vs once per operation)

2. Code Layout Tax Exceeds Logic Benefit

Even when logic change is sound, layout disruption can dominate:

Logic benefit:    ~0.5%   (eliminate branch + lazy-init)
Layout tax:       ~3.0%   (icache/alignment disruption)
Net result:       -2.47%  (NO-GO)

3. Perf Profile Can Be Misleading

tiny_region_id_write_header() showed 4.56% self-time in perf, but:

• Most of that time is actual header write work, not gate overhead
• The tiny_header_mode() call is already optimized by compiler
• Profiler cannot distinguish between "work" time and "gate" time

Better heuristic: Only constantize gates that:

1. Appear in perf with high instruction count (not just time)
2. Have visible getenv() calls in assembly
3. Lack existing optimization (no Phase 21-style split)

Recommendation

REVERT Phase 40 changes completely.

Alternative Approaches (Future Research)

If we still want to optimize tiny_header_mode():

1. Wait for Phase 21 BENCH_MINIMAL adoption - Constantize tiny_header_hotfull_enabled() instead

   • Rationale: Eliminates entire hot/cold branch, not just mode check
   • Expected: +0.5~1% (higher leverage point)

2. Profile-guided optimization - Let compiler optimize based on runtime profile

   • Rationale: Avoid manual layout disruption
   • Method: gcc -fprofile-generate → run benchmark → gcc -fprofile-use

3. Assembly inspection first - Check if gate is actually compiled as branch

   • Method: objdump -d bench_random_mixed_hakmem_minimal | grep -A20 tiny_header_mode
   • If already optimized away → skip constantization

Files Modified (REVERTED)

• /mnt/workdisk/public_share/hakmem/core/tiny_region_id.h (lines 180-218)

Next Steps

1. Revert all Phase 40 changes via git restore
2. Update CURRENT_TASK.md - Mark Phase 40 as NO-GO with analysis
3. Document in scorecard - Add Phase 40 as research failure for future reference
4. Re-evaluate gate candidates - Use stricter criteria (see Lessons Learned #1)

Appendix: Raw Test Data

Baseline runs

56789069, 56274671, 56513942, 56133590, 56634961,
54943677, 57088883, 56337157, 55930637, 56590285

Treatment runs

54355307, 56936372, 54694629, 54504756, 55137468,
52434980, 52438841, 54966798, 56834583, 57034821

Variance Analysis

Baseline:

• Std dev: ~586K ops/s (1.04% CV)
• Range: 2.14M ops/s (54.9M - 57.1M)

Treatment:

• Std dev: ~1.52M ops/s (2.77% CV)
• Range: 4.60M ops/s (52.4M - 57.0M)

Observation: Treatment shows 2.6x higher variance than baseline, suggesting layout instability.

---

Conclusion: Phase 40 is a clear NO-GO. Revert all changes and re-focus on gates without existing optimization.