4 ms·

It does sort of bring up the general question of why this is a compile time and not runtime constant. I doubt x86 will double its cache-line size any time soon,

It does sort of bring up the general question of why this is a compile time and not runtime constant. I doubt x86 will double its cache-line size any time soon, but if it did -- and people are running binaries with cache-padding at 64-bytes -- expected behaviour is going to differ. Not in a way that's going to make anybody lose their minds, mind you, but this kind of micro-optimization will just cease to be effective. EDIT: naturally I understand that compile makes sense for e.g. statically sizing array sizes etc.

jeffbee 3y ago
> I doubt x86 will double its cache-line size any time soon Well, why not? They doubled it from 32B to 64B between the Pentium III and Pentium IV.
- cmrdporcupine 3y ago
  I don't know enough about CPU design to say really but Pentium IV is a long time ago now. And since then, I suspect that a lot of assumptions about 64B line sizes have been baked in. Apple could go to 128 because they were rolling out a whole new ISA, so were breaking compat anyways. That said, they have amazing performance on the M1, and I wonder how much of that has to do with the wider L1 size.
aw1621107 3y ago
Raymond Chen discussed that in a relatively recent blog post [0]. The main points are that those constants are typically used to influence struct layouts/alignments, and those must be decided at compile time. The alternative is to generate multiple versions of a struct/other code with different alignments/layouts and choose among them at runtime, but that comes with other tradeoffs. [0]: https://devblogs.microsoft.com/oldnewthing/20230424-00/?p=108085 https://devblogs.microsoft.com/oldnewthing/20230424-00/?p=10...
gpderetta 3y ago
99% of the time {constructive,destructive}_interference_size is used as a parameter to alignas, which necessarily takes a constant value. It would simply replace a lot of const size_t cache_size = 64 from user code making it slightly moreportable. Having a runtime value can be sometimes useful but it is beyond the scope of the feature. C++11 std::atomic had similar scope creep where it had atomic::is_lock_free as a runtime parameter. Nobody ever used it as is simply not something you care at runtime. So C++17 added is_always_lock_free as a compile time query which can be actually actionable.

jeffbee 3y ago

> I doubt x86 will double its cache-line size any time soon Well, why not? They doubled it from 32B to 64B between the Pentium III and Pentium IV.

cmrdporcupine 3y ago
I don't know enough about CPU design to say really but Pentium IV is a long time ago now. And since then, I suspect that a lot of assumptions about 64B line sizes have been baked in. Apple could go to 128 because they were rolling out a whole new ISA, so were breaking compat anyways. That said, they have amazing performance on the M1, and I wonder how much of that has to do with the wider L1 size.

aw1621107 3y ago

Raymond Chen discussed that in a relatively recent blog post [0]. The main points are that those constants are typically used to influence struct layouts/alignments, and those must be decided at compile time. The alternative is to generate multiple versions of a struct/other code with different alignments/layouts and choose among them at runtime, but that comes with other tradeoffs. [0]: https://devblogs.microsoft.com/oldnewthing/20230424-00/?p=108085 https://devblogs.microsoft.com/oldnewthing/20230424-00/?p=10...

gpderetta 3y ago

99% of the time {constructive,destructive}_interference_size is used as a parameter to alignas, which necessarily takes a constant value. It would simply replace a lot of const size_t cache_size = 64 from user code making it slightly moreportable. Having a runtime value can be sometimes useful but it is beyond the scope of the feature. C++11 std::atomic had similar scope creep where it had atomic::is_lock_free as a runtime parameter. Nobody ever used it as is simply not something you care at runtime. So C++17 added is_always_lock_free as a compile time query which can be actually actionable.