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

[John McCall]

On Oct 12, 2011, at 7:37 PM, Lawrence Crowl wrote:
> Applications drive architecture extension, not the reverse.
> What applications will want to use larger atomics now that there
> are languages for specifying them?  We have obvious need for atomic
> types that are twice the size of a pointer.  We do not presently
> have a compelling case to implement even larger types efficiently.
> We may have that evidence in the future.  However, given ABI
> compatibility constraints, we must choose forever very soon.

Yes, I understand.  I think you and Jeffrey Yasskin are approaching
this from the perspective that nobody will ever actually use these
types when they're not lockless, and I am assuming that of course
some people will, because they're attracted by the word "atomic",
and they'll do so with full knowledge that a cheap lock might be
involved, and those people will be very surprised to find out that
the implementation is substantially less efficient than possible
simply because we wanted to future-proof against a grossly
improbable outcome.

>> We're not talking about a radically different ABI.  We're talking
>> about basically -msse.
> 
> No, we are not.  The -msse flag does not affect the layout of doubles
> in memory.  How successful would -msse have been if it required
> changing the size of a double and recompiling every library that
> went into the program?  Every device driver?  Not very.

You're right;  my example was poorly chosen.  Of course -msse is
purely local to a translation unit.

Across GCC and Clang, there are dozens of examples of
command-line options which do impact the ABI, all of them much
more invasively than this.  If I were designing this properly, though,
I would suggest some sort of attribute((lockless)) to opt in a specific
object to a variant lockless implementation.

>> Bloating structures to meet 64-byte alignment requirements also
>> has a real impact on system performance.
> 
> True enough.  However, I expect the performance tradeoff to weigh
> in favor of reducing synchronization costs over saving space for
> atomics.

I'm not sure I would agree even if I saw any likelihood whatsoever
of these performance gains actually being realized.  We live in an
era where memory is precious and CPU cycles are cheap, and
that doesn't seem to be changing.

John.