Add a hardware_destructive_interference_size const to the standard library

[strega-nil]

http://www.eelis.net/c++draft/hardware.interference

constexpr size_t hardware_destructive_interference_size = implementation-defined;

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

struct keep_apart {
  alignas(hardware_destructive_interference_size) atomic<int> cat;
  alignas(hardware_destructive_interference_size) atomic<int> dog;
};

constexpr size_t hardware_constructive_interference_size = implementation-defined;

This number is the maximum recommended size of contiguous memory occupied by two objects accessed with temporal locality by concurrent threads. It shall be at least alignof(max_align_t).

struct together {
  atomic<int> dog;
  int puppy;
};
struct kennel {
  // Other data members...
  alignas(sizeof(together)) together pack;
  // Other data members...
};
static_assert(sizeof(together) <= hardware_constructive_interference_size);

[strega-nil]

It seems very useful.

[Amanieu]

So, basically the cache line size? I've typically just used a hard-coded value of 64 for this.

[Amanieu]

Also a const isn't very useful since you can't use them with #[align = "N"].

[strega-nil]

@Amanieu exactly. That seems... bad? since it's different across architectures.

That also seems bad.

[eddyb]

#[cfg(any(target_arch = "x86", ...))]
#[repr(align(64))]
pub struct CacheAligned<T>(pub T);

#[cfg(any(target_arch = "etc", ...))]
#[repr(align(123))]
pub struct CacheAligned<T>(pub T);

[strega-nil]

@eddyb seems fine, if it's in the standard.

[HadrienG2]

Count me interested in this one. I wouldn't want to put lots of architecture-specific cfgs in my code just so as to badly reinvent some constant which LLVM probably natively knows about.

[eddyb]

@HadrienG2 How are we supposed to lift it from LLVM though? All our type layouts and constants can be evaluated without LLVM's input atm.

[HadrienG2]

This is a very good question, and my current answer will be that I don't know. But I'm going to ask the LLVM team about it and get back to you once I have more details.

[hanna-kruppe]

@HadrienG2 I saw your mail to llvm-dev and I think you misunderstood what @eddyb was saying. While rustc is currently using LLVM as its sole backend, it's going to support other backends in the future, and consequently should not be tied too much to LLVM for backend-agnostic issues. One part of this is that type layout computations and constants don't rely on LLVM, so that they can be used by all future backends. So even if LLVM exposed these constants, we probably wouldn't/couldn't reuse them (at least not by interacting with LLVM during type layout computation).

[HadrienG2]

If this is a concern, I think your best option would be to build a small abstraction layer which can plug into LLVM as well as any other backend you may use in the future, and use that to get the hardware-specific type layout parameter.

I guess my main concern here is that I would not want rustc to go through the trouble of building yet another database of hardware characteristics when there are already so many ones available in the wild, and you probably already have a good one right under your feet.

[hanna-kruppe]

That doesn't solve the issue of having to duplicate that knowledge, it just pushes the responsibility for it on N other backends. Besides, the specific backends planned (miri and cranelift) won't have this information available, so we'd just push the job of building/stealing such a data base onto these projects (but why should they do that?). I understand your concern but I don't really see any way to do better than rustc cribbing this knowledge from LLVM (assuming it's available over there, which hasn't been confirmed or denied over at llvm-dev — maybe this stuff is solely in libc++, which rustc does not depend on).

[HadrienG2]

Well, the worst that could happen would be that you do decide to copy/paste this from LLVM, in which case my post on llvm-dev will still have achieved either of the following:

• You get the orders of magnitude from the various posts made there by people like Bruce Hoult or David Abdurachmanov
• You know which LLVM API/header you should keep in sync with, if such an API exists

From my perspective, that's still a win :)