Re: Fix performance of generic atomics

Sokolov Yura <funny.falcon@postgrespro.ru>

From: Sokolov Yura <funny.falcon@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, Jeff Janes <jeff.janes@gmail.com>, Jesper Pedersen <jesper.pedersen@redhat.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, pgsql-hackers-owner@postgresql.org
Date: 2017-09-06T13:42:29Z
Lists: pgsql-hackers
On 2017-09-06 16:36, Tom Lane wrote:
> Sokolov Yura <funny.falcon@postgrespro.ru> writes:
>> On 2017-09-06 15:56, Tom Lane wrote:
>>> 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.
> 
>> Not exactly. I've checked, that new version of generic
>> pg_atomic_fetch_or_u32
>> loop also gives improvement.
> 
> But once you put in the generic-gcc version, that's not reached 
> anymore.
> 

Yes, you're right.

But I think, generic version still should be "fixed".
If generic version is not reached on any platform, then why it is kept?
If it is reached somewhere, then it should be improved.

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


Commits

  1. Further marginal hacking on generic atomic ops.

  2. Use more of gcc's __sync_fetch_and_xxx builtin functions for atomic ops.

  3. Remove duplicate reads from the inner loops in generic atomic ops.