On Wed, Apr 13, 2016 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> That's what I thought you were going to say, and it means that any
>>> "performance improvement" patch that relies on 64-bit atomics in hotspot
>>> code paths is going to be a complete disaster on anything but modern Intel
>>> hardware. I'm not sure that's a direction we want to go in. We need to
>>> stick to a set of atomics that's pretty widely portable.
>
>> I think 64-bit atomics *are* pretty widely portable. Can you name a
>> system with more than 4 CPU cores that doesn't support them?
>
> No, you're ignoring my point, which is what happens on single-CPU
> 32-bit machines, and whether we aren't going to destroy performance
> on low-end machines in pursuit of better performance on high-end.
>
> Now, to the extent that a patch uses a 64-bit atomic op to replace
> a spinlock acquisition, it might be pretty much a wash if low-end
> machines have to use a spinlock to emulate the atomic op. But it
> would be really easy for the translation to replace one spinlock
> acquisition with multiple spinlock acquisitions, and that would hurt.
One of us is confused, or we're just talking past each other, because
I don't think I'm ignoring your point at all. In fact, I think I just
responded to it rather directly. I agree that the exact risk you are
describing exists. However, the multiple spinlock cycles that you are
concerned about will only occur on a platform that doesn't support
64-bit atomics. In order to test whether there is a performance
problem on such hardware, or how serious that problem is, we'd need to
have access to such hardware, and I don't know where to find any such
hardware. Do you?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
