How do `std::hardware_destructive_interference_size` and `std::hardware_constructive_interference_size` relate to L1 cache line size, and what are the implications for cross-platform code?

Understanding std::hardware_destructive_interference_size and std::hardware_constructive_interference_size

These constants were introduced in C 17 to provide a portable way to get the size of the L1 cache line. However, their relationship with cache line size is more subtle than that.

How are these constants related to the L1 cache line size?

In theory, these constants should be either equal to or greater than the L1 cache line size. This is because the destructive interference size is the minimum offset between two objects that are accessed by different threads to avoid false sharing, while the constructive interference size is the maximum size of two objects that can be placed together in memory to promote true sharing.

However, in practice, the values of these constants may not match the L1 cache line size exactly for several reasons. First, compilers may use heuristics or environmental hints to estimate the cache line size, which may not be accurate in all cases. Second, the cache line size may vary depending on the architecture of the specific machine where the code is executed.

Is there a good example that demonstrates their use cases?

False sharing occurs when two or more threads access different parts of the same cache line, causing the cache line to be invalidated and reloaded frequently. This can lead to significant performance degradation. To avoid false sharing, objects that are accessed by different threads should be placed at least one cache line apart in memory.

True sharing occurs when two or more threads access the same cache line, allowing the cache line to be loaded into the cache once and shared by all threads. This can lead to significant performance improvement. To promote true sharing, objects that are accessed by the same thread should be placed together in memory such that they fit within a single cache line.

Both are defined static constexpr. Is that not a problem if you build a binary and execute it on other machines with different cache line sizes? How can it protect against false sharing in that scenario when you are not certain on which machine your code will be running?

The static constexpr nature of these constants does pose a potential issue when running the code on different machines with different cache line sizes. As mentioned earlier, the values of these constants may not match the L1 cache line size exactly, which can lead to false sharing or missed opportunities for true sharing.

To mitigate this issue, you can define your own constants with specific cache line sizes for your target architecture. Alternatively, you can use the std::hardware_destructive_interference_size and std::hardware_constructive_interference_size constants as fallback values and check the actual cache line size at runtime using platform-specific methods.

The above is the detailed content of How do `std::hardware_destructive_interference_size` and `std::hardware_constructive_interference_size` relate to L1 cache line size, and what are the implications for cross-platform code?. For more information, please follow other related articles on the PHP Chinese website!