News for hackers. Stuff that matters.
Re:Cache invalidation is one of the hardest problems in comp... by prabhu-yu on Sunday November 27, 2022 @02:11AM (#33761086)
In the fix, they have padded. instead of padding, do we have compiler directive, that forces the a variable starting using a fresh cache line (instead of putting it in the last cache line?)

Reason I am asking this, it will make the fix independent of the architecture of cache lines, size of cache lines.

Also, the compiler directive/annotation would help developer to use it more liberally when they think, false sharing can happen.

Re:Cache invalidation is one of the hardest problems in comp... by int0x80 on Sunday November 27, 2022 @02:23AM (#33761144)
There is __attribute__((aligned)) that some compilers provide (e.g. gcc, clang) but it's non-standard.
Re:Cache invalidation is one of the hardest problems in comp... by prabhu-yu on Sunday November 27, 2022 @02:51AM (#33761255)
Thank you for the respone.

Can we write like this? Klass ssc __attribute__((64));

This could convey more info than padding.

Further, I wish, gcc could have provided an attribute that explicitly forces for the cache line alignment than just generic alignment. Generic scalar type alignment is not same as the cache line alignment.

Example: Klass sc __attribute__((start_at_cache_line));

Re:Cache invalidation is one of the hardest problems in comp... by gpderetta on Sunday November 27, 2022 @04:10AM (#33761583)
alignas(std::hardware_destructive_interference_size) is the portable solution.
Re:Cache invalidation is one of the hardest problems in comp... by prabhu-yu on Sunday November 27, 2022 @07:21PM (#33768421)
Thank you for sharing this. I was not aware of this. But now agree, it is indeed portable solution.
Re:Cache invalidation is one of the hardest problems in comp... by account42 on Monday November 28, 2022 @08:58AM (#33773692)
alignas() has been standard for a decade now.
Re:Cache invalidation is one of the hardest problems in comp... by psurge on Sunday November 27, 2022 @03:05AM (#33761314)
C++17 has std::hardware_destructive_interference_size which you can use in conjunction with alignas to get this behavior, see https://en.cppreference.com/w/cpp/thread/hardware_destructiv...

I’m not sure whether a single target architecture can (either in theory or in practice) map to hardware with different line sizes. If so, another problem is that the compiler’s idea of the cache line size might not match the hardware’s.

Re:Cache invalidation is one of the hardest problems in comp... by debugnik on Sunday November 27, 2022 @06:58AM (#33762357)
AArch64 processors are available with 64 and 128 byte cache lines, and big.LITTLE processors may report different icache line sizes on different cores[1], so a single thread can even be rescheduled across different icache line sizes (no idea about dcache).

[1]: https://www.mono-project.com/news/2016/09/12/arm64-icache/