Re: Use compiler intrinsics for bit ops in hash
Jesse Zhang <sbjesse@gmail.com>
From: Jesse Zhang <sbjesse@gmail.com>
To: David Fetter <david@fetter.org>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>, Andrew Gierth <andrew@tao11.riddles.org.uk>
Date: 2020-03-09T00:29:25Z
Lists: pgsql-hackers
Hi David, On Sun, Mar 8, 2020 at 11:34 AM David Fetter <david@fetter.org> wrote: > > On Mon, Mar 02, 2020 at 12:45:21PM -0800, Jesse Zhang wrote: > > Hi David, > > Per discussion on IRC with Andrew (RhodiumToad) Gierth: > > The runtime detection means there's always an indirect call overhead > and no way to inline. This is counter to what using compiler > intrinsics is supposed to do. > > It's better to rely on the compiler, because: > (a) The compiler often knows whether the value can or can't be 0 and > can therefore skip a conditional jump. Yes, the compiler would know to eliminate the branch if the inlined function is called with a literal argument, or it infers an invariant from the context (like nesting inside a conditional block, or a previous conditional "noreturn" path). > (b) If you're targeting a recent microarchitecture, the compiler can > just use the right instruction. I might be more conservative than you are on (b). The thought of building a binary that cannot run "somewhere" where the compiler supports by default still mortifies me. > (c) Even if the conditional branch is left in, it's not a big overhead. > I 100% agree with (c), see benchmarking results upthread. Cheers, Jesse
Commits
-
Modify additional power 2 calculations to use new helper functions
- 02a2e8b44200 13.0 landed
-
Modify various power 2 calculations to use new helper functions
- d025cf88ba5a 13.0 landed
-
Add functions to calculate the next power of 2
- f0705bb6286d 13.0 landed
-
Move src/backend/utils/hash/hashfn.c to src/common
- 05d8449e7369 13.0 cited