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

On Tue, Nov 1, 2011 at 9:55 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Nov 1, 2011 at 10:47 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
>> 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?
>
> Well, the obvious problem is that we might end up spending a lot of
> work on something that doesn't actually improve performance, or even
> makes it worse, if our guesses about what's likely and unlikely turn
> out to be wrong.  If we can show cases where it reliably produces a
> significant speedup, then I would think it would be worthwhile, but I
> think we should probably start by looking at what's slow and see how
> it can best be made faster rather than by looking specifically for
> places to use likely() and unlikely().

The first thing that jumps to mind is the hint bit checks in
HeapTupleSatisifiesMVCC().

merlin