You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"native" instruction set alias for AOT compilers #73246
Then compile that into jitinterface.dll (that ships with ILC) and p/invoke into this.
We already have managed definitions of the various flags this returns because the computed values are bitmasked with compile-time expectations burned into the produced executable to ensure we don't run on machines that don't have expected CPU features.
As a stretch goal, we might try to unify this detection with what's in CoreCLR VM, but that might be too much extra scope. Extracting something that would be eligible to be placed under src/native/minipal in the repo would be a very good first step towards that.
@JamesNK that makes sense, NativeAOT uses arm64 8.0 as a baseline while atomic instructions require 8.1, so you need to define lse capability for NativeAOT, e.g.: <IlcInstructionSet>lse</IlcInstructionSet> or
Activity
MichalStrehovsky commentedon Aug 3, 2022
I think the most maintainable way might be to extract the CPU flag detection from the runtime:
runtime/src/coreclr/nativeaot/Runtime/startup.cpp
Lines 162 to 305 in cdf21f1
Into a place that can be shared with the JitInterface native library:
https://github.com/dotnet/runtime/tree/cdf21f143735b8d104c8e636a37eb068904cdd8b/src/coreclr/tools/aot/jitinterface
Then compile that into jitinterface.dll (that ships with ILC) and p/invoke into this.
We already have managed definitions of the various flags this returns because the computed values are bitmasked with compile-time expectations burned into the produced executable to ensure we don't run on machines that don't have expected CPU features.
As a stretch goal, we might try to unify this detection with what's in CoreCLR VM, but that might be too much extra scope. Extracting something that would be eligible to be placed under src/native/minipal in the repo would be a very good first step towards that.
JamesNK commentedon Feb 21, 2023
Performance hit was noticed when testing Native AOT gRPC app on Linux ARM.
AOT vs CoreCLR:

Compared to a minor perf hit of AOT on Linux Intel:

Probably culprit is EventSource methods that use Interlocked to increment longs:
https://github.com/grpc/grpc-dotnet/blob/0b365bf4633c9f05d0af374ed8607c046e8e74dd/src/Grpc.AspNetCore.Server/Internal/GrpcEventSource.cs#L67-L75
EgorBo commentedon Feb 21, 2023
@JamesNK that makes sense, NativeAOT uses arm64 8.0 as a baseline while atomic instructions require 8.1, so you need to define
lsecapability for NativeAOT, e.g.:<IlcInstructionSet>lse</IlcInstructionSet>orfor crank
I think a while ago we discussed about a named instruction set for Azure (to include the baseline instructions)
JamesNK commentedon Feb 21, 2023
Yes, that fixed it.
Before: 239,492 RPS
After: 849,835 RPS
Also, only using Interlocked when required with this gRPC PR - grpc/grpc-dotnet#2052 - will improve performance in the benchmark.
omariom commentedon Mar 8, 2023
@JamesNK If the effect this large then may be the hottest counters should be placed on their own cache lines?
Add support for `--instruction-set:native`