Re: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Tue, Aug 11, 2015 at 02:25:26PM -0400, Zack Weinberg wrote:
> >> ...
> >>> thats completely flawed analysis
> >> ...
> >> 
> >> I would like to believe you about this, because I would have liked
> >> not to have to patch 66 files for explicit_bzero, but I don't; not
> >> because I disbelieve any of your concrete claims - they all sound
> >> *plausible* - but because your attitude does not admit the
> >> possibility that you might be wrong.
> > 
> > You don't have to trust, you have to verify.
> 
> I can't verify any of your claims, because you have not documented
> enough of your methodology for me to even *attempt* to reproduce them.

Unless I forgot I always with data put a line profiler is available at
following address. So is it too hard to download it and check that your
applications give similar results as are my claims?

> (Whole-system profiling data is inherently unreproducible; nobody else
> has the exact same computer and configuration that you do.

That like saying that medical experiments are inherently unreproducible
as nobody has some immune system as you do. Yet you could do hypothesis
testing to see if medicine works or not.

Likewise here you could check if distribution you get here is stable.
When I ran this most applications behaved similirly and between runs
distribution of sizes, running times stayed mostly same. 

As for reproducibility its relatively easy to make that reproducible by
using script that calls fixed applications with fixed inputs. For
example gcc workload is a simple test that I use in my profiler.

You could tell that my sample size is small. Thats true but its better
than nothing so provide data instead complaining.

>  When you
> have posted benchmark data, they are synthetic results which you have
> only *asserted* reflect real-world usage patterns; you have not provided
> evidence of any kind for that assertion.)
> 
No, these were perfectly replicable. Just pick profiler from link thats
in email and see if you get same result and different. 


> > Here you should stop talking that its hard to tell whats overhead of plt
> > calls and just read benchmark data.
> 
> I believe that was Mike's claim, not mine.  Also, every time you tell
> someone to shut up and go away, you make people not want to work with you.
> 
This quote is bit out of context. I meant that you could talk about
something for long time without telling anything new by making guesses
what could happen.

So to move discussion in more productive direction you should start
doing something. As Mike said that plt calls are slow but I said that
they cause regression as you call two functions instead one we need
verify what holds and what not.