Enable a faster mod/GetCurrentProcessorId

[benaadams]

Ensure GetCurrentProcessorId() is in range 0 - ProcCount as with #27543 ProcCount is now a stable value.

In TimerQueueTimer use GetCurrentProcessorId() directly as it no longer needs mod.

In TlsOverPerCoreLockedStacksArrayPool use a pattern that can be elided by Tier1 Jitting and skip mod if ProcCount < 64

Originally I was aiming to use FastMod; however I realised the Jit would do it itself at Tier1 as the readonly statics would become consts

/cc @stephentoub @jkotas @VSadov

[jkotas]

Any performance numbers?

[benaadams]

Moved GetCurrentProcessorId to shared as Mono is currently just

public static int GetCurrentProcessorId()
{
    // TODO: Implement correctly
    return Environment.CurrentManagedThreadId;
}

So the change it would need is dropping that method and adding

public static int GetCurrentProcessorNumber()
{
    // TODO: Implement correctly
    return -1;
}

And it will pickup the benefit from the caching of the mod value /cc @filipnavara @marek-safar

[VSadov]

I believe in a VM proc Id could be above ProcessorCount. Do we care?

[benaadams]

Do you as to whether its accurate vs in range 0-ProcCount?

The first means a mod is needed for each use; the second a mod every 5000 calls.

[VSadov]

Another concern is - is this cheap? The number of cores could be pretty odd nowdays.
I generally round up the number of stripes to the next ^2 - so that I could use binary masking which is much cheaper.

In that case some slots may not be used due to the oddness of the proc number (or due to affinity), but that is never a big deal.

[benaadams]

Also the mod will be changed to not be a mod at Tier1 as the divisor will be a constant.

[jkotas]

the second a mod every 5000 calls.

@VSadov has done a number of experiments around this and we believe that this limit should be <50.

On more recent hardware, none of this TLS caching should be needed and this should just call RDPID instruction that is both fastest and most accurate.

[benaadams]

If the exact coreid is important over an in range value it would be better to expose RDPID or similar via intrinsics to expose that? Then you can check the .IsSupported flags, do something different for Arm vs Intel etc

[jkotas]

CurrentProcessorId is platform neutral concept. I do not think we need to have yet another set of hardware intrinsics for it.

it also currently adds 100 to it

I would be ok with dropping this and making this API to return the underlying Processor ID.

[benaadams]

I'm happy to push the mod bypasses out into the callsites rather than in GetCurrentProcessorId

CurrentProcessorId is platform neutral concept.

However, my point is it doesn't return a platform neutral value; its platform specific

[VSadov]

I think we could drop the +100 part.
It is not a big problem for reducer though. Until you have 100+ cores in the system any method of reducing - modding, masking, hashing, should work the same.
After 100+ cores, yes, it could be a bit of a problem for those who use masking.

[benaadams]

Just changed the call sites in #27600 if that is preferred?

[filipnavara]

Good catch with the missing Mono implementation. I will look into it.

[benaadams]

Good catch with the missing Mono implementation.

It returns -1 for some Unixes also; this change means Mono will have the same caching behaviour as coreclr

[benaadams]

Using #27600 in preference