[mono] Regression of BigInteger.Multiply on arm64 AOT-llvm

[matouskozak]

Description

Mono runtime recorded regressions for BigInteger.Multiple dotnet/perf-autofiling-issues#24512 on arm64 AOT-llvm. The regressions are possibly caused by e733539 and isolated to Mono runtime (CoreCLR is unaffected).

Configuration

Linux arm64 AOT-llvm

Data

[ghost]

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

Issue Details

---

Description

Mono runtime recorded regressions for BigInteger.Multiple dotnet/perf-autofiling-issues#24512 on arm64 AOT-llvm. The regressions are possibly caused by e733539 and isolated to Mono runtime (CoreCLR is unaffected).

Configuration

Linux arm64 AOT-llvm

Data

Author:	matouskozak
Assignees:	-
Labels:	area-System.Numerics, tenet-performance, untriaged, needs-area-label
Milestone:	-

[jkotas]

cc @adamsitnik @kzrnm

[adamsitnik]

@jkotas as I wrote in dotnet/perf-autofiling-issues#24512 (comment), CoreCLR has improved on both arm64 and x64. The changes were relatively simple, I don't know what could have caused the regression only on Mono arm64.

[matouskozak]

We have seen improvements in Perf_BigInteger.Multiply(arguments: 65536,32768 bits) across the board: AOT-llvm arm64/x64, JIT x64 (we don't have arm64 JIT perf line), and x64 interpreter.

Perf_BigInteger.Multiply(arguments: 1024,512 bits) regressed mainly on AOT-llvm arm64. There was also a small regression for JIT x64 but the measurements don't seem to be too stable:

but no regressions were recorded for AOT-llvm x64.

[vargaz]

Can't reproduce this locally.

[matouskozak]

Can't reproduce this locally.

I can't reproduce it either on osx-arm64. I will try it on linux arm64 when I figure out how to do it

[steveisok]

/cc @lateralusX

[kotlarmilos]

Do we plan this for .NET 9+?

[tannergooding]

Multiple users cannot reproduce this (I can't either) and there are measured reproducible significant improvements that went along with the change (dotnet/perf-autofiling-issues#24513).

Please feel free to reopen if we feel this needs more in depth investigation, but as is I'm going to close this as "by design" given its likely some microarchitectural specific quirk and not something related to the S.Numerics implementation