Repository navigation
[Perf] Linux/arm64: 1 System.Numerics.Tests.Perf_BigInteger Regression on 2/4/2025 10:16:23 PM +00:00 #112664
Closed as not planned
Description
Run Information
| Name | Value |
|---|---|
| Architecture | arm64 |
| OS | ubuntu 22.04 |
| Queue | AmpereUbuntu |
| Baseline | dea928c98e6355c8dc6cd6e94ef5686000edca8d |
| Compare | ff604c23939bc59f856ef67f1f3d18dd685ff7a2 |
| Diff | Diff |
| Configs | CompilationMode:tiered, RunKind:micro |
Regressions in System.Numerics.Tests.Perf_BigInteger
| Benchmark | Baseline | Test | Test/Base | Test Quality | Edge Detector | Baseline IR | Compare IR | IR Ratio |
|---|---|---|---|---|---|---|---|---|
| 96.03 μs | 105.13 μs | 1.09 | 0.02 | False |
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 'System.Numerics.Tests.Perf_BigInteger*'Details
System.Numerics.Tests.Perf_BigInteger.ModPow(arguments: 1024,1024,64 bits)
ETL Files
Histogram
JIT Disasms
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
Activity
[-][Perf] Linux/arm64: 1 Regression on 2/4/2025 10:16:23 PM +00:00[/-][+][Perf] Linux/arm64: 1 System.Numerics.Tests.Perf_BigInteger Regression on 2/4/2025 10:16:23 PM +00:00[/+]dotnet-policy-service commentedon Feb 18, 2025
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
LoopedBard3 commentedon Feb 18, 2025
Caused by: #96895 and similar regression seen across a handful of configurations. There are already multiple and more linked improvements. Is this a good tradeoff, @tannergooding?
dotnet-policy-service commentedon Feb 19, 2025
Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.
tannergooding commentedon Feb 19, 2025
Yes. It was expected that a minor regression (about 9us here) would occur for some medium sized inputs in exchange for significantly faster large input handling.
We could possibly maintain both the old and new algorithm, switching between them based on the threshold, but I don't think we have the data to indicate that is worthwhile at this point in time.
CC. @kzrnm