Re: Review of gnio, round 1

[John McCutchan <john johnmccutchan com>]

On Mon, Apr 27, 2009 at 8:40 AM, Havoc Pennington
<havoc pennington gmail com> wrote:
> Hi,
>
> On Mon, Apr 27, 2009 at 10:40 AM, Behdad Esfahbod <behdad behdad org> wrote:
>>> There is a lot of G_UNLIKELY() calls in places that really are not in
>>> any way performance sensitive. I'm not sure I like this, since it makes
>>> the code harder to read for very little gain. Like, it probably makes
>>> sense for the inlined version of g_once_init_enter() to use G_LIKELY,
>>> but I don't think it makes sense for e.g. error checking when creating a
>>> socket, which is not gonna happen a lot.
>>
>> I think I can answer this part since I use G_UNLIKELY extensively myself.
>>  The way I see it, it's not just a hint for the compiler, it's also an
>> annotation of the source code for the next person reading it, saying "this
>> branch is expected to happen in exceptional cases only, not the norm."  And
>> I find it extremely useful for that.
>>
>
> I don't really know much about modern processors or compilation, but
> my understanding is that the penalty for being wrong on G_UNLIKELY()
> is quite high. And as we know from the old "premature optimization"
> cliche it can be a bit hard to predict which codepaths get hit. For
> example, I can certainly imagine uses of IO or socket APIs where IO
> errors are hit reasonably often.
>

The penalty for being wrong is the same as when the CPU makes a bad
branch prediction.

You are providing a hint though and if that hint is bad, you are going
to cause the CPU to initially take the wrong branch, which can be
expensive.

It's good practice to avoid using hints unless you have a firm grasp
on the odds of the branch being taken.

-- 
John McCutchan <john johnmccutchan com>