Compiler branch prediction hints (was: So, is COUNT(*) fast now?)

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Compiler branch prediction hints (was: So, is COUNT(*) fast now?)
Date: 2011-11-01 14:47:34
Message-ID: CABRT9RC-AUuQL6txxsoOkLxjK1iTpyexpbizRF4Zxny1GXASGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 28, 2011 at 20:58, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I tried sprinkling a little branch-prediction magic on this code using
> GCC's __builtin_expect().  That initially seemed to help, but once I
> changed the BufferIsValid() test to !BufferIsInvalid() essentially all
> of the savings disappeared.

Sounds like mere chance that the compiler decided to lay it out in one
way or another. A different compiler version could pick a different
path.

I quite like the likely() and unlikely() macros used in Linux kernel;
much more readable than __builtin_expect and they might also be useful
for (usually redundant) error checks and asserts in hot code paths. It
looks like this:

#ifdef __GNUC__
# define unlikely(xpr) __builtin_expect(xpr, 0)
#else
# define unlikely(xpr) (xpr)
#endif

if (unlikely(blkno >= rel->rd_smgr->smgr_vm_nblocks))
{
/* unlikely branch here */
}

However, the wins are probably minor because most of the time,
adaptive CPU branch prediction will override that. Do you think this
would be a useful patch to attempt?

Regards,
Marti

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-11-01 14:55:02 Re: Compiler branch prediction hints (was: So, is COUNT(*) fast now?)
Previous Message Magnus Hagander 2011-11-01 14:47:03 Re: LDAP server docs