Re: Review of gnio, round 1

[John McCutchan <john johnmccutchan com>]

On Mon, Apr 27, 2009 at 10:30 AM, Mark Mielke <mark mark mielke cc> wrote:
> John McCutchan wrote:
>
> On Mon, Apr 27, 2009 at 8:40 AM, Havoc Pennington
> <havoc pennington gmail com> wrote:
>
>
> 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.
>
>
> Hi John:
>
> On the penalty being the same - are you assuming or have you looked at the
> generated assembly?
>
> The last time I tried this out and analyzed gcc -S output, the case without
> using the "likely" hint generated code that still used a branch, but was
> mostly inline in both cases. When I switched to using a "likely" hint, it
> moved the entire "unlikely" block down to the bottom of the function. Yes,
> there is a bad branch prediction cost in both cases, but I think there is
> *also* a cache miss possibility in here. That is, if the case is truly
> unlikely - it's been moved out to the bottom into a different cache line,
> leaving more room in the calling cache line for the success case.
>

My commentary was based on looking at the assembly code and gcc didn't
move functions around with my tests. Your point is an excellent one,
incorrect use of "likely" and "unlikely" could easily lead to an
i-cache miss.

-- 
John McCutchan <john johnmccutchan com>