[transfix]

AsyncCalls.StepCostSetsTheDefaultRate checks that kDefaultAsyncStepsPerCpuMs stays within a factor of four of what a step costs in an optimized build. Since #844 made the evaluator faster, it fails. It failed on recipe / macos-latest / Release on #851 (run 40613165503): 2000 vs 2026.04. It also fails on the MSVC x64 build the default was measured on.

The default was set from steps costing 0.4 to 0.45 CPU µs (2,200 to 2,500 per CPU ms, rounded down to 2000). They now cost about a quarter of that, so the default is stale.

Measured

state_exec_async_calls_test --gtest_filter=AsyncCalls.StepCostSetsTheDefaultRate --gtest_repeat=N on master c0e0b5a, MSVC 19.44 Release, x64, 22 logical cores, 2026-10-28. Other jobs were loading the box, and the load varied between the three batches. Contention on a busy box makes a step cost more CPU time, so the busier batches read lower.

batch	box CPU load	async scheduler, steps per CPU ms	sync scheduler	default 2000 fails	default 8000 fails
1 (8 runs)	lightest	7,743 – 11,447 (most 9,700 – 11,400)	9,765 – 13,153	7 of 8	0 of 8
2 (30 runs)	~67%	3,889 – 9,231 (medians 6,000 – 6,250)	4,057 – 10,877	1 of 30	0 of 30
3 (30 runs)	~25–40%	5,888 – 10,378 (medians 8,200 – 8,500)	6,285 – 12,017	11 of 30	0 of 30

The macOS arm64 runner, from #851's failure log, measured 8,104 – 8,676 on both schedulers.

For batches 1 and 3, the "8000 fails" column is computed from the printed rates. With 8000 built in, the test passed 30 of 30 repeats.

The change

• kDefaultAsyncStepsPerCpuMs goes from 2000 to 8000. That is the async scheduler's measured range rounded down, the same rule that set 2000. 8000 is under the macOS runner's rates as well. The factor of four stays.
  • Margins at 8000: the test now fails only when a build's slowest program exceeds 32,000 steps per CPU ms, or its fastest drops below 2,000. The extremes measured were 8,313 for the slowest program and 5,196 for the fastest.
• The constant is repeated in pycvc.i, which is updated to match.
• Tests that hard-coded counts derived from 2000 now use the constant, with the same tolerances:
  • AS18/AS26: 0.2 CPU s;
  • AS21: under 30 CPU ms;
  • AS27: 50 CPU ms;
  • pycvc's sleeping-call test: under 50 CPU ms.
• Docs follow: STATE_EXEC_EXCEPTIONS.md (the rate's rationale, and the AS-18 and AS-27 rows), the developer guide and ARIADNE.md.

What it changes for hosts

An async call's CPU time now costs four times as many steps, which is again about what the same CPU time buys in DSL steps. Ariadne's 5000-step action cap now covers 0.625 ms of kernel CPU instead of 2.5 ms; since #844, 5000 DSL steps take about 0.5 ms. A host whose documents call CPU-heavy async verbs raises ariadne.limits.action_max_steps, as ARIADNE.md already says. The in-tree async verbs (nav_compute's nav-step, http-get-async) use far less than that.

The alternative was to widen the test's factor and keep 2000. That leaves async CPU charged at about a fifth of what DSL steps cost. If you'd rather keep the old charge and the Ariadne caps as they are, say so and I'll switch to that.

Tested

Locally, MSVC Release (no pycvc build here, so pycvc's tests run in CI):

suite	tests passed
state_exec_async_calls_test	46
state_exec_scheduler_test	165
ariadne_runtime_test	181
state_exec_exceptions_test	18
state_exec_gaps_test	94
state_exec_integration_test	104
state_exec_evaluator_test	48
state_exec_data_steps_test	35
state_exec_stdlib_test	28

• StepCost, AS18, AS21 and AS27 passed 30 of 30 repeats.
• clang-format 18.1.8 left the changed lines unchanged.