On Wed, Apr 13, 2016 at 10:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers