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
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 |