4 ms·

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 puttin

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.

int0x80 4y ago
There is __attribute__((aligned)) that some compilers provide (e.g. gcc, clang) but it's non-standard.
- prabhu-yu 4y ago
  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));
  - gpderetta 4y ago
    alignas(std::hardware_destructive_interference_size) is the portable solution.
    - prabhu-yu 4y ago
      Thank you for sharing this. I was not aware of this. But now agree, it is indeed portable solution.
- account42 4y ago
  alignas() has been standard for a decade now.
psurge 4y ago
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_destructive_interference_size 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.
- debugnik 4y ago
  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/ https://www.mono-project.com/news/2016/09/12/arm64-icache/

int0x80 4y ago

There is __attribute__((aligned)) that some compilers provide (e.g. gcc, clang) but it's non-standard.

prabhu-yu 4y ago
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));
- gpderetta 4y ago
  alignas(std::hardware_destructive_interference_size) is the portable solution.
  - prabhu-yu 4y ago
    Thank you for sharing this. I was not aware of this. But now agree, it is indeed portable solution.
account42 4y ago
alignas() has been standard for a decade now.

psurge 4y ago

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_destructive_interference_size 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.

debugnik 4y ago
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/ https://www.mono-project.com/news/2016/09/12/arm64-icache/