P1 profiling baseline — radix_sort 27% / ssim 16% / backward 14% が三大 bottleneck、refine は僅か 2.6%

Phase D 30k で wallclock 42m vs brush 9m (-4.6x gap) の原因を kernel ごとに数値化。当初仮説は 「splat process CPU 63.4% = 1 thread bound、refine の host RMW (prune/split/clone) が dominant」 だった。これは誤りで、refine は 2.6% に過ぎない。 実 dominant は forward 内の radix_sort 27.0%、ssim 15.6%、backward 13.5%。 CPU 50% = main thread が GPU commit/wait_until_completed で blocking している 症状であり、CPU parallelization で解決しない (15 idle core は無関係)。優先順位を 低 hanging fruit → radix_sort → Phase E は最後 に反転すべき。

1. 計測 setup

2. per-kernel wallclock breakdown (1500 iter cumulative)

3. CPU / GPU 占有率の解釈

4. radix_sort が 27% も占めるのはなぜか?

• tile_bin.rs の radix sort は 16-pass: 4-bit radix × 16 pass = u64 key 全幅。各 pass で encoder 1 個 commit + wait、host CPU 側で prefix scan を 1 回 同期 (= 16 × commit_wait + 16 × scan = 32 boundary)。
• pair_count が iter で増加: 1500 iter で splats 5k→76k に成長、tile_bin pair 数も同様に成長。**30k では更に増加** (Phase D 最終 375k で pair_count は数 M 規模、ms/call は 3-5x 増の見込み)。
• Apple Metal Performance Shaders (MPS) の radix_sort は未使用: 現状 hand-rolled で動いており、MPS の MPSRadixSort や cooperative kernel 化で 2-3x 高速化の余地大。
• A.7 ICB batching は forward tail (extract_offsets + rasterize): radix_sort 自体は host scan を挟むため batch 対象外、別の最適化が必要 (= ROI 主軸)。

5. ROI 見積もり (Phase E / A.6 / kernel fusion / target_upload キャッシュ)

6. brush -4.6x gap の解釈

• brush 9m / 本実装 42m = -4.6x gap は radix_sort + ssim + backward の 3 kernel が brush の Burn/wgpu 実装と比べて遅いことに起因。
• brush も同じ algorithm なので構造的に 5x 遅いはずがない、kernel 実装効率 (MPS 利用 / atomic minimization / commit batching) の差。
• target_upload cache (即 -5.5%) で 42m → 39.7m。次に radix_sort -15% で 39.7m → 33.7m。 SSIM fusion -6% で 31.7m、 A.7 batching -6% で 29.7m。 累積で 42m → ~29m (-30%)、brush 9m まではまだ -3.2x ある (が +12-15m 圏は射程)。
• Phase E (refine GPU 化) は最後 -1〜-2m しか効かない、axis 1 (native Metal) の卒論主張としては必要だが、bench 改善の主役ではない。

7. 計測 instrumentation の実装

• splat/crates/splat-train-v1/src/timing.rs: 既存 thread-local `HashMap` accumulator に is_enabled() / disable() を追加。
• splat/crates/splat-train-v1/src/config.rs: `BackendConfig` に `profile: bool` を追加 (default false)。
• splat/crates/splat-train-v1/src/train_loop.rs: 既存の `ts_forward / ts_loss_gpu / ts_adam / ts_project_back` に加え、`ts_ssim_fwd_grad / ts_l1_combine_ssim / ts_backward_raster / ts_refine_accumulate / ts_refine / ts_opacity_decay / ts_opacity_reset / ts_scale_reg / ts_mcmc_*` を追加。 ts_loss_gpu parent は double-count 回避のため除去。
• splat/crates/splat-train-v1/src/trainer.rs: `forward_with_state` 内に `ts_fwd_project / ts_fwd_emit_pairs / ts_fwd_radix_sort / ts_fwd_extract_off / ts_fwd_rasterize` を追加 (forward sub-breakdown)。
• splat/crates/splat-cli/src/cmd/train.rs: `cfg.backend.profile == true` で timing::reset() + enable()、train_loop 終了時 `print_summary()` を log_every の max_steps tick で stderr 出力。
• splat/configs/2026-05-25-1200-lego-profile-smoke.toml: smoke config (1500 iter、profile=true)、parent: 2026-05-24-2000-lego-brushcompat-opacdecay-5k.toml。
• overhead 実測: profile=false で既存挙動と完全互換 (enable 判定で early return)、profile=true でも 1500 iter 36 s / 既存 baseline 推定 35 s = ~0.2% noise floor。

8. 想定外 / caveat

• GPU contention: 計測中 M4 Max 上で並行 splat trainer 3 本 (chair 30k / materials 30k / 別 smoke) が走っていた。absolute ms は 1.3-1.5x 膨張、しかし 相対順序は安定 (advisor 確認: contention は GPU ops を host ops より重く penalize するため、refine が bottleneck でないという結論は contention なしでも更に強化される)。
• 1500 iter vs 30k: 1500 iter 終了時の splats は 76k、Phase D 30k 最終 375k と 5x 差。forward 系 (radix_sort / rasterize / backward) は splats と pair_count に比例して伸びるため、 30k では top 3 占有率が更に+5pt 高い可能性。逆に refine 占有率は更に低下 (refine の per-call ms は splats 5x で 3-4x のみ増、call 数固定)。
• host Instant proxy の限界: GPU 内部 sub-stage (rasterize の tile 走査 vs 各 splat memo 等) は分解できない。MTLCounterSampleBuffer による HW counter 計測が次の精度向上 step (但し sudo 不要だが API 複雑、本 finding では proxy で十分と判断)。
• opacity_decay 0.001% は train_t→1 で no-op になる影響: 1500/1500 = train_t=1.0 で minus_opac=0 になり後半 11 tick は early return。 Phase D 30k 全期間でも 0.01% に届かず、Phase D を host で実装した判断は正当。

9. autonomous loop に向けた提案

1. P1 final-bench までに target_upload cache + radix_sort 改善を入れる → Lego 30k で wallclock 42m → ~30m を狙う (brush 9m gap は -3.3x まで縮小、論文評価で defensible)
2. radix_sort の真の中身を MTLCounterSampleBuffer で sub-pass 計測 (= 16-pass のうちどれが重いか、scan vs commit_wait vs sort pass)、 ~1 h 工数で投資し最適化方向を確定する
3. Phase E は axis 1 contribution の卒論記述として scope を確保しておく (refine GPU 化のコード自体は残し、bench 数値の主役からは外す)
4. A.6 f16 packed の deprioritize 確定: 既存 memo `feat_g_f16_packed_roi.md` の "wallclock ~1%" 数値と本 finding が一致、roadmap から外す

10. 再現手順

# 1. Build (P1 profiling instrumentation 含む binary)
cd splat
cargo build --release -p splat-cli

# 2. profile smoke 実行 (1500 iter、~35-50 s + GPU contention で 1.3-1.5x 増)
./target/release/splat train --config configs/2026-05-25-1200-lego-profile-smoke.toml

# 3. 期待出力: stderr に
#   [profile] kernel timing ON ([backend] profile=true)
#   ... training progress ...
#   === Kernel timing summary ===
#   kernel  | total | calls | avg/call | %total
#   ts_fwd_radix_sort | 9.679s | 1500 | 6.453ms | 27.0%
#   ...
#
# 4. 任意の config で計測したければ [backend] に profile = true を追加するだけ。
#    既存 config は profile flag を持たず default false なので互換。

11. 関連

• Phase D 30k baseline (wallclock 42m): p1-d-stage2-30k-results
• A.7 ICB batching (forward tail batching): a-7-icb-batching-results
• f16 packed ROI 検証 (deprioritize 確定): memo feat_g_f16_packed_roi.md
• 次予定: target_upload cache + radix_sort sub-pass profiling (本 finding ROI table の#1, #2 を実装)
• Phase E (refine GPU 化) memo: autonomous_plan_brush_parity.md (本 finding により優先度反転、卒論後 defer)

• positiveP1.D Stage 2 — Lego brushcompat + opacity decay 30k = 36.106 dB、splats -56% / wallclock -32%2026-05-25
• positiveA.7 batched cmd buffer — wallclock -6.2% 改善 + PSNR drift -0.30 dB2026-05-23