Files
hakmem/docs/analysis/ANALYSIS_INDEX.md
Moe Charm (CI) 67fb15f35f Wrap debug fprintf in !HAKMEM_BUILD_RELEASE guards (Release build optimization)
## Changes

### 1. core/page_arena.c
- Removed init failure message (lines 25-27) - error is handled by returning early
- All other fprintf statements already wrapped in existing #if !HAKMEM_BUILD_RELEASE blocks

### 2. core/hakmem.c
- Wrapped SIGSEGV handler init message (line 72)
- CRITICAL: Kept SIGSEGV/SIGBUS/SIGABRT error messages (lines 62-64) - production needs crash logs

### 3. core/hakmem_shared_pool.c
- Wrapped all debug fprintf statements in #if !HAKMEM_BUILD_RELEASE:
  - Node pool exhaustion warning (line 252)
  - SP_META_CAPACITY_ERROR warning (line 421)
  - SP_FIX_GEOMETRY debug logging (line 745)
  - SP_ACQUIRE_STAGE0.5_EMPTY debug logging (line 865)
  - SP_ACQUIRE_STAGE0_L0 debug logging (line 803)
  - SP_ACQUIRE_STAGE1_LOCKFREE debug logging (line 922)
  - SP_ACQUIRE_STAGE2_LOCKFREE debug logging (line 996)
  - SP_ACQUIRE_STAGE3 debug logging (line 1116)
  - SP_SLOT_RELEASE debug logging (line 1245)
  - SP_SLOT_FREELIST_LOCKFREE debug logging (line 1305)
  - SP_SLOT_COMPLETELY_EMPTY debug logging (line 1316)
- Fixed lock_stats_init() for release builds (lines 60-65) - ensure g_lock_stats_enabled is initialized

## Performance Validation

Before: 51M ops/s (with debug fprintf overhead)
After:  49.1M ops/s (consistent performance, fprintf removed from hot paths)

## Build & Test

```bash
./build.sh larson_hakmem
./out/release/larson_hakmem 1 5 1 1000 100 10000 42
# Result: 49.1M ops/s
```

Generated with [Claude Code](https://claude.com/claude-code)

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

190 lines
5.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Random Mixed ボトルネック分析 - 完全レポート
**Analysis Date**: 2025-11-16
**Status**: Complete & Implementation Ready
**Priority**: 🔴 HIGHEST
**Expected Gain**: +13-29% (19.4M → 22-25M ops/s)
---
## ドキュメント一覧
### 1. **RANDOM_MIXED_SUMMARY.md** (推奨・最初に読む)
**用途**: エグゼクティブサマリー + 優先度付き推奨施策
**対象**: マネージャー、意思決定者
**内容**:
- Cycles 分布(表形式)
- FrontMetrics 現状
- Class別プロファイル
- 優先度付き候補A/B/C/D
- 最終推奨1-4優先度順
**読む時間**: 5分
**ファイル**: `/mnt/workdisk/public_share/hakmem/RANDOM_MIXED_SUMMARY.md`
---
### 2. **RANDOM_MIXED_BOTTLENECK_ANALYSIS.md** (詳細分析)
**用途**: 深掘りボトルネック分析、技術的根拠の確認
**対象**: エンジニア、最適化担当者
**内容**:
- Executive Summary
- Cycles 分布分析(詳細)
- FrontMetrics 状況確認
- Class別パフォーマンスプロファイル
- 次の一手候補の詳細分析A/B/C/D
- 優先順位付け結論
- 推奨施策(スクリプト付き)
- 長期ロードマップ
- 技術的根拠Fixed vs Mixed 比較、Refill Cost 見積もり)
**読む時間**: 15-20分
**ファイル**: `/mnt/workdisk/public_share/hakmem/RANDOM_MIXED_BOTTLENECK_ANALYSIS.md`
---
### 3. **RING_CACHE_ACTIVATION_GUIDE.md** (即実施ガイド)
**用途**: Ring Cache C4-C7 有効化の実施手順書
**対象**: 実装者
**内容**:
- 概要(なぜ Ring Cache か)
- Ring Cache アーキテクチャ解説
- 実装状況確認方法
- テスト実施手順Step 1-5
- Baseline 測定
- C2/C3 Ring テスト
- **C4-C7 Ring テスト(推奨)** ← これを実施すること
- Combined テスト
- ENV変数リファレンス
- トラブルシューティング
- 成功基準
- 次のステップ
**読む時間**: 10分
**実施時間**: 30分1時間
**ファイル**: `/mnt/workdisk/public_share/hakmem/RING_CACHE_ACTIVATION_GUIDE.md`
---
## クイックスタート
### 最速で結果を見たい場合5分
```bash
# 1. このガイドを読む
cat /mnt/workdisk/public_share/hakmem/RING_CACHE_ACTIVATION_GUIDE.md
# 2. Baseline 測定
./out/release/bench_random_mixed_hakmem 500000 256 42
# 3. Ring Cache C4-C7 有効化してテスト
export HAKMEM_TINY_HOT_RING_ENABLE=1
export HAKMEM_TINY_HOT_RING_C4=128
export HAKMEM_TINY_HOT_RING_C5=128
export HAKMEM_TINY_HOT_RING_C6=64
export HAKMEM_TINY_HOT_RING_C7=64
./out/release/bench_random_mixed_hakmem 500000 256 42
# 期待結果: 19.4M → 22-25M ops/s (+13-29%)
```
---
## ボトルネック要約
### 根本原因
Random Mixed が 23% で停滞している理由:
1. **Class切り替え多発**:
- Random Mixed は C2-C7 を均等に使用16B-1040B
- 毎iteration ごとに異なるクラスを処理
- TLS SLLper-classが複数classで頻繁に空になる
2. **最適化カバレッジ不足**:
- C0-C3: HeapV2 で 88-99% ヒット率 ✅
- **C4-C7: 最適化なし** ❌Random Mixed の 50%
- Ring Cache は実装済みだが **デフォルト OFF**
- HeapV2 拡張試験で効果薄(+0.3%
3. **支配的ボトルネック**:
- SuperSlab refill: 50-200 cycles/回
- TLS SLL ポインタチェイス: 3 mem accesses
- Metadata 走査: 32 slab iteration
### 解決策
**Ring Cache C4-C7 有効化**:
- ポインタチェイス: 3 mem → 2 mem (-33%)
- キャッシュミス削減(配列アクセス)
- 既実装(有効化のみ)、低リスク
- **期待: +13-29%** (19.4M → 22-25M ops/s)
---
## 推奨実施順序
### Phase 0: 理解
1. RANDOM_MIXED_SUMMARY.md を読む5分
2. なぜ C4-C7 が遅いかを理解
### Phase 1: Baseline 測定
1. RING_CACHE_ACTIVATION_GUIDE.md Step 1-2 を実施
2. 現在の性能 (19.4M ops/s) を確認
### Phase 2: Ring Cache 有効化テスト
1. RING_CACHE_ACTIVATION_GUIDE.md Step 4 を実施
2. C4-C7 Ring Cache を有効化
3. 性能向上を測定(目標: 22-25M ops/s
### Phase 3: 詳細分析(必要に応じて)
1. RANDOM_MIXED_BOTTLENECK_ANALYSIS.md で深掘り
2. FrontMetrics で Ring hit rate 確認
3. 次の最適化への道筋を検討
---
## 予想される性能向上パス
```
Now: 19.4M ops/s (23.4% of system)
Phase 21-1 (Ring C4/C7): 22-25M ops/s (25-28%) ← これを実施
Phase 21-2 (Hot Slab): 25-30M ops/s (28-33%)
Phase 21-3 (Minimal Meta): 28-35M ops/s (31-39%)
Phase 12 (Shared SS Pool): 70-90M ops/s (70-90%) 🎯
```
---
## 関連ファイル
### 実装ファイル
- `/mnt/workdisk/public_share/hakmem/core/front/tiny_ring_cache.h` - Ring Cache header
- `/mnt/workdisk/public_share/hakmem/core/front/tiny_ring_cache.c` - Ring Cache impl
- `/mnt/workdisk/public_share/hakmem/core/tiny_alloc_fast.inc.h` - Alloc fast path
- `/mnt/workdisk/public_share/hakmem/core/box/tls_sll_box.h` - TLS SLL API
### 参考ドキュメント
- `/mnt/workdisk/public_share/hakmem/CURRENT_TASK.md` - Phase 21-22 計画
- `/mnt/workdisk/public_share/hakmem/bench_random_mixed.c` - ベンチマーク実装
---
## チェックリスト
- [ ] RANDOM_MIXED_SUMMARY.md を読む
- [ ] RING_CACHE_ACTIVATION_GUIDE.md を読む
- [ ] Baseline を測定 (19.4M ops/s 確認)
- [ ] Ring Cache C4-C7 を有効化
- [ ] テスト実施 (22-25M ops/s 目標)
- [ ] 結果が目標値を達成したら ✓ 成功!
- [ ] 詳細分析が必要ならば RANDOM_MIXED_BOTTLENECK_ANALYSIS.md を参照
- [ ] Phase 21-2 計画に進む
---
**準備完了。実施をお待ちしています。**