On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Apr 13, 2016 at 9:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@gmail.com> writes: >>>> I have never understood why you didn't include 64-bit atomics in the >>>> original atomics implementation, and I really think we should have >>>> committed a patch to add them long before now. > >>> What will you do on 32-bit platforms (or, more generally, anything >>> lacking 64-bit-wide atomics)? > >> We fall back to emulating it using spinlocks. > > 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? >> This isn't really an >> issue in practice because 32-bit x86 has native 64-bit atomics, and >> it's hard to point to another 32-bit platform that is likely to be >> have enough concurrency for the lack of 64-bit atomics to matter. > > It's not concurrency I'm worried about, it's the sheer overhead of > going through the spinlock code. I'm not sure I understand exactly what the concern is here. I agree that there is a possibility that any patch which uses 64-bit atomics could regress performance on platforms that do not support 64-bit atomics. That's why I argued initially against having fallbacks for *any* atomic operations; I was of the opinion that we should be prepared to carry two implementations of anything that was going to depend on atomics. I lost that argument, perhaps for the best. I think one of the problems here is that very few of us have any hardware available which we could even use to test performance on systems that lack support for both 32 and 64 bit atomics. We can compile without atomics on the hardware we do have and see how that goes, but that's not necessarily indicative of what will happen on some altogether different CPU architecture. In some cases there might be an emulator, like the VAX emulator Greg Stark was playing with, but that's not necessarily indicative either, and also, really, who cares? I think it would be cool if somebody started a project to try to optimize the performance of PostgreSQL on, say, a Raspberry Pi. Then we might learn whether any of this stuff actually matters there or whether the problems are completely elsewhere (like too much per-backend memory consumption). However, for reasons that are probably sort of obvious, I doubt I'll have much luck getting EnterpriseDB to fund work on that project - if it ever happens, it will probably have to be the work of a dedicated hobbiest, or somebody who has a tangible need to build an embedded system using PostgreSQL. > I'd be okay with atomics that were defined as "pointer width", if > we have a need for that, but I'm suspicious of 64-bits-exactly. I think LSNs are an important case, and they are not pointer width. -- 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