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>
7.2 KiB
7.2 KiB
Phase 19: Frontend Layer A/B Test Results
テスト環境
- ベンチマーク:
bench_random_mixed_hakmem 500000 4096 42 - ワークロード: ランダム割り当て 16-1040バイト、50万イテレーション
- 測定対象: C2 (33-64B), C3 (65-128B) のヒット率と性能
A/Bテスト結果サマリー
| 設定 | Throughput | vs Baseline | C2 ヒット率 | C3 ヒット率 | 評価 |
|---|---|---|---|---|---|
| Baseline (UH + HV2) | 10.1M ops/s | - | UH=11.7%, HV2=88.3% | UH=0.2%, HV2=99.8% | ベースライン |
| HeapV2のみ (UH無効) | 11.4M ops/s | +12.9% ⭐ | HV2=99.3%, SLL=0.7% | HV2=97.3%, SLL=2.7% | 最速! |
| UltraHotのみ (HV2無効) | 6.6M ops/s | -34.4% ❌ | UH=96.4%, SLL=3.6% | UH=5.8%, SLL=94.2% | 大幅劣化 |
詳細分析
テスト1: Baseline(両方ON - 現状)
Throughput: 10.1M ops/s
Class C2 (33-64B):
UltraHot: 455 hits (11.7%)
HeapV2: 3450 hits (88.3%)
Total: 3905 allocations
Class C3 (65-128B):
UltraHot: 13 hits (0.2%)
HeapV2: 7585 hits (99.8%)
Total: 7598 allocations
観察:
- HeapV2 が主力として機能(88-99% ヒット率)
- UltraHot の貢献は微小(0.2-11.7%)
- 2層のチェックによる分岐オーバーヘッド発生
テスト2: HeapV2のみ(UltraHot無効) ⭐ 推奨設定
ENV: HAKMEM_TINY_FRONT_DISABLE_ULTRAHOT=1
Throughput: 11.4M ops/s (+12.9% vs Baseline)
Class C2 (33-64B):
HeapV2: 3866 hits (99.3%)
TLS SLL: 29 hits (0.7%) ← HeapV2 miss 時の fallback
Total: 3895 allocations
Class C3 (65-128B):
HeapV2: 7596 hits (97.3%)
TLS SLL: 208 hits (2.7%) ← HeapV2 miss 時の fallback
Total: 7804 allocations
重要な発見:
- UltraHot 削除で性能向上 (+12.9%)
- HeapV2 単独でも 97-99% の高ヒット率を維持
- UltraHot の分岐チェックがオーバーヘッドになっていた
- SLL が HeapV2 miss を拾って補完(0.7-2.7%)
分析:
- 分岐予測ミスのコスト > UltraHot のヒット率向上効果
- UltraHot チェック:
if (ultra_hot_enabled() && front_prune_ultrahot_enabled())- 毎回評価されるが、11.7% しかヒットしない
- 88.3% のケースで無駄な分岐チェック
- HeapV2 単独の方が 予測可能性が高い → CPU 分岐予測器に優しい
テスト3: UltraHotのみ(HeapV2無効) ❌ 非推奨
ENV: HAKMEM_TINY_FRONT_DISABLE_HEAPV2=1
Throughput: 6.6M ops/s (-34.4% vs Baseline)
Class C2 (33-64B):
UltraHot: 3765 hits (96.4%)
TLS SLL: 141 hits (3.6%)
Total: 3906 allocations
Class C3 (65-128B):
UltraHot: 248 hits (5.8%) ← C3 サイズに対応できていない!
TLS SLL: 4037 hits (94.2%) ← ほぼ全てが SLL に漏れる
Total: 4285 allocations
問題点:
- C3 でヒット率壊滅 (5.8%) → 94.2% が SLL に漏れる
- UltraHot の magazine サイズが C3 に不十分
- SLL アクセスは遅い(linked list traversal)
- 結果: -34.4% の大幅性能劣化
UltraHot の設計限界:
- C2: 4スロット magazine → 96.4% ヒット率(まずまず)
- C3: 4スロット magazine → 5.8% ヒット率(不十分)
- C3 の高需要に対応できない magazine 容量
結論と推奨事項
🎯 推奨設定: HeapV2のみ(UltraHot無効)
export HAKMEM_TINY_FRONT_DISABLE_ULTRAHOT=1
./bench_random_mixed_hakmem
理由:
- 性能向上 +12.9% (10.1M → 11.4M ops/s)
- コード簡素化 - 1層削減で分岐予測改善
- 高ヒット率維持 - HeapV2 単独で 97-99% 達成
- SLL fallback - HeapV2 miss 時は SLL が補完(0.7-2.7%)
❌ UltraHot 削除の根拠
定量的根拠:
- ヒット率貢献: 0.2-11.7%(微小)
- 分岐オーバーヘッド: 毎回評価(100% のケース)
- 性能影響: 削除で +12.9% 改善
定性的根拠:
- 設計の複雑性(Borrowing Design)
- HeapV2 との機能重複(C2/C3 両方対応)
- メンテナンスコスト > 効果
✅ HeapV2 保持の根拠
定量的根拠:
- ヒット率: 88-99%(主力)
- 性能影響: 無効化で -34.4% 劣化
- SLL fallback: miss 時も 0.7-2.7% で収まる
定性的根拠:
- シンプルな magazine 設計
- C2/C3 両方で高効率
- UltraHot より容量大(ヒット率高)
次のステップ
Phase 19-5: UltraHot 削除パッチ作成
-
コード削除:
core/front/tiny_ultra_hot.h/c削除tiny_alloc_fast.inc.hから UltraHot セクション削除- ENV 変数
HAKMEM_TINY_ULTRA_HOT削除
-
ビルドシステム更新:
- Makefile から UltraHot 関連削除
- build.sh 更新
-
ドキュメント更新:
- CLAUDE.md に Phase 19 結果追記
- CURRENT_TASK.md 更新
Phase 19-6: 回帰テスト
-
性能検証:
bench_random_mixed_hakmem- 目標: 11M+ ops/slarson_hakmem- 安定性確認bench_fixed_size_hakmem- 各サイズクラス確認
-
機能検証:
- HeapV2 単独で全サイズクラス対応確認
- SLL fallback 動作確認
- Prewarm 動作確認
ChatGPT 先生の戦略検証 ✅
Phase 19 戦略:
- ✅ 観測 (Box FrontMetrics) → HeapV2 88-99%, UltraHot 0.2-11.7%
- ✅ 診断 (Box FrontPrune A/B) → UltraHot 削除で +12.9%
- ⏭️ 治療 (UltraHot 削除実装) → 次フェーズ
結果:
- 「観測 → 診断 → 治療」のアプローチが 完璧に機能 🎉
- 直感に反する発見(UltraHot が阻害要因)を データで証明
- A/B テストで リスクなし確認 してから削除へ
ファイル変更履歴
Phase 19-1 & 19-2 (Metrics):
core/box/front_metrics_box.h- NEWcore/box/front_metrics_box.c- NEWcore/tiny_alloc_fast.inc.h- メトリクス収集追加
Phase 19-3 (FrontPrune):
core/box/front_metrics_box.h- ENV切り替え関数追加core/tiny_alloc_fast.inc.h- ENV条件分岐追加
Phase 19-4 (A/B Test):
- このレポート:
PHASE19_AB_TEST_RESULTS.md - 分析:
PHASE19_FRONTEND_METRICS_FINDINGS.md
付録: 性能比較グラフ(テキスト)
Throughput (M ops/s):
Baseline ████████████████████ 10.1
HeapV2のみ ██████████████████████ 11.4 (+12.9%) ⭐
UltraHotのみ █████████████ 6.6 (-34.4%) ❌
0 2 4 6 8 10 12 (M ops/s)
C2 Hit Rate (33-64B):
Baseline: [UH 11.7%][======= HV2 88.3% =======]
HeapV2のみ: [============ HV2 99.3% ===========][SLL 0.7%]
UltraHotのみ:[========== UH 96.4% ==========][SLL 3.6%]
C3 Hit Rate (65-128B):
Baseline: [UH 0.2%][========== HV2 99.8% ==========]
HeapV2のみ: [========= HV2 97.3% =========][SLL 2.7%]
UltraHotのみ:[UH 5.8%][========== SLL 94.2% ==========] ← 壊滅!
まとめ: ChatGPT 先生の推奨通り、Box FrontMetrics → Box FrontPrune で科学的にフロント層を分析した結果、UltraHot削除で +12.9% 性能向上 という明確な結論が得られたにゃ!🎉