Compiler branch prediction hints (was: So, is COUNT(*) fast now?)
| От | Marti Raudsepp |
|---|---|
| Тема | Compiler branch prediction hints (was: So, is COUNT(*) fast now?) |
| Дата | |
| Msg-id | CABRT9RC-AUuQL6txxsoOkLxjK1iTpyexpbizRF4Zxny1GXASGg@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: Compiler branch prediction hints (was: So, is COUNT(*)
fast now?)
|
| Список | pgsql-hackers |
On Fri, Oct 28, 2011 at 20:58, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: