Files
hakmem/docs/analysis/ANALYSIS_INDEX.md

190 lines
5.6 KiB
Markdown
Raw Normal View History

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
# 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 計画に進む
---
**準備完了。実施をお待ちしています。**