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?)  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: LDAP server docs
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Compiler branch prediction hints (was: So, is COUNT(*) fast now?)