[Perf] Linux/x64: 3 Regressions on 8/24/2026 9:02:58 AM +00:00

[performanceautofiler]

Run Information

Name	Value
Architecture	x64
OS	ubuntu 22.04
Queue	ViperUbuntu
Baseline	64a29867c5c5c8e0babc9e31313cf3b6e50f0193
Compare	c545c4e3f9e2ebc10c6b3e2626187e18569adcf2
Diff	Diff
Configs	CompilationMode:tiered, RunKind:bepuphysics

Regressions in DemoBenchmarks.TwoBodyConstraintBenchmarks

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio
AngularHinge - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	97.12 μs	119.64 μs	1.23	0.00	True
Contact4Nonconvex - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	490.66 μs	561.04 μs	1.14	0.00	True
DistanceServo - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	82.95 μs	94.54 μs	1.14	0.00	True

Test Report

Repro

General Docs link: https://github.com/dotnet/performance/blob/main/docs/benchmarking-workflow-dotnet-runtime.md

git clone https://github.com/dotnet/performance.git
python3 .\performance\scripts\benchmarks_ci.py -f net8.0 --filter 'DemoBenchmarks.TwoBodyConstraintBenchmarks*'

Details

DemoBenchmarks.TwoBodyConstraintBenchmarks.AngularHinge

ETL Files

Histogram

JIT Disasms

DemoBenchmarks.TwoBodyConstraintBenchmarks.Contact4Nonconvex

ETL Files

Histogram

JIT Disasms

DemoBenchmarks.TwoBodyConstraintBenchmarks.DistanceServo

ETL Files

Histogram

JIT Disasms

Docs

Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository

[LoopedBard3]

🔍 Automated Triage Analysis

Summary: Of the 3 reported bepuphysics regressions, only Contact4Nonconvex (+14.35%, z=2.86) is a genuine regression; the historical series shows a progressive upward drift (early ~479k ns → recent ~512k ns → compare ~561k ns) rather than a single-commit step change. The other two tests (AngularHinge +23.19%, DistanceServo +13.97%) are measurement noise from persistently bimodal series (both deltas fall below their adaptive thresholds with z<0.6). No commit attribution is possible: the build repo i Bisection skipped — autofile run configuration is not supported by the bisection harness.

Finding Confidence: 4/5 (analysis accuracy)
Regression Confidence: 3/5 (likelihood of true regression)

🤖 Proposed Next Actions: Uncertain — flag for re-triage — 1 done, 1 dry-run (rule R5_look_again — see Full Analysis for the table). · 🦆 Re-analysis: ⚠️ disputes (weak-bisection-evidence, bimodal-history, possible-noise)

📊 Full Analysis (click to expand)

Summary: Of the 3 reported bepuphysics regressions, only Contact4Nonconvex (+14.35%, z=2.86) is a genuine regression; the historical series shows a progressive upward drift (early ~479k ns → recent ~512k ns → compare ~561k ns) rather than a single-commit step change. The other two tests (AngularHinge +23.19%, DistanceServo +13.97%) are measurement noise from persistently bimodal series (both deltas fall below their adaptive thresholds with z<0.6). No commit attribution is possible: the build repo is dotnet/sdk (branch 11.0) and its baseline→compare SHAs are not resolvable through the GitHub compare API. Finding confidence 4/5 (300 historical runs), regression confidence 3/5 (strong z-score but drift pattern and no attributable commit).

Issue Overview

• Issue: #78337 - [Perf] Linux/x64: 3 Regressions on 8/24/2026 9:02:58 AM +00:00
• Date: 2026-08-24 | Queue: ViperUbuntu (Ubuntu.2204.Amd64.Viper.Perf) | OS/Arch: ubuntu 22.04/x64
• Commits: 64a29867 → c545c4e3 (range not resolvable via compare API)
• Labels: untriaged, perf-regression, arch-x64, os-linux, runtime-coreclr, kind-bepuphysics, branch-11.0, compilationmode-tiered, runkind-bepuphysics
• Runtime stack: Desktop + CoreCLR (implicit; build repo dotnet/sdk 11.0, CoreClr=true, tiered compilation)
• Historical Data: Available (300 prior runs per test)

Test Analysis

Test Name	Baseline	Compare	Δ%	μ	σ	n	z	Thresh%	Noise?	Assessment
Contact4Nonconvex	490.66 μs	561.04 μs	+14.35%	495.23 μs	23.01 μs	300	2.86	9.29%	N	Drift (progressive slowdown), CV=4.6%
AngularHinge	97.12 μs	119.64 μs	+23.19%	111.55 μs	14.35 μs	300	0.564	25.73%	Y	Within variance; bimodal series (~97k/~120k), CV=12.9%
DistanceServo	82.95 μs	94.54 μs	+13.97%	89.62 μs	8.23 μs	300	0.599	18.36%	Y	Within variance; bimodal series (~83k/~91–110k), CV=9.2%

Legend: μ=mean, σ=stddev, n=runs, z=z-score, Thresh%=adaptive threshold

Finding Confidence: 4/5 - 300 historical runs per test (well above minimum), classifications backed by reliable z-scores. Slight caveat: afterCount=0 (compare value is the final chronological entry, no isolated post-change series), and the two noise series are visibly bimodal, inflating stddev/thresholds.

Candidate Stack Relevance

Commit-level candidate classification is not possible for this issue. The autofile RunType.BuildRepo is dotnet/sdk (branch 11.0), and the baseline (64a29867) → compare (c545c4e3) SHAs cannot be resolved: GetCommitRangeSummary, GetCommitRangeHashes, and GetSingleCommitSummary all return "Comparison not found" / "No commit found" against the public dotnet/sdk repo (these appear to be internal build-graph SHAs, not public product commits). No changed-path data is available to classify any candidate as Relevant / Shared / LessLikely.

Commit	Touched Paths (summary)	Relevance	Notes
n/a	(range not resolvable via GitHub compare API)	Unknown	SDK 11.0 build SHAs not present in public dotnet/sdk; no diff obtainable

Confirmed Regressions

DemoBenchmarks.TwoBodyConstraintBenchmarks.Contact4Nonconvex (+14.35%)

• Delta: 490.66 μs → 561.04 μs (+14.35%)
• Historical Context: μ=495.23 μs (σ=23.01 μs, n=300); z-score=2.86; adaptive threshold=9.29%; CV=4.6%
• Assessment: Gradual drift / progressive slowdown. earlyBeforeMean ~479k ns → recentBeforeMean ~512k ns → compare ~561k ns. The compare value accelerates beyond the already-elevated recent trend rather than a clean single-build step.
• Finding Confidence: 4/5 - 300 runs, moderately stable series (CV=4.6%), z-score reliable.
• Regression Confidence: 3/5 - Δ exceeds adaptive threshold and z=2.86 ≥ 2 (strong statistical signal), but the change is a drift, not a step, and no attributable commit is available (SDK build range unresolvable). Capped at 3/5 pending isolation.
• Likely Cause: No clear attribution. The dotnet/sdk 11.0 baseline→compare range is not resolvable, so no commit diff could be inspected. The drift pattern further suggests the slowdown accumulated across multiple builds rather than a single culprit commit.
  • Affected Areas: Physics constraint solve (SIMD Vector<float> heavy, bepuphysics2 Contact4Nonconvex prestep/warmstart/solve path) — see benchmark source. Given the CoreCLR/tiered stack, a likely-affected component would be JIT codegen for hardware-accelerated SIMD, but this is unverified.
  • Stack Relevance: Unknown (no diff available to classify)
  • Rationale: The benchmark is a tight SIMD-vectorized two-body contact constraint solve; regressions here typically track JIT/codegen or vectorization changes. However, because the SDK build range cannot be resolved and the series is drifting, no specific commit can be named. Corroboration across the sibling tests is weak — the other two constraint benchmarks in the same run are classified as noise.
  • Candidates Considered: none obtainable (commit range not resolvable via compare API)
• Verification Status: Not verified. RunWithBuildAtHash reproduction was not attempted because the SDK build SHAs are not present in the runtime build graph reachable by the Helix repro tooling; a bisect target range could not be constructed.

Open Questions

• Historical Data: Available and sufficient (300 runs/test), but afterCount=0 — no isolated post-change series to confirm the new level persists.
• Confidence Limitations: Commit range for dotnet/sdk 11.0 is not resolvable (compare API returns "not found"), so root-cause attribution is impossible with current tooling. Two of three tests are bimodal, complicating any future delta interpretation.
• Verification Needed: Isolated rerun / bisection of the true underlying dotnet/runtime (or SDK-embedded runtime) commit range corresponding to this SDK build window; source/codegen review of SIMD constraint solve.
• Bisection Status: Not performed (unable to enumerate commits — range unresolvable).

Recommended Actions

1. Confirm reproducibility - Rerun DemoBenchmarks.TwoBodyConstraintBenchmarks.Contact4Nonconvex on baseline and compare builds to verify the +14.35% delta is stable and not part of the ongoing drift, before committing effort to root-cause.
2. Resolve the true commit range - Map the dotnet/sdk 11.0 build SHAs (64a29867 → c545c4e3) to the underlying runtime commit range so a diff and bisection target can be built; the public compare API does not resolve these SHAs.
3. Bisect the underlying runtime range - Once the real commit range is known, bisect recent Ubuntu.2204.Amd64.Viper.Perf builds to isolate the progressive slowdown; given the drift, look for an accumulation across multiple commits rather than one step.
4. Treat AngularHinge and DistanceServo as noise - Both are bimodal; investigate whether the measurement infrastructure produces two execution modes (CPU frequency states / NUMA) before attributing any future delta to code.

🤖 Proposed Next Actions

Rule: R5_look_again — Uncertain — flag for re-triage.

Regression confidence 3/5 is below the required 4/5. Revisit once more historical data is available.

#	Action	Status	Details
1	Add label	✅ Done	Look Again
2	Remove label	⏭️ Skipped (dry-run)	untriaged

🦆 Re-analysis (advisory)

⚠️ Disputes the analysis — advisory only, not applied

Flags: weak-bisection-evidence, bimodal-history, possible-noise

Rationale: Bisection was skipped for all benchmarks and no culprit converged, while bimodal history is flagged, so the 3/5 regression confidence on Contact4Nonconvex is unsupported and should be lowered. No culprit was proposed, so there is nothing to dispute there, and the finding confidence is defensible.

Suggested confidence: Change Confidence → 2/5 (advisory — not applied)

This critique is advisory in the current configuration and did not change the confidences, culprit, or proposed actions above.

---

Generated by PerfTriageAgent on 2026-08-24 09:07 UTC