[{"data":1,"prerenderedAt":720},["ShallowReactive",2],{"finding:p2-counter-session":3,"finding-runs:p2-counter-session":586,"finding-related:p2-counter-session":613},{"meta":4,"impact":45,"sections":51},{"id":5,"title":6,"subtitle":7,"eyebrow":8,"date":9,"status":10,"category":11,"polarity":12,"axes":13,"tags":16,"task_code":28,"commit":29,"branch":30,"config_paths":31,"related_runs":35,"related_findings":39},"p2-counter-session","P2 counter session — default スタックの GPU busy% は 68〜69% で確定、H1 (bubble) 単独で W 比 0.70 を説明。H3 (DVFS) は棄却、卒論の「エネルギー 0.7-0.8× で勝つ」は不成立 (GPU energy 0.90×・package energy 1.06×)","Layer 1 (CB 区間 union) と Layer 2 (IOReport、sudo 不要) を同時に回し、replay bench n=3 ×2 regime \u002F 12.5k full run 1 本 \u002F msplat 交互 7 run で計測。\u003Cstrong>busy% は bench 68.9% (final) \u002F 67.5% (iter5000)、full run 補正値 68.6% の 3 系統が一致\u003C\u002Fstrong> — P1 の「~30%」は\u003Cstrong>同 doc 内で既に自己訂正済みの誤読\u003C\u002Fstrong> (30% は CPU 側 encoding の取り分、GPU compute は ~70% と書かれていた)、P2 の「~82%」は予算式の過大評価。msplat との交互実測 (splat n=3 \u002F msplat n=4、AC・warm) で \u003Cstrong>GPU 平均電力は splat 18.95 W vs msplat 26.92 W = 0.704×\u003C\u002Fstrong>、これは busy 比 (0.689) とほぼ一致するため \u003Cstrong>H1 (bubble) だけで説明でき H2 (activity factor) は null\u003C\u002Fstrong>。\u003Cstrong>H3 は逆向きに棄却\u003C\u002Fstrong>: 本実装は P15 (最高 P-state) に 98% 居座り、DVFS で落とされているのは\u003Cstrong>電力上限に当たっている msplat の方\u003C\u002Fstrong> (P15 residency 5.7〜89%)。wallclock が 1.273× 長いぶん W の優位は相殺され、\u003Cstrong>完走までの GPU energy は 0.897×、package energy は 1.062×\u003C\u002Fstrong>。","P2 並列性能軸 · 計測 · counter session (H1\u002FH2\u002FH3)","2026-08-16","stable","experiment","mixed",[14,15],1,3,[17,18,19,20,21,22,23,24,25,26,27],"counter-session","gpu-busy","ioreport","power","energy","dvfs","p-state","msplat","m4-max","thesis-ready","negative","2026-08 1× 工程表 v2 — AC 復帰後 計測 queue #1","56519c4fb432","main",[32,33,34],"splat\u002Fconfigs\u002F2026-08-16-counter-12500-prof.toml","splat\u002Fconfigs\u002F2026-08-16-counter-12500-noprof-r1.toml","splat\u002Fconfigs\u002F2026-08-16-counter-12500-noprof-r2.toml",[36,37,38],"counter-12500-prof","counter-12500-noprof-r1","counter-12500-noprof-r2",[40,41,42,43,44],"p2-w2-chained-submission","p2-msplat-parity-lego","p2-bench-harness-calibration","phase5-step30-profile","p2-s1-pipeline-resident",{"summary":46,"rank":47,"verdict":48,"delta_psnr":49,"delta_wallclock":50},"1× 工程表 v2 が「AC 復帰後 queue #1」に置いていた counter session を実施し、3 問すべてを実測で閉じた。\u003Cstrong>(1) busy% 論争は 68〜69% で決着\u003C\u002Fstrong> — bench (final 68.9% \u002F iter5000 67.5%、n=3、cb_dropped=0・overlap 1.00×) と 12.5k full run の補正値 (148.169s busy ÷ 同日 profile=false wallclock 216.12s = 68.6%) が一致。\u003Cstrong>(2) H1\u002FH2\u002FH3 の verdict は「H1 単独で説明・H2 null・H3 棄却」\u003C\u002Fstrong>。W 比 0.704 ≈ busy 比 0.689 なので activity factor の差 (H2) を持ち出す必要がなく、P-state residency は本実装が P15 に 97.6〜98.0% (bench) 居座る一方、msplat の方が電力上限で P10〜P14 に落ちる — \u003Cstrong>DVFS で損をしているのは msplat であって本実装ではない\u003C\u002Fstrong>。\u003Cstrong>(3) 卒論 positive の撤回\u003C\u002Fstrong>: roadmap v2 が期待した「エネルギー 0.7-0.8× = W\u002FPSNR 効率で勝つ」は\u003Cstrong>不成立\u003C\u002Fstrong>。W が 0.70× でも wallclock が 1.273× 長いので、完走までの GPU energy は \u003Cstrong>0.897×\u003C\u002Fstrong> (10% 得) に留まり、CPU を含む package energy では \u003Cstrong>1.062×\u003C\u002Fstrong> (6% 損) に反転する。energy 0.75× を達成するには W 比 0.573× が必要で、実測 0.704× は energy 等価点 (0.764×) の外側。\u003Cstrong>結論: 卒論 §5 で電力効率を主張軸にはできない。正しい主張は「同じ package 電力枠でより長く回る = 熱設計に優しい」ではなく、単純に『S2\u002FS3 で bubble を潰せば W も energy も改善する余地が 31% 残っている』という engineering debt の定量化。\u003C\u002Fstrong>","high","busy-68to69pct-H1-only-H3-refuted-energy-claim-withdrawn","本 session の 12.5k n=3 self-eval (premultiplied convention) mean 36.174 dB (36.187 \u002F 36.130 \u002F 36.204)、profile=true 1 本 36.262 dB。msplat 30K native val (white) n=4 mean 36.539 dB。**convention 依存のため直接比較しない** (p2-msplat-parity-lego の cross-eval 表を参照)","12.5k profile=false n=3 mean **216.12s** (219.35 \u002F 222.71 \u002F 206.31) — W2 gate の 219.51s と同水準 (日内 drift 内)。msplat 30K n=4 mean **169.77s** (176.09 \u002F 161.37 \u002F 173.93 \u002F 167.68)。等価 gap = **1.273×**",[52,55,58,76,81,83,128,131,133,151,153,266,269,273,296,299,301,304,306,395,402,404,497,500,528,530,562,565,569,571,578,580],{"type":53,"text":54},"lead","commit 26cdc92 で入れた 2 層計装 — \u003Cstrong>Layer 1\u003C\u002Fstrong> (完了 command buffer の GPU 実行区間を union して busy% と同期税を出す) と \u003Cstrong>Layer 2\u003C\u002Fstrong> (IOReport private framework、sudo なしで GPU energy [J] と P-state residency を読む) — を AC 電源下で初めて本格運用した。加えて本 session で \u003Ccode>splat power-sample\u003C\u002Fcode> (standalone サンプラ) を足し、\u003Cstrong>msplat (別プロセス) の消費電力を本実装と同一の計測器で\u003C\u002Fstrong>取れるようにした。\u003Ccode>splat bench --power\u003C\u002Fcode> は本実装の計測区間を内側から括るので他実装には使えない、という穴を塞ぐためである。",{"type":56,"text":57},"heading","0. 環境条件と計器の妥当性検証 (これを通さない数値は使わない)",{"type":59,"items":60},"kv",[61,64,67,70,73],{"key":62,"value":63},"電源 \u002F 機体","AC 接続、M4 Max (36 GB)、macOS 26.5.2 (25F84)。GPU は本 session が専有",{"key":65,"value":66},"他プロセス","GPU を使う別プロジェクトは**無し** (Chrome \u002F Spotify の GPU プロセスは compositing のみ)。ただし同一機体で別プロジェクト otksynth の `cargo build` (rustc 多重) と `analyze-lab` (11 core) が断続的に走っており、**CPU 側は clean ではない**。IOReport は SoC-wide なので、GPU idle 床 (0.063〜0.172 W) は無視できるが **CPU 側の W 比較は汚染されている** (idle 床が session 中 3.99〜11.14 W と揺れた)",{"key":68,"value":69},"thermal","最初の計測前に 90 秒 idle でならし。以後は各 block 間に 20〜30 秒。Spotlight (mds) の PLY 再インデックスが full run 終盤に噛むことを実測で確認 (下記 §3 の tail 参照)",{"key":71,"value":72},"計器検証 (energy 線形性)","同一 workload を iters 200 \u002F 800 \u002F 3200 (3.58 \u002F 14.28 \u002F 57.75 s) で回し、GPU energy 65.204 \u002F 262.027 \u002F 1125.482 J → **18.22 \u002F 18.36 \u002F 19.49 W** と平均 W が安定 (長時間側の +7% は DVFS\u002Fthermal の立ち上がり)。energy は elapsed に線形。**battery smoke で出ていた 2.4 W は 75 ms 窓のカウンタ粒度アーティファクトで、長区間では再現しない**ことを確認",{"key":74,"value":75},"計器検証 (P-state 分布)","負荷下で OFF \u002F P1 \u002F P15 だけでなく P2〜P14 も実際に populate することを per_kernel mode で確認 (P15 が 61.6〜80.9% まで下がり P3\u002FP4\u002FP6\u002FP8\u002FP10\u002FP12\u002FP14 が立つ)。**residency channel は死んでおらず H3 の判定に使える**",{"type":77,"label":78,"variant":79,"text":80},"callout","計器の読み方 — `gpu_active_ratio` は busy% ではない","info","Layer 2 の \u003Ccode>active(P-state)\u003C\u002Fcode> は負荷下で常に 94〜100% を示すが、これは \u003Cstrong>「GPU が電源 OFF 状態でない時間の割合」\u003C\u002Fstrong>であって稼働率ではない。CB 間の bubble 中も GPU は P15 に居座ったままなので active に数えられる。稼働率は必ず Layer 1 の \u003Ccode>busy_pct\u003C\u002Fcode> (CB 区間 union ÷ wall) を使うこと。逆に Layer 1 の busy% も \u003Cstrong>CB 粒度\u003C\u002Fstrong>であり、CB 内の occupancy 低下 (SIMD divergence 等) は見えない — つまり \u003Cstrong>busy% が高いことは CB レベルの bubble が無いことしか意味しない\u003C\u002Fstrong>。",{"type":56,"text":82},"1. busy% の決着 — 3 系統が 68〜69% で一致",{"type":84,"columns":85,"align":93,"rows":96},"table",[86,87,88,89,90,91,92],"計測系統","条件","busy%","ms\u002Fiter","busy ms\u002Fiter","sync-tax ms\u002Fiter","健全性",[94,94,95,95,95,95,94],"left","right",[97,105,113,121],[98,99,100,101,102,103,104],"replay bench (final)","409,660 splats、chained、n=3","**68.9%**","18.178","12.498","5.662","cb_dropped=0 \u002F overlap 1.00× \u002F σ 0.30%",[106,107,108,109,110,111,112],"replay bench (iter5000)","ckpt_005000、chained、n=3","**67.5%**","16.769","11.312","5.464","cb_dropped=0 \u002F overlap 1.00× \u002F σ 0.48%",[114,115,116,117,118,119,120],"12.5k full run (実測値)","profile=true、wall 236.09s","62.8%","18.89","11.85","7.03","cb_dropped=0 \u002F cb 27.0 per iter",[122,123,124,125,118,126,127],"12.5k full run (**補正値**)","busy 148.169s ÷ 同日 profile=false wallclock 216.12s","**68.6%**","17.29","5.44","profiling の host overhead を分母から除いた推定",{"type":77,"label":129,"variant":79,"text":130},"補正の根拠 — profile=true の wallclock を分母にすると busy% が過小に出る","profile=true は host 側に計測 overhead を足す (分母が伸びる) だけで GPU 実行時間 (分子) は変えない。実際 \u003Ccode>busy 148.169s\u003C\u002Fcode> は profile ON\u002FOFF で不変とみなせるので、同日の profile=false wallclock (n=3 mean 216.12s) を分母に置き直すと \u003Cstrong>68.6%\u003C\u002Fstrong> となり bench の 68.9% \u002F 67.5% と一致する。\u003Cstrong>profile=false では busy 行そのものが出ないので直接測定はできない\u003C\u002Fstrong> — この 68.6% は 2 つの実測値 (148.169s と 216.12s) から作った推定値である旨を明示しておく。",{"type":56,"text":132},"1b. P1 (~30%) \u002F P2 (~82%) 推定はなぜズレたか",{"type":84,"columns":134,"align":139,"rows":140},[135,136,137,138],"推定","出所","実際に何を測っていたか","判定",[94,94,94,94],[141,146],[142,143,144,145],"**~30%**","P1 調査 (`phase5-step30-profile.md` 由来)","同 doc の表は \u003Ccode>STIME\u002F(UTIME+STIME) = 70%\u003C\u002Fcode>、\u003Ccode>Rust user code は CPU 時間の 30% のみ\u003C\u002Fcode> と書いている。これは \u003Cstrong>CPU 時間の内訳\u003C\u002Fstrong>であって GPU 稼働率ではない。しかも同 doc の「誤解 2」節が既に自己訂正しており、\u003Cstrong>「~55ms (~70%) = GPU compute ← CPU は blocked、GPU が物理的に計算」「~25ms (~30%) = CPU 側 encoding」\u003C\u002Fstrong>と正解を書いている","**誤読**。roadmap v2 が「P1 調査は ~30%」と引いたのは CPU 側の取り分を GPU busy% に読み替えたもの。P1 時点の正しい読み (~70% GPU compute) は\u003Cstrong>今回の実測 68.9% とほぼ一致\u003C\u002Fstrong>していた",[147,148,149,150],"**~82%**","P2 opus-5 調査の「予算式」(roadmap v2 §並列性能軸の編入)","repo 内の doc に式が残っておらず**基礎データを復元できない**。roadmap の記述は「GPU busy 推定 ~82% (P2 予算式)」のみ","**過大評価** (実測比 +13pt)。式が復元できない以上、原因は特定せず「予算式が per-kernel の host 時間 (wait 込み) を GPU 時間として積み上げた可能性がある」という**仮説の域を出ない**ことを明記しておく",{"type":56,"text":152},"2. H1 \u002F H2 \u002F H3 の判定 — msplat 交互実測 (splat n=3 \u002F msplat n=4、AC・warm、ABBA + BAB)",{"type":84,"columns":154,"align":163,"rows":164},[155,156,157,158,159,160,161,162],"run (実行順)","wallclock","GPU W (steady)","CPU W","package W","GPU J (完走)","package J","P15 residency",[94,95,95,95,95,95,95,95],[165,173,182,191,200,209,218,226,235,240,249,258],[166,167,168,169,170,171,171,172],"idle (pre)","60.1s","0.17","11.14","11.31","—","0.0%",[174,175,176,177,178,179,180,181],"splat 12.5k r1","219.35s","18.79","6.46","25.25","4,122","5,538","67.8%",[183,184,185,186,187,188,189,190],"msplat 30K r1","176.09s","20.69","3.56","24.25","3,643","4,270","5.7%",[192,193,194,195,196,197,198,199],"msplat 30K r2","161.37s","30.69","2.12","32.81","4,953","5,295","89.1%",[201,202,203,204,205,206,207,208],"splat 12.5k r2","222.71s","17.37","8.57","25.94","3,869","5,776","83.8%",[210,211,212,213,214,215,216,217],"msplat 30K r3","173.93s","27.80","3.54","31.34","4,836","5,452","52.7%",[219,220,185,221,222,223,224,225],"splat 12.5k r3","206.31s","4.59","25.28","4,268","5,216","95.7%",[227,228,229,230,231,232,233,234],"msplat 30K r4","167.68s","28.51","5.70","34.21","4,781","5,737","74.5%",[236,167,237,238,239,171,171,172],"idle (post)","0.07","3.99","4.06",[241,242,243,244,245,246,247,248],"**splat mean (n=3)**","**216.12s**","**18.95**","6.54","25.49","**4,086**","5,510","82.4%",[250,251,252,253,254,255,256,257],"**msplat mean (n=4)**","**169.77s**","**26.92**","3.73","30.65","**4,553**","5,188","55.5%",[259,260,261,262,263,264,265,171],"**比 (splat \u002F msplat)**","**1.273×**","**0.704×**","1.754×","0.832×","**0.897×**","**1.062×**",{"type":77,"label":267,"variant":79,"text":268},"計測 note — steady W の取り方と CPU 列の信頼度","各 run は \u003Ccode>splat power-sample --interval 5\u003C\u002Fcode> を workload と同時に走らせ (sampler duration は splat 200s \u002F msplat 150s)、\u003Cstrong>GPU W が peak の 50% を超えた最初のサンプル以降\u003C\u002Fstrong>を steady 区間として時間加重平均した (dataset load \u002F Python import の prologue を固定 offset でなく plateau 検出で落とすため)。完走 J は steady W × train-loop wallclock。\u003Cstrong>CPU 列は信用してはいけない\u003C\u002Fstrong>: IOReport は SoC-wide で、本 session 中は別プロジェクト (otksynth) の CPU 負荷と Claude エージェント自身が乗っており、idle 床が 3.99〜11.14 W と揺れた。GPU 列は idle 床 0.07〜0.17 W なので clean。\u003Cstrong>package 行は参考値\u003C\u002Fstrong>。",{"type":77,"label":270,"variant":271,"text":272},"計測 note — msplat 側は W の分散が大きい (電力上限に当たっているサイン)","warning","msplat は 20.69 → 30.69 → 27.80 → 28.51 W と \u003Cstrong>初回だけ 20.7 W まで落ち込み、以降 28〜31 W で安定\u003C\u002Fstrong>した。同時に P15 residency が 5.7% → 89.1% → 52.7% → 74.5% と動いており、\u003Cstrong>「電力\u002F熱の余裕が無いときは clock を落として 20 W に留まり、余裕が出ると P15 で 30 W まで引き上げる」\u003C\u002Fstrong>という power-limited な挙動そのもの。r1 は cold 開始 + ファン未加速の局面にあたる。一方 \u003Cstrong>splat は 17.37〜20.69 W と一貫して 19 W 前後\u003C\u002Fstrong>で、P15 residency が 67.8〜95.7% と高いのに W は上がらない — \u003Cstrong>電力上限に当たっておらず、demand-limited\u003C\u002Fstrong> であることを示す。この非対称性が下の H3 判定の直接証拠になる。",{"type":84,"columns":274,"align":279,"rows":280},[275,276,277,278],"仮説","判定基準 (P2 調査の判定表)","実測","verdict",[94,94,94,94],[281,286,291],[282,283,284,285],"**H1 — bubble (busy% が低い)**","W 比 ≈ busy 比 なら H1 で説明しきれる","W 比 **0.704**、busy 比 **0.689** (68.9% ÷ msplat 想定 100%)。両者は 2pt 差で一致","**採用 — H1 単独で W 差を説明できる**",[287,288,289,290],"**H2 — activity factor (同 busy でも瞬時電力が低い)**","W 比が busy 比より**さらに低い**なら H2 が上乗せされている","W 比 0.704 は busy 比 0.689 より**わずかに高い** (= H2 の余地は負方向)","**null — 追加要因として不要**。本実装の kernel が msplat より電力密度が低いという証拠はない",[292,293,294,295],"**H3 — DVFS (bubble が P-state を下げ超線形に電力減)**","本実装の P-state residency が低クロック側に寄っていれば H3","本実装は bench で **P15 = 97.6〜98.0%** (n=3、final regime)、full run でも 67.8〜95.7%。落ちているのは **msplat 側** (P15 5.7〜89.1%)","**棄却 (かつ逆向き)** — DVFS で clock を落とされているのは電力上限に当たる msplat であって本実装ではない",{"type":77,"label":297,"variant":271,"text":298},"H1 判定の前提 — msplat の busy% は測っていない (アーキ主張からの仮定)","busy 比の分母に置いた msplat ~100% は \u003Cstrong>実測値ではない\u003C\u002Fstrong>。msplat には Layer 1 計装が無く、「1 CB \u002F 0 wait だから CB レベルの bubble は原理的に存在しない」というアーキテクチャ上の主張から置いた値である。仮に msplat の実 busy% が 90% だとすると busy 比は 0.766 となり、W 比 0.704 との差 (-8%) が H2 の寄与として残る。\u003Cstrong>H2 が完全に null と言い切れるのは msplat 側 busy% が 95% 以上のときだけ\u003C\u002Fstrong>であり、この前提は本 finding の限界として記録しておく。",{"type":56,"text":300},"2b. 「ファンが msplat の半分」の正体 — 2× の電力差は存在しない",{"type":302,"text":303},"paragraph","元の観察 (本実装のファン騒音が msplat の半分以下) は \u003Cstrong>2× の電力差としては裏付けられなかった\u003C\u002Fstrong>。package 平均は splat 25.49 W vs msplat 30.65 W = \u003Cstrong>1.20×\u003C\u002Fstrong> にすぎず、GPU 単体でも 1.42× である。ただし msplat は瞬間 34〜35 W まで振れており (splat の最大は 24 W 帯)、ファン回転数は消費電力に対して強い非線形、体感騒音はさらに回転数の 2.5〜3 乗に効くため、\u003Cstrong>「20% の package 電力差 + ピーク 1.5×」が体感 2× の騒音差を生むこと自体は矛盾しない\u003C\u002Fstrong>。すなわち観察は正しいが、\u003Cstrong>その機構は『本実装の GPU が半分しか働いていない』ではなく『msplat が電力上限に張り付き、本実装は上限に届かない』\u003C\u002Fstrong>である。",{"type":56,"text":305},"3. 12.5k full run の busy 軌跡 (profile=true、log_every=250、window 差分)",{"type":84,"columns":307,"align":315,"rows":316},[308,309,310,311,312,313,314],"iter","splats","window ms\u002Fiter","window busy%","window busy ms","window sync-tax ms","cb\u002Fiter",[95,95,95,95,95,95,95],[317,325,332,339,346,353,360,367,374,381,388],[318,319,320,321,322,323,324],"500","562","5.99","41.4%","2.48","3.51","27.0",[326,327,328,329,330,331,324],"1,000","8,210","8.46","51.9%","4.40","4.07",[333,334,335,336,337,338,324],"1,500","72,182","11.74","66.8%","7.85","3.89",[340,341,342,343,344,345,324],"2,500","253,518","13.24","63.2%","8.37","4.87",[347,348,349,350,351,352,324],"4,000","349,303","17.33","65.7%","11.38","5.95",[354,355,356,357,358,359,324],"5,500","383,397","18.62","66.0%","12.30","6.32",[361,362,363,364,365,366,324],"7,000","398,049","23.48","56.4%","13.23","10.25",[368,369,370,371,372,373,324],"8,500","403,984","19.82","67.2%","13.32","6.50",[375,376,377,378,379,380,324],"10,500","406,727","22.72","**71.6%**","16.27","6.44",[382,383,384,385,386,387,324],"11,500","407,700","32.93","45.1%","14.84","18.08",[389,390,391,392,393,394,324],"12,500","409,140","26.34","54.4%","14.32","12.02",{"type":396,"items":397},"list",[398,399,400,401],"\u003Cstrong>busy% は splat 数に単調増加\u003C\u002Fstrong>: 序盤 (iter 500、562 splats) は 41.4%、大 splat 期 (iter 10,500、406k splats) で \u003Cstrong>71.6% がピーク\u003C\u002Fstrong>。GPU 側の仕事量が増えても host 側の同期税は 6.0〜6.5 ms\u002Fiter でほぼ一定なので、比として busy% が上がる。**逆に言えば同期税は splat 数に依らない固定コストで、小 scene ほど相対的に重い**","\u003Cstrong>refine tick (every=100) 自体は軌跡に見えない\u003C\u002Fstrong>: cb\u002Fiter は全区間で 27.0 固定、window busy% も 100 iter 周期の変動を示さない。refine の host readback は既に 511f916 で縮小済みで、250 iter 窓に均せば無視できる水準","\u003Cstrong>iter 7,000 \u002F 9,000 \u002F 11,500〜12,500 の落ち込み (45〜56%) は系統外 interference\u003C\u002Fstrong>: window busy ms は 13.2〜14.8 とほぼ一定のまま sync-tax だけが 6.5 → 18.1 ms に膨れており、**GPU の仕事量ではなく host 側が待たされている**。計測直後の `ps` で Spotlight (mds \u002F mds_stores) が PLY checkpoint を再インデックスしていたのを確認しており、これが主因と判断する。**この落ち込みは本実装の性質ではない**","cumulative busy% は 62.8% で着地するが、これは profiling 分母込みの値 (§1 の補正で 68.6%)",{"type":56,"text":403},"4. 律速答え合わせ — per-kernel gpu_ms 表 (per_kernel mode、n=3、GPU 側実時間)",{"type":84,"columns":405,"align":412,"rows":413},[406,407,408,409,408,410,411],"kernel (leaf)","final regime gpu_ms\u002Fiter","share","iter5000 gpu_ms\u002Fiter","host ms\u002Fiter (final)","同期税 (host−gpu)",[94,95,95,95,95,95,95],[414,422,430,438,446,454,462,469,477,484,491],[415,416,417,418,419,420,421],"ts_fwd_radix_sort","3.564","**26.3%**","2.975","**27.2%**","6.030","2.466",[423,424,425,426,427,428,429],"ts_backward_raster (+project_back)","4.556","**33.6%**","3.808","**34.8%**","5.319","0.763",[431,432,433,434,435,436,437],"ts_adam","1.879","13.8%","1.692","15.5%","2.753","0.874",[439,440,441,442,443,444,445],"ts_fwd_rasterize","1.611","11.9%","1.314","12.0%","1.798","0.187",[447,448,449,450,451,452,453],"ts_ssim_fwd_grad","1.354","10.0%","1.263","11.5%","2.775","1.421",[455,456,457,458,459,460,461],"ts_fwd_project","0.364","2.7%","0.329","3.0%","0.854","0.490",[463,464,465,466,465,467,468],"ts_fwd_emit_pairs","0.130","1.0%","0.107","0.586","0.456",[470,471,472,473,474,475,476],"ts_l1_combine_ssim","0.103","0.8%","0.097","0.9%","0.300","0.197",[478,479,480,481,480,482,483],"ts_fwd_extract_off","0.013","0.1%","0.012","0.160","0.147",[485,486,487,488,487,489,490],"**leaf 合計**","**13.574**","100%","**11.597**","20.575","7.001",[492,493,171,494,171,495,496],"(参照) 実測 GPU busy","12.874","11.714","19.254 (= ms\u002Fiter)","6.480",{"type":77,"label":498,"variant":79,"text":499},"表の読み方 — 3 つの帰属限界","(1) \u003Cstrong>label は入れ子\u003C\u002Fstrong>なので \u003Ccode>ts_forward\u003C\u002Fcode> (親) は除いて leaf のみを並べた。leaf 合計 13.574 は実測 busy 12.874 を 5.4% 上回るが、これは非ブロッキング回収 (\u003Ccode>gputime::harvest\u003C\u002Fcode>) が wait なし commit の CB を後続 label に重複帰属させるためで、\u003Cstrong>全体値は必ず \u003Ccode>gpu_busy_stats()\u003C\u002Fcode> を使う\u003C\u002Fstrong>という timing.rs の注記どおり。(2) \u003Ccode>ts_project_back\u003C\u002Fcode> の gpu_ms は \u003Ccode>ts_backward_raster\u003C\u002Fcode> と\u003Cstrong>ビット単位で同値\u003C\u002Fstrong> (final 4.556 \u002F iter5000 3.808) で、同一 CB 集合の二重計上。分離できないため 1 行に統合した。(3) \u003Cstrong>host 列との差 (同期税) は per_kernel mode 固有\u003C\u002Fstrong>で、default (chained) では loss chain 側が 1 CB に畳まれているため既に回収済み。",{"type":84,"columns":501,"align":504,"rows":505},[502,503,277,278],"HW-3 律速仮説","検証可能な列",[94,94,94,94],[506,511,515,519,523],[507,508,509,510],"radix_sort が forward の律速","leaf gpu_ms share","forward chain 5.682 ms のうち radix が **3.564 ms = 62.7%**。GPU 全体でも 26.3%（両 regime 安定）","**支持** — 単一 kernel として最大。ただし S2 (hierarchical scan) が狙うのは radix の *CB\u002Fwait 数* であって kernel 時間ではない点に注意",[512,508,513,514],"backward_raster が全体の律速","33.6% (project_backwards と分離不能な合算値)。Phase 5 step30b 時点の 52.1% からは大幅低下 (W1 warp sparse skip の -35.2% が効いている)","**部分的に支持** — 依然 単独最大ブロックだが、もはや過半ではない",[516,508,517,518],"ssim が重い","10.0〜11.5%。host 側では 2.775 ms だが GPU は 1.354 ms — **差 1.42 ms は同期税**で、W3a (float4 化) の GPU 側 upside は小さい","**下方修正** — W3a の優先度を下げる根拠",[520,508,521,522],"adam が無視できる","13.8〜15.5%。5 param group の合計として想定より大きい","**反証** — 無視できない。ただし W2 Stage A で CB は既に 1 本",[524,525,526,527],"chained は host 時間だけを削る (GPU 時間は不変)","chained vs per_kernel の実測 busy ms\u002Fiter (leaf 合計ではなく union 値で比較)","final 12.498 (chained) vs 12.874 (per_kernel) = **-2.9%**、iter5000 11.312 vs 11.714 = **-3.4%**。ms\u002Fiter 差 (-5.6% \u002F -6.2%) の**半分程度は GPU 側実時間の短縮**","**部分的に反証** — chained は host 同期税だけでなく GPU 側実時間も 3% 前後削っている (CB 立ち上げ \u002F 終了の firmware コストが CB 数 36 → 27 に比例して減るため)",{"type":56,"text":529},"5. chained vs per_kernel の対照 (default 交代の副次確認、n=3、warm)",{"type":84,"columns":531,"align":535,"rows":536},[532,89,88,90,91,533,534,162],"regime \u002F mode","GPU W","J\u002Fiter",[94,95,95,95,95,95,95,95],[537,542,549,554],[538,101,100,102,103,539,540,541],"final \u002F **chained (default)**","19.33","0.350","**97.6〜98.0%**",[543,544,545,493,496,546,547,548],"final \u002F per_kernel","19.254","66.3%","19.49","0.375","80.7〜80.9%",[550,109,108,110,111,551,552,553],"iter5000 \u002F **chained (default)**","16.40","0.276","94.6〜96.9%",[555,556,557,494,558,559,560,561],"iter5000 \u002F per_kernel","17.869","65.6%","6.155","19.15","0.346","80.8〜94.3%",{"type":77,"label":563,"variant":271,"text":564},"計測 note — この表の W \u002F J 列は mode 間で比較しないこと","chained の 2 regime は session 前半 (cold)、per_kernel の 2 regime は session 後半 (warm、msplat interleave 後) に取っており、\u003Cstrong>thermal \u002F 電力上限の状態が違う\u003C\u002Fstrong>。実際 iter5000 の W は chained 16.40 \u002F per_kernel 19.15 と逆転しているが、これは submission の差ではなく機体状態の差である (§2 で見たとおり warm な方が P15 を掴みやすい)。\u003Cstrong>mode 間で意味があるのは ms\u002Fiter \u002F busy% \u002F sync-tax \u002F P15 residency の 4 列だけ\u003C\u002Fstrong>。W の mode 比較が要るなら 1 session 内で交互に取り直すこと。",{"type":77,"label":566,"variant":567,"text":568},"副産物 — CB 数を増やすと DVFS が実際に効く (H3 の機構自体は実在する)","success","同一 workload で submission だけを per_kernel に戻すと (CB 27 → 36 per iter)、\u003Cstrong>P15 residency が 98% → 81% に落ち、P3\u002FP4\u002FP6\u002FP8\u002FP10\u002FP12\u002FP14 が立つ\u003C\u002Fstrong>。これは「短い dispatch が断続すると DVFS が上がりきらない」という H3 の機構\u003Cstrong>そのものが実在する\u003C\u002Fstrong>ことの直接証拠である。default (chained) スタックでその影響が無視できるのは、W2 で CB 数を既に十分減らしてあるから。\u003Cstrong>つまり H3 は『機構としては真、現行 default では効いていない』\u003C\u002Fstrong>。逆に S2\u002FS3 で CB をさらに減らしても、P15 は既に 98% なので DVFS 経由の上積みは期待できない — \u003Cstrong>S2 の期待値は純粋に bubble (sync-tax 31%) の回収分に限られる\u003C\u002Fstrong>。",{"type":56,"text":570},"6. 卒論への含意",{"type":396,"items":572},[573,574,575,576,577],"\u003Cstrong>「W\u002FPSNR 効率で勝つ」は書けない\u003C\u002Fstrong>。GPU energy で 0.897×、package energy で 1.062× — どちらも『勝つ』と主張できる幅ではない。roadmap v2 が期待した energy 0.7-0.8× には W 比 0.573× が必要で、実測 0.704× は energy 等価点 0.764× の外側 (= wallclock の不利を W の有利が埋め切れない)。\u003Cstrong>この行は撤回する\u003C\u002Fstrong>","\u003Cstrong>そもそも W\u002FPSNR という量を作らない\u003C\u002Fstrong>。dB は対数量なので「1 dB あたりの電力」に物理的意味がなく、加えて p2-msplat-parity-lego が示したとおり PSNR の勝敗は eval convention で反転する (brush convention なら本実装 +1.79 dB、white-bg なら msplat +1.09 dB)。\u003Cstrong>energy と PSNR は対で、PSNR は convention 明記のうえ並記する\u003C\u002Fstrong>","\u003Cstrong>positive として書けるのは『まだ 31% 残っている』という定量化\u003C\u002Fstrong>。sync-tax は replay bench final regime で 5.662 ms\u002Fiter = wallclock の 31.1%、12.5k full run でも 5.44 ms\u002Fiter = 31.4% と一致する。仮に busy% を 100% まで詰めれば full run は \u003Cstrong>216.12s → 148.17s\u003C\u002Fstrong> (= GPU busy 148.169s そのもの) となり、msplat 等価 gap 1.273× は \u003Cstrong>0.87× (追い越し)\u003C\u002Fstrong> に届く計算。これは axis 1 (native Metal) の残工程を正当化する数字であり、同時に \u003Cstrong>S2 \u002F S3 を合わせた期待値の理論上限\u003C\u002Fstrong>でもある (これ以上は kernel 自体を速くするしかない)","\u003Cstrong>axis 3 (CPU densify) の構造的代償は上限 2〜4pt という roadmap の記述は維持できる\u003C\u002Fstrong>。full run 軌跡で refine tick は cb\u002Fiter にも window busy% にも現れず、busy% の主変動要因は splat 数 (41% → 72%) だった。つまり **68.9% と 100% の差 31pt のうち、refine 起因は小さく大半は submission\u002Fpipelining の engineering debt** という位置づけは実測で支持された","\u003Cstrong>「GPU を遊ばせているから静か」という語り口は誤り\u003C\u002Fstrong>。実測では本実装は P15 に居座りつつ 19 W を安定して引いており、msplat が 30 W まで振れて電力上限に当たっているのが騒音差の正体。卒論では『本実装は electrical\u002Fthermal headroom を使い切れていない』= \u003Cstrong>性能を取りこぼしている側の記述\u003C\u002Fstrong>として書く",{"type":56,"text":579},"7. 追試すべき残件",{"type":396,"items":581},[582,583,584,585],"\u003Cstrong>msplat 側の busy% を実測する経路がない\u003C\u002Fstrong> — H1 verdict は msplat ~100% の仮定に依存している。Xcode GPU capture (Metal System Trace) を msplat プロセスに当てれば CB 占有率が直接見えるはず。counter session の『Xcode capture で limiter 確定』は本 session では未実施 (時間と GUI 操作の都合)","\u003Cstrong>CPU 側 W の clean な再計測\u003C\u002Fstrong> — 本 session は同一機体で別プロジェクトの CPU 負荷が乗っており package energy 1.062× の確度が低い。他プロセス完全停止下で 1 往復取り直せば package の主張が確定する","\u003Cstrong>CB 内 occupancy\u003C\u002Fstrong> — busy 68.9% は CB 粒度の値で、CB 内の SIMD divergence \u002F メモリ待ちは含まれない。radix \u002F backward_raster の真の limiter (ALU \u002F bandwidth \u002F occupancy) は Xcode の counter set が要る","\u003Cstrong>mipnerf 級 (1M splats) での再測\u003C\u002Fstrong> — sync-tax が splat 数に依らない固定コストであることが分かったので、大 scene ほど busy% は上がる (= gap は縮む)。Lego 409k で 68.9% なら 1M では 80% 圏の可能性があり、卒論の scene 依存性の節に使える",[587,599,605],{"id":37,"title":37,"subtitle":588,"date":9,"workspace":589,"tags":590,"verdict":594,"psnr":595,"psnr_unit":-1,"wallclock":596,"splats":597,"summary_url":598,"detail_path":598},"counter session step 4: msplat との GPU 電力 interleave 比較用の本実装 12.5k (profile=false)。同時に当日の S2 gate baseline wallclock も兼ねる","splat",[5,20,591,592,593],"msplat-interleave","no-profile","lego-12500","partial",36.2037467956543,"3m 26s",408243,"\u002Fruns\u002Fcounter-12500-noprof-r1\u002F",{"id":38,"title":38,"subtitle":588,"date":9,"workspace":589,"tags":600,"verdict":594,"psnr":601,"psnr_unit":-1,"wallclock":602,"splats":603,"summary_url":604,"detail_path":604},[5,20,591,592,593],36.12981414794922,"3m 39s",407912,"\u002Fruns\u002Fcounter-12500-noprof-r2\u002F",{"id":36,"title":36,"subtitle":606,"date":9,"workspace":589,"tags":607,"verdict":594,"psnr":609,"psnr_unit":-1,"wallclock":610,"splats":611,"summary_url":612,"detail_path":612},"counter session (H1\u002FH2\u002FH3): default スタック 12.5k を profile=true で 1 本 — [gpu] busy 軌跡 (refine tick \u002F 序盤大 splat 期 vs 後期) を取る。wallclock は profiling オーバーヘッド込みなので 219.51s 系列とは比較不可",[5,18,608,593],"profile-on",36.2624397277832,"3m 56s",409140,"\u002Fruns\u002Fcounter-12500-prof\u002F",[614,635,656,679,700],{"id":42,"title":615,"date":9,"status":10,"polarity":616,"category":617,"axes":618,"tags":619,"task_code":628,"related_runs":629,"delta_psnr":-1,"delta_wallclock":631,"rank":47,"verdict":632,"impact_summary":633,"detail_path":634},"splat bench harness 実装 + calibration — σ_replay 0.83%、full run 比 ~6x ノイズ削減","positive","tooling",[14,15],[620,621,622,623,624,625,626,627],"bench-harness","calibration","variance","reproducibility","c7","fixed-workload","gate-infra","lego","splat bench harness (2026-08-16 GPU 専有タスク)",[630],"lego-bench-calib-checkpoints","σ_replay 0.83% (n=10, final-scale workload) vs full run 実測 ~10% — 約 6x ノイズ削減","accepted","`splat bench --config bench.toml` を実装し、同一 config n=10 replay で \u003Cstrong>σ_replay = 0.234 ms\u002Fiter (mean 28.339 ms 比 0.83%)\u003C\u002Fstrong> を実測。full training run で観測されていた ~10% 分散に対し \u003Cstrong>約 6x のノイズ削減\u003C\u002Fstrong>。3-regime (iter 1000 \u002F 5000 \u002F final checkpoint、各 n=5) でも σ 1.2-4.6% の範囲に収まり、splat 数が少ない早期 regime ほど相対分散が大きい傾向を確認。有意判定閾値を \u003Ccode>max(2σ, 1%)\u003C\u002Fcode> と規約化し、以後の gate 判定をこの harness の計測に載せ替える。付随して `--parity` (kernel variant 間の勾配 \u002F binning 一致検証) と `[output] save_ply_at` (checkpoint 保存) を実装、parity mode の実測で production-scale シーンの `sorted_idx` tie-order 非決定性 (~0.2%、真の非決定性であって variant 差ではない) を発見し gate から除外した。","\u002Ffindings\u002Fp2-bench-harness-calibration\u002F",{"id":41,"title":636,"date":9,"status":10,"polarity":12,"category":11,"axes":637,"tags":639,"task_code":647,"related_runs":648,"delta_psnr":651,"delta_wallclock":652,"rank":47,"verdict":653,"impact_summary":654,"detail_path":655},"P2 msplat parity — 同日等価比較で msplat 30K = 167.7s \u002F 36.5 dB、gap は 12.5k で 2.10× (matched-wallclock 7.5k は 1.08× で brush +0.94 dB)",[14,638],2,[640,641,24,642,643,644,645,646,627,25,26],"gap-sweep","phase-3","parity","baseline","cross-eval","eval-convention","thermal-interleave","2026-08 msplat gap sweep Phase 3 (parity 再計測)",[649,650],"lego-parity-noprof-12500","lego-parity-noprof-7500","brush convention (同一 evaluator): 本実装 12.5k +1.79 dB \u002F 7.5k +0.94 dB (vs msplat 30K q8 34.47)。white-bg convention: msplat +1.09 dB (36.28 vs 本実装 12.5k 35.19)","msplat 30K 167.7s vs 本実装 12.5k 352.3s = **2.10×** (両者 profile なし・同日実測)。matched-wallclock: 7.5k 181.4s = 1.08×。従来の 1.53× (spike 値 220s 基準) は撤回","parity-established-gap-2.10x-convention-coupled-psnr","gap sweep の公式 gap 数値を \u003Cstrong>同日・同一条件の実測で確定\u003C\u002Fstrong>: Lego 12.5k vs msplat 30K の wallclock gap は \u003Cstrong>2.10×\u003C\u002Fstrong> (352.3s vs 167.7s、両者 profiling なし) — Phase 2 の 1.53× は spike の古い msplat 値 (219.8s) 起因の過小評価だった。一方 \u003Cstrong>matched-wallclock 断面 (本実装 7.5k = 181.4s、msplat の 1.08×)\u003C\u002Fstrong> では brush convention の同一 evaluator cross-eval で本実装が \u003Cstrong>+0.94 dB\u003C\u002Fstrong> (35.41 vs 34.47)。PSNR 比較は eval convention に強く依存し (white-bg では msplat +1.09 dB)、p1-a-3 の「訓練\u002F評価 convention coupling」を第三者実装との比較で再実証した。msplat の native 品質が spike 比 +1.05 dB 向上した主因は今回の対称条件 (同一 culled init.ply 5207 pts・train 100 view 全量・常時フル解像度) にあり、msplat 側の条件を今回初めて本実装と揃えた結果。卒論 §5 の direct comparison 表はこの数値で置き換える。","\u002Ffindings\u002Fp2-msplat-parity-lego\u002F",{"id":44,"title":657,"date":9,"status":10,"polarity":616,"category":11,"axes":658,"tags":659,"task_code":668,"related_runs":669,"delta_psnr":674,"delta_wallclock":675,"rank":47,"verdict":676,"impact_summary":677,"detail_path":678},"S1 pipeline 全域 resident 化 — replay bench -22.9% (final regime) で採用 (Tier A\u002FB\u002FC)",[14,15],[640,660,661,662,663,664,665,666,620,627,667],"phase-2","s1","resident","alloc-audit","unified-memory","gpu-gate","adopted","attribution","S1 pipeline 全域 resident 化 worktree 統合 + GPU gate (2026-08-16 GPU 専有タスク)",[670,671,672,673,630],"lego-s1-resident-12500","lego-s1-resident-12500-rep2","lego-s1-resident-12500-rep3","lego-gap-baseline-12500","12.5k full run PSNR guard: 基準 36.19 前後 (歴代同 recipe 7 run 分布 36.138-36.226) に対し rep1 36.051 (-0.14、guard 外) \u002F rep2 36.168 \u002F rep3 36.224 dB → n=3 mean 36.148 dB = -0.04 dB (±0.1 dB guard 内、PASS)。rep1 は歴代最低値だが S1 は数学的同値 (parity test 群で証明) のため run 分散の tail と判定","replay bench final regime n=3: 28.630 → 22.059 ms\u002Fiter = **-22.9%** (閾値 max(2σ,1%)=2.05%)。iter5000 regime n=3: 26.113 → 20.405 ms\u002Fiter = **-21.9%** (閾値 1.29%)。12.5k full run: 公式 336.33s → rep1 272.36s \u002F rep2 257.55s \u002F rep3 254.73s = mean 261.55s (**-22.2%**)","adopted-unconditional-no-flag","別 worktree で実装済みだった S1 (pipeline 全域 resident 化) を main へ統合。C3 統合後の tile_bin.rs と conflict したため手 merge し、C3 (rejected flag) との新規相互作用 (S1 の buffer 直結が C3 の panic guard に当たる) はフォールバック + regression test で解決。build warning 0、MSL smoke compile (adam.metal binding 変更) + 新規 S1 test 9 本 (resident byte-stability \u002F grow path \u002F ForwardState parity \u002F Vec vs raw parity \u002F C3 fallback) 含む workspace 全 test pass。replay bench は \u003Cstrong>final regime -22.9% \u002F iter5000 -21.9%\u003C\u002Fstrong> と Phase 2 単一項目として C0 に次ぐ効果で、attribution 計測 (S1 で新設した DispatchAttribution 4 点) が alloc 成分の消滅を直接証明 — C0 の「主犯は first-touch page fault」結論の pipeline 全域への一般化。12.5k full gate は PSNR rep1 が guard 外 (36.051) に出たが n=3 escalation で tail variance と確定 (rep2 36.168 \u002F rep3 36.224、歴代同 recipe 分布 36.14-36.23)。採用 — flag なしの無条件変更として default 化。","\u002Ffindings\u002Fp2-s1-pipeline-resident\u002F",{"id":40,"title":680,"date":9,"status":10,"polarity":616,"category":11,"axes":681,"tags":682,"task_code":690,"related_runs":691,"delta_psnr":695,"delta_wallclock":696,"rank":47,"verdict":697,"impact_summary":698,"detail_path":699},"W2 encoder\u002FCB 統合 — replay -13.7% \u002F 12.5k -9.1% (bit-exact、default flip)",[14,15],[683,684,685,686,687,688,689,627,664],"1x-roadmap-v2","w2","chained-submission","command-buffer","encoder","set-bytes","bit-exact","2026-08 1× 工程表 v2 W2",[692,693,694],"lego-w2-chained-12500","lego-w2-chained-12500-rep2","lego-w2-chained-12500-rep3","12.5k gate n=3: 36.160 \u002F 36.203 \u002F 36.146 dB → mean 36.170 dB = W1 基準 36.201 (n=3 mean) 比 -0.031 dB (guard ±0.1 内、n=3 mean 判定 — n=1 判定なし)","replay bench final regime: 20.869 → 18.005 ms\u002Fiter = **-13.7%** (clean batch 帯 -13.7〜-16.2%、閾値 max(2σ,1%)=1.9%)。iter5000 regime: clean 帯 18.60〜19.76 → 16.56〜16.61 = **-10.7〜-15.9%** (閾値 ≤2.8%)。12.5k full run n=3: 213.42 \u002F 224.83 \u002F 220.27s → mean **219.51s** (W1 基準 241.41s 比 **-9.1%**)","w2-adopted-default-flip-chained","1× 工程表 v2 の第 2 波。HW 4 軸調査 #2 の CB\u002Fwait 監査 (本実装 ~21 CB \u002F ~11 wait vs msplat 1 CB \u002F 0 wait) を受け、submission 戦略を BackendConfig の enum variant として実装・gate した。同一 CB 内の連続 encoder は firmware が CPU 介在なしに back-to-back 実行するため、per-kernel の commit + waitUntilCompleted (0.1〜1 ms 級の full round trip) が丸ごと消える。replay 全体で -13.7% (final)、12.5k full run は 241.41 → 219.51s で msplat 同日等価 gap は 1.44× → 1.31× に縮小。累計 (数学的同値の施策のみ) は 766.07 → 219.51s = -71.3%。expected gate 帯 -5〜15% (F.3 overlap 割引済) のほぼ上限で着弾し、F.3 (radix GPU scan) が単独敗北した『wait 除去』が、chain 全体の統合では大きく勝つことを示した — 部分 wait 除去と全 chain 統合の ROI 差は axis 3 (unified memory \u002F submission 論) の narrative 素材。次の律速は forward 30% (radix 18% 内数) \u002F chain GPU 26%。","\u002Ffindings\u002Fp2-w2-chained-submission\u002F",{"id":43,"title":701,"date":702,"status":10,"polarity":12,"category":703,"axes":704,"tags":705,"task_code":712,"related_runs":713,"delta_psnr":-1,"delta_wallclock":715,"rank":716,"verdict":717,"impact_summary":718,"detail_path":719},"Phase 5 step 30 — Instruments \u002F Metal System Trace 分析結果","2026-04-30","speed",[15],[706,707,708,709,25,710,711],"phase-5","step-30","instruments","metal-system-trace","profiling","fusion-reject","#5.30",[714],"phase5-step30","B-mini: -1% (noise floor)","mid","investigative","30s Metal System Trace で 14,909 encoder \u002F iter 40 encoder を観測。当初の「STIME 70% = sync overhead」解釈は B-mini プロト (scatter wait 削除、\u003C 1% 改善) で撤回。真の breakdown は GPU compute ~70% \u002F CPU encoding ~30%、dispatch fusion ROI は小さく Phase 4 後続 (C\u002FD\u002FF) 進行に戻る判断。","\u002Ffindings\u002Fphase5-step30-profile\u002F",1790227326539]