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

[Konstantin Kharlamov]

On 29.01.2019 22:59, Konstantin Kharlamov wrote:
> 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.

Unfortunately phoronix-test-suite doesn't run under wine, it quits with "can't recognize CV_redist.x64.xe' as an internal or external command".

I'll test later if it works under Windows and report a wine bug if it does; but if anybody is aware of any other free windows benchmarkss for memory allocation of threads creation that work under wine, I'll be happy to try them out.

I guess there's no haste since someone for some reason told Marvin to reject my patch (let's hope it was just a misclick without any malicious intention).