[Mono][Perf][AOT] Regressions in BigInteger benchmarks.

[naricc]

I am seeing regressions in several BigInteger benchmarks, in mono-aot that seem to be related to this change: 22b516c

@sakno @gfoidl Any ideas?

Automated issue below.

Run Information

Architecture	x64
OS	ubuntu 18.04
Baseline	cc7f2f9c1a80c262055757331acca25d2748d381
Compare	ce4eb48eb8950e3a1454149af14318494a1ca95e
Diff	Diff

Regressions in System.Numerics.Tests.Perf_BigInteger

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio	Baseline ETL	Compare ETL
ModPow - Duration of single invocation	2.91 ms	4.14 ms	1.42	0.01	True
Add - Duration of single invocation	21.64 ns	30.60 ns	1.41	0.01	True
Divide - Duration of single invocation	19.88 ns	22.10 ns	1.11	0.04	True

Test Report

Repro

git clone https://github.com/dotnet/performance.git
python3 .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Numerics.Tests.Perf_BigInteger*'

Payloads

Baseline
Compare

Histogram

System.Numerics.Tests.Perf_BigInteger.ModPow(arguments: 16384,16384,64 bits)

System.Numerics.Tests.Perf_BigInteger.Add(arguments: 16,16 bits)

System.Numerics.Tests.Perf_BigInteger.Divide(arguments: 16,8 bits)

Docs

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

[ghost]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I am seeing regressions in several BigInteger benchmarks, in mono-aot that seem to be related to this change: 22b516c

@sakno @gfoidl Any ideas?

Automated issue below.

Run Information

Architecture	x64
OS	ubuntu 18.04
Baseline	cc7f2f9c1a80c262055757331acca25d2748d381
Compare	ce4eb48eb8950e3a1454149af14318494a1ca95e
Diff	Diff

Regressions in System.Numerics.Tests.Perf_BigInteger

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio	Baseline ETL	Compare ETL
ModPow - Duration of single invocation	2.91 ms	4.14 ms	1.42	0.01	True
Add - Duration of single invocation	21.64 ns	30.60 ns	1.41	0.01	True
Divide - Duration of single invocation	19.88 ns	22.10 ns	1.11	0.04	True

Test Report

Repro

git clone https://github.com/dotnet/performance.git
python3 .\performance\scripts\benchmarks_ci.py -f net6.0 --filter 'System.Numerics.Tests.Perf_BigInteger*'

Payloads

Baseline
Compare

Histogram

System.Numerics.Tests.Perf_BigInteger.ModPow(arguments: 16384,16384,64 bits)

System.Numerics.Tests.Perf_BigInteger.Add(arguments: 16,16 bits)

System.Numerics.Tests.Perf_BigInteger.Divide(arguments: 16,8 bits)

Docs

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

Author:	naricc
Assignees:	-
Labels:	area-System.Numerics, untriaged
Milestone:	-

[naricc]

Also effecting these sets of benchmarks:

dotnet/perf-autofiling-issues#2195
dotnet/perf-autofiling-issues#2064

[sakno]

@naricc , see comment from @jeffhandley here: #60293.

[naricc]

@jeffhandley So it looks like the decision for CoreCLR was basically that this was an acceptable trade-off? I don't see any reason it should be acceptable in mono too, and will close the issue if that is the conclusion.

@SamMonoRT

[jeffhandley]

From the CoreCLR side, yes, we did think these were acceptable trade-offs. We can close this. Thanks, @naricc.