cost ゲートなしで全幅を渡す経路: 三角積の x86 カーネル、K==1 の rank_update、GEMM のセクション数過少計上

問題

cost ゲートを通らずに、caller の par.degree() を丸ごとカーネルや分割に渡している経路があります。小さな積でも p 全員の起床と barrier が起きるので、同期コストは p に比例します。

場所	内容	由来	危険度
`matmul/triangular.rs:733` (三角形出力の x86 カーネル)	`pays` は計算するものの (`:622`)、再帰経路でしか使わない。Rayon/Seq では `private_gemm_x86::gemm(.., par.degree())` をサイズによらず呼ぶ。Team 経路は `kernel_width` で判定している	upstream も無条件。PATCHSET 115 の floor 統一で取りこぼし	中
`matmul/mod.rs:1162-1190` (K == 1 の `rank_update`)	ゲートなしで列を p 分割。2×2 でも 64 分割になる	upstream 構造。fork は arm を `_` に広げて Team も通した	低〜中
native GEMM / `spicy_matmul` のセクション数	ゲートは 1 section と数える。カーネルは kc ブロックごとに pack と job queue の 2 セクションを回す (`2·⌈k/kc⌉`)	fork の floor (PATCHSET 101/114)	中 (子 issue「cost モデル」と合わせて計測)

確認済み (コード): 三角積と rank_update にゲートがないこと。GEMM ゲートの sections = 1。
推測: カーネル内のセクション数 (fork 版 t4a-private-gemm-x86 0.1.26 はローカルに無く、upstream 0.1.22 から推測)。三角積が Cholesky/LDLT の内側でどれだけ効くか。

llt / ldlt: f64/c64、n = 128/256/512。triangular::matmul の lower 出力: n = k = 64/128。いずれも 1/8/16/32/64T。
K = 1 の積: m = n = 64〜1024、1T と 64T を比較。

三角積、rank_update: 修正。三角積には matmul_imp と同じ pays_full(serial(n²k/2), 2) を入れる。rank_update には par_pays(m·n, rate, 1) を入れる。テスト 1 本と、上の計測で確認する。
GEMM のセクション数: 子 issue「cost モデル」の計測結果に合わせて直す。

親: #95

🤖 Generated with Claude Code

Folded into the umbrella #168 (parallel structure of the factorizations). This issue is re-scoped or closed against its items.