Improve Arm64 Performance in .NET 10

kunalspathak commented 7 hours ago

We will continue to improve the code quality for Arm64 targets in .NET 10 to benefit our customers who run or wants to run their workload on Arm64 hardware.

General optimizations

PAC/RET feature enablement

[ ] Cobalt 100 hardware has pointer-authentication extension and as part of security measure, we would like to add the support in .NET 10, both for the .NET runtime as well as JIT code. More details can be found in https://github.com/dotnet/runtime/issues/109457

Compact encoding

[ ] Improve code quality by making use of instructions that do more than one operation and hence improve the encoding of Arm64. Also, as part of this work, we will revisit the addressing modes that are ignored or used less frequently (e.g. post-index addressing mode) but can give much better code quality. https://github.com/dotnet/runtime/issues/68028

Improvements in GC

[ ] Improve GC's vxsort algorithm to take advantage of NEON intrinsics. Related: https://github.com/dotnet/runtime/issues/108473
[ ] Modernize write barriers for Arm64: In various benchmarks, we have seen write barrier on arm64 is more time consuming that x86 counterpart. This is despite the fact that arm64 have conservative write-barrier (which does less work) instead of precise write barrier present in x86 (which does more work). The first step is to analyze the results from our experiments done in https://github.com/dotnet/runtime/issues/106051. Next step would be to see and enable precise write barrier for arm64. On x64, it showed significant wins in GC pause time and hence overall throughput. Another thing we want to explore is what happens when we have multiple versions of write-barrier similar to x86 and if we will give us any benefits.
- https://github.com/dotnet/runtime/pull/67389
- https://github.com/dotnet/runtime/pull/98485

Scalable Vector Extension

Wrap the non-streaming SVE work

[ ] Complete Pri1 issues found during .NET 9
[ ] Complete Pri2 issues found during .NET 9
[ ] Complete Pri3 issues found during .NET 9

Add support for vector length agnostic

The primary requirement before starting the design of streaming-mode SVE and SME would be to add support in JIT/.NET runtime for VL agnostic. This includes the following:

[ ] Introduce TYP_SIMD and educate various JIT code paths about the new type. See if some portion of this can be achievable on how we handle stackalloc.
[ ] Make sure getVectorTByteLength() returns VL that is available on the hardware and fix all the JIT code paths affected.
[ ] Sort locals such that TYP_SIMD / TYP_MASK are at the very last. They will be places at the bottom of the stack frame layout.
[ ] Access the stack offsets of TYP_SIMD / TYP_MASK using sve instructions
[ ] Enable non-streaming SVE for NativeAOT / crossgen with VL agnostic.

Reference: https://github.com/dotnet/runtime/issues/101477

Design streaming mode SVE and SME

Come up with API design of streaming-mode SVE and SME and its interaction with non-streaming APIs as well as NEON APIs.
Implication of the streaming modes switch on overall .NET runtime executing process
Handling of diagnostics and debugging during streaming mode
NativeAOT and crossgen support in presence of streaming mode flag toggles
How faults and exceptions will be handled, and how the state restore will happen.
Handling of ZA storage register in LSRA
Stretch
[ ] Use Arm intrinsics in more places in BCL
[ ] https://github.com/dotnet/runtime/issues/35274
[ ] Some of the unimportant SVE issues in Pri2 and Pri3 will be done if time permits
[ ] Implement the approved non-streaming SVE2 APIs
[ ] Prototype streaming mode SVE and SME design on M4 (if available)

References:

kunalspathak commented 7 hours ago

@dotnet/arm64-contrib @dotnet/jit-contrib

JulieLeeMSFT commented 6 hours ago

Improvements in GC

CC @mangod9.

dotnet-policy-service[bot] commented 6 hours ago

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch See info in area-owners.md if you want to be subscribed.

dotnet / runtime