Files
hakmem/docs/archive/claude.md

193 lines
6.6 KiB
Markdown
Raw Normal View History

# hakmem - Claude向けクイックリファレンス
## 📚 主要ドキュメント
### 基本
- [README.md](README.md) - プロジェクト全体の概要
- [docs/INDEX.md](docs/INDEX.md) - ドキュメント索引
### 仕様・設定
- [docs/specs/CURRENT_SPEC.md](docs/specs/CURRENT_SPEC.md) - 現在の実装仕様SACS-3、学習、環境変数
- [docs/specs/ENV_VARS.md](docs/specs/ENV_VARS.md) - **環境変数の一覧と意味30以上のオプション**
### ベンチマーク
- [docs/benchmarks/README.md](docs/benchmarks/README.md) - 計測の流れ、保存場所、命名規則
- [docs/benchmarks/2025-10-22_SWEEP_NOTES.md](docs/benchmarks/2025-10-22_SWEEP_NOTES.md) - 最新の計測要約
### 実装状況
- [docs/status/IMPLEMENTATION_STATUS_2025_10_22.md](docs/status/IMPLEMENTATION_STATUS_2025_10_22.md) - 実装状況
- [PHASE_6.15_SUMMARY.md](PHASE_6.15_SUMMARY.md) - Phase 6.15の要約TLS最適化
## 🚀 クイックスタート
### ビルド
```bash
# 通常ビルド
make shared
# デバッグビルドタイミング計測ON
make debug
# ベンチマーク用profiler組み込み
make bench
```
### 基本的な使い方
#### 1. プリセットモードで実行
```bash
# 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. タイミング計測
```bash
# 全カテゴリの実行時間を計測終了時にstderrへ出力
HAKMEM_TIMING=1 LD_PRELOAD=./libhakmem.so ./your_app
```
#### 3. Profilerでホットパス分析
```bash
# サンプリング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. 学習機能(自動キャッシュチューニング)
```bash
# 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=N`1/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](docs/specs/ENV_VARS.md) を参照。
## 🧪 ベンチマーク
### Larsonマルチスレッド負荷テスト
```bash
# 基本実行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
```bash
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ドキュメントを参照。