Re: Review of gnio, round 1

[Mark Mielke <mark mark mielke cc>]

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.

Meaning - you really do want the "unlikely" case to be "unlikely" before you tell the compiler that it is "unlikely". The compiler will try to improve the speed of the expected case at the expense of the not expected case.

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

Definitely. For this thread in specific - what might be unexpected today might become expected tomorrow. Using it only in specific cases where you know for certain the compiler has a chance of generating bad code (hopefully from analysis of the generated code or analysis of run time traces) is the best model. Let the compiler do its job for the rest. It can probably out-think you, and defining a block as unlikely might limit it's ability to reorder your code to best advantage.

Cheers,
mark

-- 
Mark Mielke <mark mielke cc>