[cfe-dev] [RFC] C++17 hardware constructive / destructive interference size

[James Y Knight via cfe-dev]

On Tue, May 29, 2018 at 4:39 PM JF Bastien <jfbastien at apple.com> wrote:

>
> On May 25, 2018, at 3:12 PM, James Y Knight <jyknight at google.com> wrote:
>
>
>
> On Fri, May 25, 2018 at 5:30 PM JF Bastien <jfbastien at apple.com> wrote:
>
>>
>>
>> On May 25, 2018, at 2:23 PM, James Y Knight <jyknight at google.com> wrote:
>>
>> My own employer doesn't make ABI stability promises for that code, and
>> thus is fine with changing the value anytime it feels like. That's not a
>> generically viable strategy for a value provided by the standard library.
>>
>> Additionally, before I sent that email, I looked at a number of the uses,
>> and it appeared as though a great many could be easily modified to use a
>> runtime-determined alignment.
>>
>>
>> That would be useful feedback on the paper… prior to it getting into
>> C++17. The committee’s POV voting the paper in was that having a constexpr
>> value was something we wanted, and so that’s what we have. At this point in
>> time I’d like to focus on implementing C++17 as it is, and / or filing DRs
>> as required.
>>
>
> Sure. I'm not on the committee. Even if I was, I certainly don't know that
> I would have identified the problem...
>
> But now that it has been identified, there's a choice of what to do. And
> not implementing the function (and presumably filing a DR saying so) is
> seeming like a pretty reasonable option.
>
>
> The committee discussed ABI issues (Jacksonville 2016) and decided that
> they’d rather have them than have a proliferation of #define SOMETHING 64.
> That discussion occurred with Google folks in the room, it might be higher
> bandwidth to consult with them? The notes are unfortunately quite sparse
> for that discussion.
>
> The libc++ community shouldn't decline to implement a feature without
> bringing concrete feedback to the committee. Without such feedback, I’d
> like to move forward with an implementation plan, because we should offer
> full C++17 support regardless of our distaste for specific features. I’ve
> received good feedback on the thread so far, I’m happy to leave the
> discussion open for a bit, talk to committee people next week in
> Rapperswil, and unless feedback goes the committee’s way I’d like to pursue
> an implementation. Does this sound fair?
>

There's been 3 options discussed so far -- I'm not sure which (#1 or #2)
you're now proposing to implement.

1. Return an subtarget-dependent value, depending on the exact CPU model
selected at compile-time.
  Good: Allows for better memory-usage/performance.
  Bad: Potential risk of ODR violations/ABI issues, due to dependency on
cpu tuning flags.
  Bad: Potential risk of same across versions of the compiler, if the
default generic cpu tuning is changed.

2. Choose a single "good enough" constant value for each platform.
  Good: eliminate ABI/ODR issues.
  Bad: value might be too conservative for users' desires.
    e.g. returning 128 for hardware_destructive_interference_size when 64
would've been sufficient will waste memory.
  Bad: Future CPU changes might invalidate the constant generic value,
requiring either that it be changed (introducing an ABI issue again), or
remain incorrect forever.
    e.g. most ARM chips have had 64-byte cache-lines for a while now, so
that would've seemed the only reasonable number to choose on ARM up until
recently. But, now, some of the newest CPUs have apparently switched to
128-byte cache-lines; should we change to 128?

(Or, 2b: YOLO, 64 bytes should be good enough for all platforms!)

3. Decline to implement at all.
  Good: avoid these issues.
  Bad: users who need it must do something themselves, e.g. choose some
arbitrary value e.g. 64.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180530/434cea72/attachment.html>