Resending due to list auto-discard. On 10/12/11, Lawrence Crowl <[email protected]> wrote: > On 10/12/11, John McCall <[email protected]> wrote: >> On Oct 12, 2011, at 6:50 PM, Lawrence Crowl wrote: >> > On 10/12/11, John McCall <[email protected]> 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? > > 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. > >> > > 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. > > 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. > > I can implement floating point operations in many different ways > without affecting the ABI because only the memory layout affects > the ABI of floats. The issue under discussion is the memory layout > of atomics. Any decisions made in the near term are likely to > be irrevokable. > > Atomics are different from floating point in another crucial > respect. The ABI compatiblity depends not only on the layout, > but on the synchronization protocol used to access them. If two > atomic operations are implemented with different protocols, > the synchronization will fail and the application will fail in > mysterious ways. I have participated in just such a mistake and > it was not pretty. > > A consequence of avoiding the mistake is that one needs to have > the system provide a single implementation of all potential > non-lock-free atomics. Effectively, that means a dynamic library > provided to the applications by the system. > >> > > > 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). > > They can do that only if they coordinate in advance with other > users of those same structures. > >> 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. After all, one uses atomics because one has a run-time > problem. If not, mutexes are a safer technology. > > -- > Lawrence Crowl >
-- Lawrence Crowl _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
