From: Roy Lyseng
Date: March 31 2011 8:39pm
Subject: Re: bzr commit into mysql-trunk branch (jorgen.loland:3323) Bug#11766327
List-Archive: http://lists.mysql.com/commits/134414
Message-Id: <4D94E665.2070801@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Guilhem,

On 31.03.11 21.49, Guilhem Bichot wrote:

>>>> +bool JOIN_TAB::extend_and_fix_jt_and_sel_cond(Item *add_cond, uint line)
>>>> +{
>>>> + if (extend_and_fix_cond(add_cond, line))
>>>
>>> could add unlikely()
>>
>> I'm a bit afraid of the "code contamination" of these unlikely() macros.
>
> Well... we have those macros... I find it's good if it can help lower the
> performance impact of all those rarely executed "if (out of memory)".
> What bad do they do?
>
>> There is also an option to gather branch prediction statistics using two-stage
>> compilations. (The first stage gathers statistics, the second uses statistics
>> to apply branch prediction hints). The benefit of this is that code need no
>> changes, the drawback is the need for two-stage compilation, which makes it
>> hard to do in developer sandboxes.
>
> I'm not aware of two-stage compilation. What compiler does that?
> And, isn't it dangerous? I mean, OOM happens rarely on the Lab machine where the
> release is built, as rarely as on the customer's, so if(OOM) will be optimized
> the same way, but for the other if()s, they may be optimized in some way on the
> Lab machine, in a way which isn't representative of a real load, and thus would
> perform poorly at the customer's??

We did that for Clustra/HADB on Solaris using SunStudio compilers several years 
ago. The speedup was amazing, probably 10-15%. Nowadays, I think gcc is capable 
of this as well.

I think the way it works is that regardless of load, most if tests have a branch 
that is taken more often than others. And if there is an occational miss, the 
result is barely noticeable.

Thanks,
Roy