[cfe-commits] [PATCH] atomic operation builtins, part 1

[John McCall]

On Oct 12, 2011, at 6:50 PM, Lawrence Crowl wrote:
> On 10/12/11, John McCall <rjmccall at apple.com> wrote:
>> So you want to pessimize code using large atomics just in case
>> it's eventually deployed to a theoretical future processor which
>> has burnt hardware on a use case that you've just stipulated that
>> you can't imagine a use for.
> 
> What is the problem with pessimizing code that doesn't currently
> have a use?

It's absurd to optimize based on the unsubstantiated idea that
future hardware is going to including instructions for something that
we don't have a use for.  x86-32 doesn't even have 16-byte atomics.
In fact, what significant 32-bit architecture does, or even plans to?

>> I think anyone who urgently needs to take advantage of 64-byte
>> atomics can opt into a lock-free implementation of them by
>> requesting a variant ABI.
> 
> Variant ABIs are expensive.  The x32 psABI has obvious and broad
> performance benefits, and yet it is only now getting any traction,
> near 10 years after AMD64.  I have confidence that there will be
> no widely used variant ABI for large atomics.

We're not talking about a radically different ABI.  We're talking about
basically -msse.

>>> If we do allow users to use larger atomics, then I don't think
>>> it's a good idea to guarantee the need for an ABI change when
>>> processors increase the maximum atomic size.
>> 
>> Suddenly introducing a need for huge alignments into environments
>> that don't support them is much more worrying to me than a small
>> number of programmers needing to manually request an optimization
>> on weird code.
> 
> Atomics often tend to be used in environments where performance
> is critical.  It may be wierd code, and rare code, but it's the
> code that can make or break system performance.

Great.  They can use -matomic-cachelines or, better yet, _Atomic(int512_t).

Bloating structures to meet 64-byte alignment requirements also has a
real impact on system performance.

John.