Re: Fix performance of generic atomics

From: Sokolov Yura <funny(dot)falcon(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: Fix performance of generic atomics
Date: 2017-09-06 13:31:53
Message-ID: f669e9078243a65b8d03c263401e5c75@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-09-06 15:56, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>> On 5 September 2017 at 21:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Moreover, it matters which primitive you're testing, on which
>>> platform,
>>> with which compiler, because we have a couple of layers of atomic ops
>>> implementations.
>
>> If there is no gain on 2-socket, at least there is no loss either.
>
> The point I'm trying to make is that if tweaking generic.h improves
> performance then it's an indicator of missed cases in the less-generic
> atomics code, and the latter is where our attention should be focused.
> I think basically all of the improvement Sokolov got was from upgrading
> the coverage of generic-gcc.h.
>
> regards, tom lane

Not exactly. I've checked, that new version of generic
pg_atomic_fetch_or_u32
loop also gives improvement. Without that check I'd not suggest to fix
generic atomic functions. Of course, gcc intrinsic gives more gain.

--
Sokolov Yura aka funny_falcon
Postgres Professional: https://postgrespro.ru
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-06 13:36:36 Re: Fix performance of generic atomics
Previous Message Simon Riggs 2017-09-06 13:14:01 Re: [COMMITTERS] pgsql: Add psql variables showing server version and psql version.