tomoaki/hakmem
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e51231471be93b210d6e6b94f1fb13a345a18ba5
hakmem/CURRENT_TASK_PERF_REBASE3.md
Moe Charm (CI) 118c0e4857 Phase FREE-DISPATCHER-OPT-1: free dispatcher 統計計測 
**目的**: free dispatcher（29%）の内訳を細分化して計測。

**実装内容**:
- FreeDispatchStats 構造体追加（ENV: HAKMEM_FREE_DISPATCH_STATS, default 0）
- カウンタ: total_calls / domain (tiny/mid/large) / route (ultra/legacy/pool/v6) / env_checks / route_for_class_calls
- hak_free_at / tiny_route_for_class / tiny_route_snapshot_init にカウンタ埋め込み
- 挙動変更なし（計測のみ、ENV OFF 時は overhead ゼロ）

**計測結果**:

Mixed 16-1024B (1M iter, ws=400):
- total=8,081, route_calls=267,967, env_checks=9
- BENCH_FAST_FRONT により大半は早期リターン
- route_for_class は主に alloc 側で呼ばれる（267k calls vs 8k frees）
- ENV check は初期化時の 9回のみ（snapshot 効果）

C6-heavy (257-768B, 1M iter, ws=400):
- total=500,099, route_calls=1,034, env_checks=9
- fg_classify_domain に到達する free が多い
- route_for_class 呼び出しは極小（snapshot 効果）

**結論**:
- ENV check は既に十分最適化されている（初期化時のみ）
- route_for_class は alloc 側での呼び出しが主で、free 側は snapshot で O(1)
- 次フェーズ（OPT-2）では別のアプローチを検討

**ドキュメント追加**:
- docs/analysis/FREE_DISPATCHER_ANALYSIS.md（新規）
- CURRENT_TASK.md に Phase FREE-DISPATCHER-OPT-1 セクション追加

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

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-11 21:21:40 +09:00

4.1 KiB
Raw Blame History

Phase PERF-ULTRA-REBASE-3: 正しいパラメータで再計測 (2025-12-11)

問題: Phase REBASE-2 で iters=1M, ws=400 は軽すぎて ULTRA 関数が invisible（238 samples のみ）だったため、正しいパラメータで再実施。

修正内容: iters=10M, ws=8192（Phase REBASE-1 と同じパラメータで再計測）

Mixed 16-1024B ホットパス（self% 上位, 1890 samples）

順位 関数 self% 分類
#1 free 29.22% free dispatcher
#2 main 19.27% benchmark overhead
#3 tiny_alloc_gate_fast 18.17% alloc gate
#4 tiny_c7_ultra_refill 6.92% C7 ULTRA refill
#5 malloc 5.00% malloc dispatcher
#6 tiny_region_id_write_header (lto_priv) 4.29% header write
#7 hak_super_lookup 2.90% segment lookup
#8 hak_free_at 2.36% free routing
#9 so_free 2.60% v3 free
#10 so_alloc_fast 2.46% v3 alloc

スループット:

  • Mixed 16-1024B: 30.6M ops/s (10M iter, ws=8192)
  • C6-heavy 257-768B: 17.0M ops/s (10M iter, ws=8192)

C6-heavy ホットパス（self% 上位, 3027 samples）

順位 関数 self% 分類
#1 worker_run 10.66% benchmark loop
#2 free 25.13% free dispatcher
#3 hak_free_at 19.89% free routing
#4 hak_pool_free_v1_impl 10.16% pool v1 free
#5 hak_pool_try_alloc_v1_impl 10.95% pool v1 alloc
#6 pthread_once 5.94% initialization
#7 hak_pool_free_fast_v2_impl 3.94% pool v2 fallback
#8 hak_super_lookup 4.39% segment lookup
#9 malloc 3.77% malloc dispatcher
#10 hak_pool_try_alloc (part) 0.66% pool alloc slow

分析

Mixed 16-1024B での変化:

  • free: 29.22% (benchmark 外のディスパッチャ部分)
  • tiny_alloc_gate_fast: 18.17% (前回 REBASE-1 の計測と一致)
  • C7 ULTRA refill: 6.92% (前回 REBASE-1 では 7.66% だったが、ワークロードにより変動範囲内)
  • C4-C7 ULTRA free 群: 個別には invisible (< 1% each) だが、合計で数%程度
  • so_alloc系: 2.46% (so_alloc_fast) + 1.16% (so_alloc) = 約 3.62%
  • page_of/segment: hak_super_lookup 2.90%

C6-heavy での状況:

  • pool v1 経路が dominant: hak_pool_free_v1_impl (10.16%) + hak_pool_try_alloc_v1_impl (10.95%)
  • hak_free_at: 19.89% (free routing overhead が大きい)
  • hak_super_lookup: 4.39% (segment lookup)
  • C6-heavy は完全に pool v1 経路を使用（前回の FREE_PATH_STATS 分析と一致）

次のボトルネック確定

Mixed では:

  • free dispatcher 全体（29.22%） が最大
  • tiny_alloc_gate_fast（18.17%）が第二
  • C7 ULTRA refill（6.92%）は既に薄い部類

C6-heavy では:

  • hak_free_at（19.89%） が最大の allocator 内部ボトルネック
  • pool v1 alloc/free（各 10%）は構造的なコスト
  • hak_super_lookup（4.39%）も削減余地あり

次フェーズ候補

  1. Option A: free dispatcher 最適化 (Mixed 向け)

    • free() 内部の routing logic を最適化
    • hak_free_at の分岐を削減
    • 期待効果: Mixed で free 29% → 25% 程度に削減（+1-2M ops/s）

  2. Option B: alloc gate 最適化 (Mixed 向け)

    • tiny_alloc_gate_fast（18.17%）の内部最適化
    • class 判定や routing の直線化
    • 期待効果: Mixed で alloc gate 18% → 15% 程度に削減（+1-2M ops/s）

  3. Option C: C6-heavy mid/pool 再設計 (C6 向け)

    • hak_free_at（19.89%）の C6 専用 fast path 追加
    • pool v1 の lookup overhead 削減
    • 期待効果: C6-heavy で 17M → 20-25M ops/s

推奨: Option A または B（Mixed が本線のため）。C6-heavy は別途 mid 再設計フェーズで対応。

生成ファイル

  1. /mnt/workdisk/public_share/hakmem/perf_ultra_mixed_v3.txt - Mixed 16-1024B の complete perf report (1890 samples)
  2. /mnt/workdisk/public_share/hakmem/perf_ultra_c6_v3.txt - C6-heavy の complete perf report (3027 samples)
  3. /mnt/workdisk/public_share/hakmem/CURRENT_TASK_PERF_REBASE3.md - 本レポート