[shinaoka]

Stage 4 of tensor4all/threadteam-rs#6. faer stops extrapolating the team dispatch cost itself and reads threadteam's table, so the model exists in one place for every consumer.

Changes

• Removed utils::cost::team_section_cost and MEASURED_MAX_WIDTH (threadteam is the only parallel route: drop Par::Rayon, the spindle path and the Rayon cost model #97, provisional). threadteam now does the extrapolation:
  • 0.1.1 (cost: extrapolate WidthCosts linearly above the largest anchor; variable anchors (#6 stage 1); threadteam 0.1.1 threadteam-rs#7): WidthCosts grows linearly above a row's largest anchor; from_anchors accepts variable anchors.
  • 0.1.2 (cost: measured Zen2 team row for x86_64-avx2, anchors 2 to 64 (#6 stage 2); threadteam 0.1.2 threadteam-rs#8): a measured Zen2 team row for x86_64-avx2 at widths 2 to 64, from the 並列ゲートの dispatch cost が幅 6 で頭打ち、通れば常に全幅: p=32〜64 で floor 付近の region が過剰に開く #91 broccoli measurements.
• The four readers now ask threadteam:
  • ParShape::dispatch_cost reads DispatchCosts::cost(Team, w);
  • par_pays_time, team::kernel::kernel_width and the tiled team product's floor ask TeamExec::dispatch_cost(w).
• kernel_width searches from the full width down. It used to stop at the first width that did not pay, which assumed the cost never falls with the width. Measured rows do fall (aarch64-apple team 3.0 / 2.3 / 1.4 us), so a product that pays at 6 but not at 2 got no width.
• The kernel-width tests carry the kernel module's x86_64 cfg. The existing rising-row test was missing it too.
• threadteam = "0.1.2", so the resolver cannot pick 0.1.0, which is flat above 6. Cargo.lock changes threadteam only.
• Docs: a PATCHSET row, a worklog (docs/worklogs/2026-10-29-team-cost-from-threadteam.md), and a short update in docs/par-team-migration.md. The historical threadteam is the only parallel route: drop Par::Rayon, the spindle path and the Rayon cost model #97 worklog is left unchanged.

Gate decisions that change (by design)

row	before	after
generic (largest anchor at 6)	flat to width 8	linear from 7: width 8 is 4 us instead of 3 us, so a 10 us one-section region at width 8 now stays serial
x86_64-avx512 team	0.9 us at width 8	its measured width-8 anchor, 0.98 us
x86_64-avx2 (Zen2 row)	3 us at width 2, 3 * 64 / 8 = 24 us at width 64	1.42 us at width 2, 9.33 us at width 64: regions go parallel more readily on such hosts

Tests

• utils::cost::tests::the_team_cost_is_threadteams_table_at_every_width checks:
  • for five rows, the shape cost equals threadteam's table at widths 2 to 128;
  • above each row's largest anchor, the cost is cost(w_m) * w / w_m in integer ns, including width 128 on the Zen2 row;
  • a region that does not pay at 8 does not pay at 64.
• utils::team::tests::kernel_width_finds_the_widest_paying_width_on_a_falling_row.

Verification

• cargo test -p t4a-faer --lib: 520 passed. --doc: 63 passed. --lib utils:: after the last edit: 54 passed.
• cargo check -p t4a-faer for no-default, std, std,rayon, default and std,rayon,threadteam: no new warnings, and one fewer (MEASURED_MAX_WIDTH unused).
• Independent pre- and post-implementation reviews (gpt-6.1-sol) were done and their findings applied.

Not run: the adoption-protocol acceptance measurement

docs/adoption-protocol.md asks for a blast-radius acceptance run before merge. Here the blast radius is every family whose parallel gate reads the team cost: GEMM and the triangular products through kernel_width and the tiled floor, plus the factorizations and solves through ParShape and par_pays_time.

This change moves gate inputs, not kernels. Following the maintainer's rule against a long campaign per change, the run was not done; the maintainer decides before merge whether to run it.

Next

tcontract-exec and tlinalg lock updates follow this PR.

🤖 Generated with Claude Code

[shinaoka]

Before/after on broccoli: 1T and 16T are decision-neutral; 64T is not resolvable here

origin/main ddc55a0 against PR head b83f08d, gemm f64 256x4096x256 and qr_factor f64 1024 C,
1 / 16 / 64 threads, 3 process sets per cell with the arms alternating, harness prime 250 ms / 5 reps /
median, per-cell whole-L3-domain idle guard (EPYC 7702P, 64 cores Zen2, SMT off, boost 0, governor
performance).

Both arms link threadteam 0.1.2 (the harness's own lock already carries it), so the difference
measured here is faer's reading of the cost — the new row plus the deleted team_section_cost — and
not the library version. Harness: faer-benchmark 0e685d7 (after #37).

cell	T	order	main (3 sets)	PR (3 sets)	ratio
gemm 256x4096x256	1	C	21.20 (20.97/21.20/21.65)	20.99 (20.99/21.17/20.96)	1.010
gemm 256x4096x256	16	C	2.152 (2.14/2.18/2.15)	2.172 (2.17/2.17/2.19)	0.991
gemm 256x4096x256	16	F	2.166	2.167	0.999
qr_factor 1024	1	C	77.05 (77.84/76.88/77.05)	73.62 (73.31/73.62/73.70)	1.047
qr_factor 1024	1	F	63.98	64.20	0.997
qr_factor 1024	16	C	16.10 (16.28/16.06/16.10)	16.00 (16.00/15.69/16.18)	1.006
qr_factor 1024	16	F	14.03	14.03	1.000

A floor change shows up as "a region splits or it does not", so this is the answer that matters:
at 1T and at 16T none of these cells moves. The row decides the same thing as the extrapolation it
replaces on these shapes. (The 4.7% on qr_factor 1024 C at 1T is a per-arm offset that is
reproducible within each arm and absent in F order — one thread opens no region, so that is the
binary-layout noise floor, not a decision.)

64T: no verdict from this host. The cells are bimodal there in both arms: gemm F order is
1.12/1.11 ms in main and 6.28/1.12/5.11 ms in the PR (the PR's own three sets span 5.6x), and
qr_factor C is 18.03/17.52 against 16.01/37.58. The one pair worth a follow-up on a quiet machine is
qr_factor F 64T, where the two sets of each arm agree tightly and differ by 1.9x (main 25.23/29.14,
PR 14.21/13.97) — but the C order at the same budget disagrees, so I am not calling it a win. It is
the same per-process "the regions did not engage" mode I reported on #99 and #91
(16 participants run serially in a fresh process, ~3x), which makes a single-process 64T comparison
meaningless.