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? >> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
