ASV daily benchmark check

Benchmark check 2026-07-27 (Dylan)

Catching the thread up across the weekend — covers Friday's hash-rewrite (posted about it here at the time, while Alain's out) plus today. One thing needs eyes; the rest is clean or expected.

Friday recap: ran the hash-rewrite across all three boundaries in one commit (0bf74a7a) — merged #3566 (a051c39a) + #3575 (38c44beb) + #3409 (44cb76b1, HeightfieldCollision). Mismatch count went to 0. KitchenG1 stayed hard-excluded (deliberate version="2" workload fix — the pre-v2 series accidentally skipped the kitchen scene, so the old numbers were the wrong ones), and NotifyDRLegs.time_notify_shape_properties was deferred (coherent boundary step, not enough post-change data to call). Both recorded as comments in replace_hash.sh so they don't get re-litigated.

:eyes: py3.13-only slowdown on both SC-PV machines from the 07-24 snapshot — this is the one to look at. Three unrelated benchmarks step up together and hold two points (07-24, 07-25):
- HeightfieldCollision.time_simulate +25–30% (SC-PV-02 0.084→0.105, SC-PV-10 0.079→0.103)
- FastInverseDynamics.time_eval_inverse_dynamics_force +30–35% (SC-PV-02 0.41→0.54, SC-PV-10 0.39→0.53)
- NotifyDRLegs.time_notify_shape_properties ~+53% (the deferred one, same boundary)
py3.12 is dead flat on the exact same newton commits — SC-PV-02 ran 19f8e33b on both envs, py3.12 unchanged and py3.13 stepped — and thor/orin are flat. So this is NOT a newton regression, it's the py3.13 virtualenv. asv isn't recording pinned deps in the result files so I can't name the package from the data; most likely a nightly wheel that refreshed in the py3.13 env on the SC-PV runners on 07-24. SC-PV-10 has shown this pair bimodal before (brief high mode on 07-17), so it may revert. Plan: watch the next 1–2 SC-PV py3.13 runs — if it holds, someone should diff what changed in the py3.13 venv on those runners on 07-24. Holding off #newton-dev until I have the revert/hold signal.

:white_check_mark: model_properties improvement confirmed — the mid-series drop I flagged is real and expected, not a glitch. NotifyDRLegs.time_notify_model_properties is ~4–8x faster on every reporting machine at the 07-22→07-23 boundary, bracket (fda8c48f, 9e85e577], Kamino cluster. #3606 (simplify Kamino gravity to alias Newton vectors) is the cause — aliasing instead of copying means less to push on a model-property notify. New metric, starts fresh, no merge decision.

:white_check_mark: hash-rewrite holding — sweep HASH MISMATCH count is 0 today, no residual. KitchenG1 still shows up as the top +2x flag in the sweep but that's the excluded v2 workload fix, not a regression.

:warning: machine health — L40S has gone quiet, last data 07-22 (now flagged at 4 days). orin also hasn't produced a new snapshot since 07-23. SC-PV-02/10 and thor are current through 07-25. GB10 still silent 33 days (last 06-23) — same standing issue, predates everything, separate.

:information_source: carry-overs, no action: CpuMuJoCoAnt orin creep is holding at +8% (3.82 at 07-23), no new orin data to move it — still watching, not classifiable yet. ContactPyramidDefaults orin is back at baseline (0.196), staying resolved. Minor new one: FastExampleCablePile +5% at the 07-23 boundary on both py envs + orin (thor flat) — cross-env so newton-side, low magnitude, just noting it.

@Viktor @Tobias — the new metric series (p95 step, realtime factor, steady-state GPU mem, solver niter) have fully landed and are stable; the appeared/hash churn from them will keep aging out over the next week. Reminder on the higher-is-better ones (realtime factor, steps/sec): the sweep reads a ratio <1 as an "improvement", so track the reciprocal — a drop in realtime factor is the regression direction, not a win.