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

[Hal Finkel via cfe-dev]

On 05/30/2018 02:38 PM, James Y Knight via cfe-dev wrote:
>
>
> On Tue, May 29, 2018 at 4:39 PM JF Bastien <jfbastien at apple.com
> <mailto:jfbastien at apple.com>> wrote:
>
>
>>     On May 25, 2018, at 3:12 PM, James Y Knight <jyknight at google.com
>>     <mailto:jyknight at google.com>> wrote:
>>
>>
>>
>>     On Fri, May 25, 2018 at 5:30 PM JF Bastien <jfbastien at apple.com
>>     <mailto:jfbastien at apple.com>> wrote:
>>
>>
>>
>>>         On May 25, 2018, at 2:23 PM, James Y Knight
>>>         <jyknight at google.com <mailto: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.

I'll add to option 3: Cause many downstream organizations to carry
out-of-tree patches to implement the feature.

 -Hal

>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180530/519150dc/attachment.html>