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
-
Further marginal hacking on generic atomic ops.
- bfea92563c51 11.0 landed
-
Use more of gcc's __sync_fetch_and_xxx builtin functions for atomic ops.
- e09db94c0a5f 11.0 landed
-
Remove duplicate reads from the inner loops in generic atomic ops.
- e530be96859e 11.0 landed