deploy.

App/wwwroot/HiAPI-docsite/release-note/upgrading-to-3.2/performance-and-footprint.html

@@ -91,6 +91,23 @@
 correctness that is said too. Read the ratios rather than the absolute times: several campaigns were
 run on Debug builds or on small machines, deliberately, because a paired A/B on one machine answers
 &ldquo;did this get faster&rdquo; far more reliably than an unpaired Release number on a fast one.</p>
+<h2 id="against-the-last-31-set">Against the last 3.1 set</h2>
+<p>Paired on one 32-logical-processor Linux workstation, deployed stacks, <strong>whole</strong> NC programs, steps per
+second. The 3.1 side is HardNc (the 3.1 default); the 3.2 side is SoftNc (the 3.2 default). Throughput
+on this line is <strong>2.5×–18.8×</strong>; the ratio grows with program length and mesh fineness. Memory is mixed:
+a cutting-dominated long program peaked higher on 3.2, a large-surface short-NC job peaked lower.</p>
+<p>The six-core ceiling that used to cap the 3.1 pipeline is <strong>not</strong> where that gap comes from. On the
+same workstation, pinning 3.2's worker counts to the products of that ceiling moved a ~193,000-step
+play from 15.0 s to 15.9 s (+6%); at six available cores the version advantage is still 2.8×–3.8×,
+and at two cores 2.73×. 3.1 saturates from eight cores; 3.2 from twelve. On that fixture, 3.1 allocated
+6–8× more managed memory, and the 3.1 allocation climbed as the mesh got finer while 3.2 stayed
+almost flat.</p>
+<blockquote>
+<p><strong>Conditions.</strong> Deployed x64 stacks, one machine, whole programs, steps/s (not wall-clock — a
+defect that inflated 3.2 step counts on an earlier drop is fixed on this line). Core-count figures
+used <code>DOTNET_PROCESSOR_COUNT</code> plus CPU affinity, so they are &ldquo;restricted cores on a large machine&rdquo;,
+not a small one: memory bandwidth and cache stay those of the 32-LP host.</p>
+</blockquote>
 <h2 id="milling-physics-in-the-native-kernel">Milling physics in the native kernel</h2>
 <p>The per-step physics moved into <code>core.dll</code> in stages — engagement scan conversion, the force kernel,
 then the sequential temperature and wear chain. Measured as a same-day paired A/B, managed leg
@@ -166,11 +183,11 @@ parallel physics stage is about 3.3% of wall time</strong>, while the <strong>si
 about 77%</strong> — and that subtraction is single-worker as a correctness requirement, not as an
 oversight. Raising the force-worker count therefore buys nothing on any machine; the bottleneck
 moved rather than disappearing.</p>
-<p>What did change in the worker derivation is narrower than it sounds. An unmeasured six-core ceiling
-was removed, but it only ever governed the sweep workers, and only machines with <strong>nine or more
-logical processors</strong> see a different count; force workers are unchanged everywhere. The throughput
-benefit on such a machine has <strong>not</strong> been measured — the development machines are smaller — so this
-is a ceiling removal, not a claimed speedup.</p>
+<p>What did change in the worker derivation is narrower than it sounds. The six-core ceiling
+was removed, and on a 32-logical-processor machine that is about <strong>6%</strong> of the 3.1→3.2 wall-time gap
+measured above — force workers are unchanged everywhere, and the sweep-worker count only differs on
+machines with <strong>nine or more</strong> logical processors. The rest of the gap is allocation and the rest of
+the pipeline, not the extra cores.</p>
 <p>Queue depths became fixed item budgets (120 geometry, 3840 physics) rather than scaling with the core
 count, because those queues bound per-item memory: uncapped, a 64-core machine would have been handed
 40,960-deep physics queues. On machines with fewer than six cores this is a small <em>increase</em> in