Files
hakmem/docs/archive/claude.md
Moe Charm (CI) 52386401b3 Debug Counters Implementation - Clean History
Major Features:
- Debug counter infrastructure for Refill Stage tracking
- Free Pipeline counters (ss_local, ss_remote, tls_sll)
- Diagnostic counters for early return analysis
- Unified larson.sh benchmark runner with profiles
- Phase 6-3 regression analysis documentation

Bug Fixes:
- Fix SuperSlab disabled by default (HAKMEM_TINY_USE_SUPERSLAB)
- Fix profile variable naming consistency
- Add .gitignore patterns for large files

Performance:
- Phase 6-3: 4.79 M ops/s (has OOM risk)
- With SuperSlab: 3.13 M ops/s (+19% improvement)

This is a clean repository without large log files.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-05 12:31:14 +09:00

6.6 KiB
Raw Blame History

hakmem - Claude向けクイックリファレンス

📚 主要ドキュメント

基本

仕様・設定

ベンチマーク

実装状況

🚀 クイックスタート

ビルド

# 通常ビルド
make shared

# デバッグビルドタイミング計測ON
make debug

# ベンチマーク用profiler組み込み
make bench

基本的な使い方

1. プリセットモードで実行

# BALANCED モード(推奨)
HAKMEM_MODE=balanced LD_PRELOAD=./libhakmem.so ./your_app

# MINIMAL モードベースライン、最適化OFF
HAKMEM_MODE=minimal LD_PRELOAD=./libhakmem.so ./your_app

# LEARNING モード(自動学習)
HAKMEM_MODE=learning LD_PRELOAD=./libhakmem.so ./your_app

2. タイミング計測

# 全カテゴリの実行時間を計測終了時にstderrへ出力
HAKMEM_TIMING=1 LD_PRELOAD=./libhakmem.so ./your_app

3. Profilerでホットパス分析

# サンプリングprofiler有効化1/4096サンプリング
HAKMEM_PROF=1 LD_PRELOAD=./libhakmem.so ./your_app

# サンプリング率変更1/256に
HAKMEM_PROF=1 HAKMEM_PROF_SAMPLE=8 LD_PRELOAD=./libhakmem.so ./your_app

4. 学習機能(自動キャッシュチューニング)

# 1秒ごとにヒット率を見てキャッシュ容量を自動調整
HAKMEM_LEARN=1 LD_PRELOAD=./libhakmem.so ./your_app

# パラメータ調整
HAKMEM_LEARN=1 \
  HAKMEM_TARGET_HIT_MID=0.70 \
  HAKMEM_LEARN_WINDOW_MS=500 \
  LD_PRELOAD=./libhakmem.so ./your_app

🔍 トレーシング・デバッグ機能

Debug Timing詳細なタイミング計測

  • 有効化: HAKMEM_TIMING=1
  • 測定項目: lock取得、リフィル、ドレイン、TLS操作など
  • 出力: プログラム終了時にstderrへサイクル単位で統計出力

Sampling Profiler低オーバーヘッド

  • 有効化: HAKMEM_PROF=1
  • サンプリング率: HAKMEM_PROF_SAMPLE=N1/2^N、デフォルト12=1/4096
  • カテゴリ: tiny_alloc, ace_alloc, pool_refill, l25_refillなど

Learning自動最適化

  • 有効化: HAKMEM_LEARN=1
  • 動作: バックグラウンドスレッドで1秒ごとにヒット率を計測してCAP調整
  • パラメータ: 目標ヒット率、ステップ、予算制約など

⚙️ よく使う環境変数

モード設定

  • HAKMEM_MODE=minimal|fast|balanced|learning|research

キャッシュ容量(手動設定)

  • HAKMEM_CAP_MID=10,20,40,80,160 - Mid Pool (2/4/8/16/32KB)
  • HAKMEM_CAP_LARGE=2,4,8,16,32 - Large Pool (64K/128K/256K/512K/1MB)

丸め許容W_MAX

  • HAKMEM_WMAX_MID=1.4 - Midでの丸め許容率
  • HAKMEM_WMAX_LARGE=1.4 - Largeでの丸め許容率

安全性

  • HAKMEM_SAFE_FREE=1 - free()時にmincore()チェック(重い)

その他

  • HAKMEM_THP=auto|on|off - Transparent Huge Pages
  • HAKMEM_SHARD_MIX=1 - シャード分散強化

詳細は docs/specs/ENV_VARS.md を参照。

🧪 ベンチマーク

Larsonマルチスレッド負荷テスト

# 基本実行10秒、1/4スレッド
scripts/run_larson.sh -d 10 -t 1,4

# burst プリセット(同時保持が多い、厳しめ)
scripts/run_larson.sh -d 10 -t 1,4 -p burst

# loop プリセット(局所性が高い、甘め)
scripts/run_larson.sh -d 10 -t 1,4 -p loop

mimalloc-bench

cd mimalloc-bench
./bench.sh

📊 アーキテクチャ

3層構造

  • L0: Tiny Pool (≤1KB) - TLS Magazine + Slab
  • L1: ACE層 (1KB2MB)
    • Mid Pool (232KB) - TLSリング+LIFO
    • Large Pool (64KB1MB) - bump-run方式
  • L2: BigCache/mmap (≥2MB) - LRU + カーネルmmap

主要コンポーネント

  • hakmem.c - メインアロケータ
  • hakmem_ace.c - L1統合層Mid/Large routing
  • hakmem_pool.c - Mid Pool232KB
  • hakmem_l25_pool.c - Large Pool64KB1MB
  • hakmem_tiny.c - Tiny Pool≤1KB
  • hakmem_policy.c - FrozenPolicyRCUスナップショット
  • hakmem_learner.c - 自動学習バックグラウンドCAP調整
  • hakmem_debug.c - Debug Timing
  • hakmem_prof.c - Sampling Profiler

🎯 現在の課題2025-10-24更新

パフォーマンスギャップ

  • hakmem vs mimalloc: 1Tで-41%、4Tで-48%の差
  • 現状: 4.0M ops/sec (hakmem) vs 6.8M ops/sec (mimalloc)

特定された問題点(調査完了)

1. LD_PRELOADラッパーコンテキストの罠

  • 原因: hak_in_wrapper()がTiny/Mid Poolをスキップ
  • 影響: 小サイズ割り当て10-1000バイトが全てlibc mallocにフォールバック
  • タイミング: fallback_malloc = 300 cycles (24.3%)

2. WRAP有効化の逆効果 ⚠️

HAKMEM_WRAP_TINY=1 HAKMEM_WRAP_L2=1を試した結果:

  • パフォーマンス: 4.0M → 3.2M ops/sec (-20%悪化)
  • 原因:
    • pool_get: 63 → 365 cycles (5.8倍!)
    • pool_alloc_tls_page: 10,915 cycles (重すぎる)
    • tiny_alloc: 131回のみ5002回allocの2.6%しか使われていない)

3. 詳細な問題点

  1. pool_alloc_tls_pageが激重: 10,915 cycles
  2. Tiny Poolがほぼ未使用: larsonは10-110バイトなのに2.6%のみ
  3. Mid Poolへの偏り: pool_get が7,290回allocの1.5倍)

次の調査項目

  • サイズ分布の確認larsonの実際の割り当てサイズ
  • pool_alloc_tls_pageの最適化なぜ重いか
  • Tiny Pool判定ロジックの見直しなぜ使われないか
  • コード構造の見直しultrathink調査予定

Phase 6.15以降、マルチスレッド性能mimalloc比較に注力中:

  • TLS最適化によりスケーラビリティ向上
  • freeの処理最適化
  • より詳細なタイミング計測

詳細は最新のPHASE_*.mdドキュメントを参照。