[PATCH 3/3] debug.h: hint a compiler: TRACE is not executed in common usage

[Konstantin Kharlamov]

On 29.01.2019 18:05, Zebediah Figura wrote:
> 
> 
> On 1/29/19 5:33 AM, Konstantin Kharlamov wrote:
>> On 29.01.2019 14:22, Gabriel Ivăncescu wrote:
>>> On 1/29/19 10:01 AM, Alexandre Julliard wrote:
>>>> Konstantin Kharlamov <hi-angel at yandex.ru> writes:
>>>>
>>>>> On 29.01.2019 01:17, Marvin wrote:
>>>>>> Thank you for your contribution to Wine!
>>>>>>
>>>>>> This is an automated notification to let you know that your patch has
>>>>>> been reviewed and its status set to "Rejected".
>>>>>>
>>>>>> This means that the patch has been rejected by a reviewer. You should
>>>>>> have received a mail explaining why it was rejected. You need to fix
>>>>>> the issue and resend the patch, or if you are convinced that your
>>>>>> patch is good as is, you should reply to the rejection message with
>>>>>> your counterarguments.
>>>>>>
>>>>>> If you do not understand the reason for this status, disagree with 
>>>>>> our
>>>>>> assessment, or are simply not sure how to proceed next, please ask 
>>>>>> for
>>>>>> clarification by replying to this email.
>>>>>
>>>>> Hi, I don't understand, why the 3-rd patch was marked rejected? AFAIK
>>>>> it's being discussed.
>>>>
>>>> I explained that such micro-optimizations won't be accepted, unless
>>>> there is clear evidence that they make a difference. Your numbers are
>>>> not convincing enough I'm afraid.
>>>>
>>>
>>> FWIW, just a side note, speaking in general. Most micro-optimizations 
>>> have small benefits, just as they have a tiny burden individually. As 
>>> the burden increases by applying more of them, so does the benefit as 
>>> it piles up, so it's not all that bad and works both ways, IMO.
>>>
>>> I guess in this case, for potential users who want to get max 
>>> performance out of it, disabling TRACE and compiling wine themselves 
>>> should be better. (can always just keep a normal compiled Wine along 
>>> to TRACE problems and post bug reports and so on, if they run into any)
>>
>> I disagree that less branch-misses is a tiny improvement. I've read 
>> various posts where a particular algorithm become 10-15% faster by 
>> improving branch-prediction.
>>
>> I can't remember links ATM, but from a quick search I see e.g this 
>> page http://people.csail.mit.edu/jaffer/CNS/interpreter-branch which 
>> says they get 10% speed improvement due to branch prediction.
>>
>> It's easy to imagine that such a TRACE inserted in the middle of some 
>> algo in wine may reduce its execution speed.
>>
>>
> 
> If we're arguing that less branch mispredictions makes an algorithm 
> faster, can't we cut out the middleman and measure speed improvement 
> directly?
> 
> If there really is an optimization there, can we run perhaps more than 4 
> tests to prove it, especially if the results have such wide variance?

Sure, thanks for reply, will do. To give some update: measuring with 
Xonotic benchmark didn't show anything beyond noise, but then it's 
likely GPU-bound, I gotta try some thread-spawning or memory allocation 
benchmarks. I tried a couple of random benchmarks from web, but they 
didn't work. I figured phoronix-test-suite can be used, but it downloads 
x86_64 libs, whilst my wine build for testing is purely 32-bit.

So, I'll get to re-building everything tomorrow, will report back then.