Files

Moe Charm (CI) bcfb4f6b59 Remove dead code: UltraHot, RingCache, FrontC23, Class5 Hotpath

(cherry-picked from 225b6fcc7, conflicts resolved)

2025-11-26 12:33:49 +09:00

4.4 KiB

Raw Blame History

CURRENT TASK – Performance Optimization Status

Last Updated: 2025-11-25 Scope: Random Mixed 16-1024B / Arena Allocator / Architecture Limit Analysis

🎯 現状サマリ

✅ Arena Allocator 実装完了 - mmap 95% 削減達成

Metric	Before	After	Improvement
mmap syscalls	401	32	-92%
munmap syscalls	378	3	-99%
Performance (10M)	~60M ops/s	68-70M ops/s	+15%

現在の性能比較 (10M iterations)

System malloc: 93M ops/s (baseline)
HAKMEM:        68-70M ops/s (73-76% of system malloc)
Gap:           ~25% (構造的オーバーヘッド)

🔬 Phase 27 調査結果: アーキテクチャ限界の確認

試した最適化（すべて失敗）

最適化案	結果	効果
C5 TLS容量 2倍 (1024→2048)	68-69M	変化なし
Registry lookup削除	68-70M	変化なし
Ultra SLIM 4-layer	~69M	変化なし
Phase 27-A: Ultra-Inline (全size)	56-61M	-15% 悪化 ❌
Phase 27-B: Ultra-Inline (9-512B)	61-62M	-10% 悪化 ❌

Phase 27 失敗の原因

Workload の ~52% が headerless classes (cls 0: 1-8B, cls 7: 513-1024B)
Headerless クラスをフィルタする条件分岐自体が overhead
Classes 1-6 からの利益 < 条件分岐の overhead

残り 25% ギャップの原因（構造的オーバーヘッド）

Header byte オーバーヘッド - 毎 alloc/free で 1 バイト書き込み/読み込み
TLS SLL カウンタ - 毎回 count++ / count-- (vs tcache: pointer のみ)
多層分岐 - 4-5層 dispatch (vs tcache: 2-3層)

結論

68-70M ops/s が現アーキテクチャの実質的な限界。System malloc の 93M ops/s に到達するには:

Header-free design への全面的な見直し
tcache 模倣（カウンタ削除、分岐削減）

が必要だが、現時点では投資対効果が低い。

📁 主要な修正ファイル（Arena Allocator 実装）

core/box/ss_cache_box.inc:138-229 - SSArena allocator 追加
core/box/tls_sll_box.h:509-561 - Release mode で recycle check オプショナル化
core/tiny_free_fast_v2.inc.h:113-148 - Release mode で cross-check 削除
core/hakmem_tiny_sll_cap_box.inc:8-25 - C5 容量を full capacity に変更
core/hakmem_policy.c:24-30 - min_keep tuning
core/tiny_alloc_fast_sfc.inc.h:18-26 - SFC defaults tuning

🗃 過去の問題と解決（参考）

Arena Allocator 以前の状態

Random Mixed (5M ops): ~56-60M ops/s, mmap 418回 (mimalloc の 26倍)
根本原因: SuperSlab = allocation単位 = cache単位という設計ミスマッチ
問題: ws=256 では Slab が 5-15% 使用率で停滞 → 完全 EMPTY にならない → LRU キャッシュ不発 → 毎回 mmap/munmap

Arena Allocator による解決

SuperSlab を OS 単位として扱う Arena allocator 実装
mmap 418回 → 32回 (-92%)、munmap 378回 → 3回 (-99%)
性能 60M → 68-70M ops/s (+15%)

📊 他アロケータとのアーキテクチャ対応（参考）

HAKMEM	mimalloc	tcmalloc	jemalloc
SuperSlab (2MB)	Segment (~2MiB)	PageHeap	Extent
Slab (64KB)	Page (~64KiB)	Span	Run/slab
per-class freelist	pages_queue	Central freelist	bin/slab lists
Arena allocator	segment cache	PageHeap	extent_avail

🚀 将来の可能性（長期）

Slab-level EMPTY Recycling（未実装）

Goal: Slab を cross-class で再利用可能にする
設計: EMPTY slab を lock-free stack で管理、alloc 時に class_idx を動的割り当て
期待効果: メモリ効率向上（ただし性能向上は限定的）

Abandoned SuperSlab（MT 用、未実装）

Goal: スレッド終了後のメモリを他スレッドから reclaim
設計: mimalloc の abandoned segments 相当
実装タイミング: MT ワークロードで必要になってから

✅ 完成したマイルストーン

Arena Allocator 実装 - mmap 95% 削減達成 ✅
Phase 27 調査 - アーキテクチャ限界の確認 ✅
性能 68-70M ops/s - System malloc の 73-76% に到達 ✅

現在の推奨: 68-70M ops/s を baseline として受け入れ、他のワークロード（Mid-Large, Larson 等）の最適化に注力する。

4.4 KiB Raw Blame History Unescape Escape