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 по дате отправления: