Files
hakmem/docs/analysis/PHASE7_QUICK_BENCHMARK_RESULTS.md
Moe Charm (CI) a9ddb52ad4 ENV cleanup: Remove BG/HotMag vars & guard fprintf (Larson 52.3M ops/s)
Phase 1 完了:環境変数整理 + fprintf デバッグガード

ENV変数削除(BG/HotMag系):
- core/hakmem_tiny_init.inc: HotMag ENV 削除 (~131 lines)
- core/hakmem_tiny_bg_spill.c: BG spill ENV 削除
- core/tiny_refill.h: BG remote 固定値化
- core/hakmem_tiny_slow.inc: BG refs 削除

fprintf Debug Guards (#if !HAKMEM_BUILD_RELEASE):
- core/hakmem_shared_pool.c: Lock stats (~18 fprintf)
- core/page_arena.c: Init/Shutdown/Stats (~27 fprintf)
- core/hakmem.c: SIGSEGV init message

ドキュメント整理:
- 328 markdown files 削除(旧レポート・重複docs)

性能確認:
- Larson: 52.35M ops/s (前回52.8M、安定動作)
- ENV整理による機能影響なし
- Debug出力は一部残存(次phase で対応)

🤖 Generated with Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-26 14:45:26 +09:00

5.5 KiB

Phase 7 Quick Benchmark Results (2025-11-08)

Test Configuration

  • HAKMEM Build: HEADER_CLASSIDX=1 (Phase 7 enabled)
  • Benchmark: bench_random_mixed (100K operations each)
  • Test Date: 2025-11-08
  • Comparison: Phase 7 vs System malloc

Results Summary

Size HAKMEM (M ops/s) System (M ops/s) HAKMEM % Change from Phase 6
128B 21.0 66.9 31% +11% (was 20%)
256B 18.7 61.6 30% +10% (was 20%)
512B 21.0 54.8 38% +18% (was 20%)
1024B 20.6 64.7 32% +12% (was 20%)
2048B 19.3 55.6 35% +15% (was 20%)
4096B 15.6 36.1 43% +23% (was 20%)

Larson 1T: 2.68M ops/s (vs 631K in Phase 6-2.3 = +325%)


Analysis

Phase 7 Achievements

  1. Significant Improvement over Phase 6:

    • Tiny (≤128B): -60% → -69% improvement (20% → 31% of System)
    • Mid sizes: +18-23% improvement
    • Larson: +325% improvement
  2. Larger Sizes Perform Better:

    • 128B: 31% of System
    • 4KB: 43% of System
    • Trend: Better relative performance on larger allocations
  3. Stability:

    • No crashes across all sizes
    • Consistent performance (18-21M ops/s range)

Gap to Target

Target: 70-140% of System malloc (40-80M ops/s) Current: 30-43% of System malloc (15-21M ops/s)

Gap:

  • Best case (4KB): 43% vs 70% target = -27 percentage points
  • Worst case (128B): 31% vs 70% target = -39 percentage points

Why Not At Target?

Phase 7 removed SuperSlab lookup (100+ cycles) but:

  1. System malloc tcache is EXTREMELY fast (10-15 cycles)
  2. HAKMEM still has overhead:
    • TLS cache access
    • Refill logic
    • Magazine layer (if enabled)
    • Header validation

Bottleneck Analysis

System malloc Advantages (10-15 cycles)

// System tcache fast path (~10 cycles)
void* ptr = tcache_bins[idx].entries[tcache_bins[idx].counts--];
return ptr;

HAKMEM Phase 7 (estimated 30-50 cycles)

// 1. Header read + validation (~5 cycles)
uint8_t header = *((uint8_t*)ptr - 1);
if ((header & 0xF0) != 0xa0) return 0;
int cls = header & 0x0F;

// 2. TLS cache access (~10-15 cycles)
void* p = g_tls_sll_head[cls];
g_tls_sll_head[cls] = *(void**)p;
g_tls_sll_count[cls]++;

// 3. Refill logic (if cache empty) (~20-30 cycles)
if (!p) {
    tiny_alloc_fast_refill(cls);  // Batch refill from SuperSlab
}

Estimated overhead vs System: 30-50 cycles vs 10-15 cycles = 2-3x slower


Option 1: Accept Current Performance

Rationale:

  • Phase 7 achieved +325% on Larson, +11-23% on random_mixed
  • Mid-Large already dominates (+171% in Phase 6)
  • Total improvement is significant

Action: Move to Phase 7-2 (Production Integration)

Target: Reduce overhead from 30-50 cycles to 15-25 cycles

Potential Optimizations:

  1. Eliminate header validation in hot path (save 3-5 cycles)

    • Only validate on fallback
    • Assume headers are always correct
  2. Inline TLS cache access (save 5-10 cycles)

    • Remove function call overhead
    • Direct assembly for critical path
  3. Simplify refill logic (save 5-10 cycles)

    • Pre-warm TLS cache on init
    • Reduce branch mispredictions

Expected Gain: 15-25 cycles → 40-55% of System (vs current 30-43%)

Option 3: Ultra-Aggressive Fast Path

Idea: Match System tcache exactly

// Remove ALL validation, match System's simplicity
#define HAK_ALLOC_FAST(cls) ({ \
    void* p = g_tls_sll_head[cls]; \
    if (p) g_tls_sll_head[cls] = *(void**)p; \
    p; \
})

Expected: 60-80% of System (best case) Risk: Safety reduction, may break edge cases


Recommendation: Option 2

Why:

  • Phase 7 foundation is solid (+325% Larson, stable)
  • Gap to target (70%) is achievable with targeted optimization
  • Option 2 balances performance + safety
  • Mid-Large dominance (+171%) already gives us competitive edge

Timeline:

  • Optimization: 3-5 days
  • Testing: 1-2 days
  • Total: 1 week to reach 40-55% of System

Then: Move to Phase 7-2 Production Integration with proven performance


Detailed Results

HAKMEM (Phase 7-1.3, HEADER_CLASSIDX=1)

Random Mixed 128B:  21.04M ops/s
Random Mixed 256B:  18.69M ops/s
Random Mixed 512B:  21.01M ops/s
Random Mixed 1024B: 20.65M ops/s
Random Mixed 2048B: 19.25M ops/s
Random Mixed 4096B: 15.63M ops/s
Larson 1T:          2.68M ops/s

System malloc (glibc tcache)

Random Mixed 128B:  66.87M ops/s
Random Mixed 256B:  61.63M ops/s
Random Mixed 512B:  54.76M ops/s
Random Mixed 1024B: 64.66M ops/s
Random Mixed 2048B: 55.63M ops/s
Random Mixed 4096B: 36.10M ops/s

Percentage Comparison

128B:  31.4% of System
256B:  30.3% of System
512B:  38.4% of System
1024B: 31.9% of System
2048B: 34.6% of System
4096B: 43.3% of System

Conclusion

Phase 7-1.3 Status: Successful Foundation

  • Stable, crash-free across all sizes
  • +325% improvement on Larson vs Phase 6
  • +11-23% improvement on random_mixed vs Phase 6
  • Header-based free path working correctly

Path Forward: Option 2 - Further Tiny Optimization

  • Target: 40-55% of System (vs current 30-43%)
  • Timeline: 1 week
  • Then: Phase 7-2 Production Integration

Overall Project Status: On track to beat mimalloc/System with Mid-Large dominance + improved Tiny performance 🎯