API for fetching Cache Line size for current CPU architecture

[JakeYallop]

I was looking at #131696

From the comment in code the PR:

64 is the size of a cache line on many systems; larger ones may see a little more false sharing.

I think there may have been discussions in the past about this. I've found this: https://lemire.me/blog/2023/12/12/measuring-the-size-of-the-cache-line-empirically/ that suggests that at least M2 chips (and likely, M-series chips) have a cache line of 128 bytes.

If this differing cache line size is going to start cropping up, does it suggest the need for an API to retrieve this value?

There seems to be quite a few hits: https://github.com/search?q=%2F%28CacheLine%7CCACHE_LINE%7Ccache+line%29%2F+language%3AC%23+&type=code

I know that the runtime already has its own internal constant.

For this hypothetical API to be useful, it would need to adjust the value it returns based on the architecture its running on.

This is just a discussion instead of a concrete API proposal right now.

[dotnet-policy-service]

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

[dotnet-policy-service]

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

[EgorBo]

I think there may have been discussions in the past about this. I've found this: https://lemire.me/blog/2023/12/12/measuring-the-size-of-the-cache-line-empirically/ that suggests that at least M2 chips (and likely, M-series chips) have a cache line of 128 bytes.

I think most modern arm64 server hardware (where high contention typically occurs) uses a 64-byte cache line (e.g., all Cobalt and Graviton chips), so it's safe to use 64B if you suspect 128B is too wasteful. Apple hardware typically uses 128B, but I'm not sure how often users encounter high contention scenarios on those machines.

For this hypothetical API to be useful, it would need to adjust the value it returns based on the architecture its running on.

I don't think such an API would be useful. It has to be a compile time constant to be used for FieldOffset/ExplicitLayout.

PS: In fact, I think we should change CACHE_LINE_SIZE = 128; to 64 in BCL, because for AnyCPU libraries we add extra padding not only for Cobalt/Graviton where it makes no sense, but also for all x64.

[timcassell]

#108416 Is related to this (and this is one of the motivating scenarios).

[JakeYallop]

It has to be a compile time constant to be used for FieldOffset/ExplicitLayout

Yes - that would definitely complicate any potential solution.

[tannergooding]

Some System.Runtime.InteropServices.CachePadded<T> (with more thought on a good name) would be significantly better than FieldOffset or the like and would work in all scenarios. It is also significantly cheaper to implement (in contrast to special support for magic constants, other attribute constants, etc), doesn't pessimize layout, doesn't alias fields, etc

Such a type is a handful of lines of code to support, even for transparent handling with interop as we already have that support, with the "hardest" part being the querying of the cache line size.