https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116662
--- Comment #7 from Levi Zim <rsworktech at outlook dot com> --- (In reply to Xi Ruoyao from comment #6) > cppreference is not the standard. The standard never says > hardware_destructive_interference_size means this. > > Instead it says: > > This number is the minimum recommended offset between two > concurrently-accessed objects to avoid additional performance degradation > due to contention introduced by the implementation. It shall be at least > alignof(max_align_t). > > To me "recommended" means the value is not needed to be strictly matching > the hardware property. And the original paper > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0154r1.html > clearly says: > > Destructive interference size: a number that’s suitable as an offset between > two objects to likely avoid false-sharing due to different runtime access > patterns from different threads. > > Note the word "likely" directly contradicts from your suggestion using the > maximum value. If we have 100 CPUs with 32B, 250 CPUs with 64B, and 10 CPUs > with 128B, by "likely" we should use 64B, but the maximum is 128B. Thanks for your excellent explanation! Then most of the riscv64 CPUs I know have a cache line size of 64B. Would gcc update the value to 64B?
