This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 11 Aug 2015 23:56:46 +0200
- Subject: Re: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.
- Authentication-results: sourceware.org; auth=none
- References: <55C76FCD dot 5020607 at panix dot com> <CAMe9rOoAWjRma_mG_FazVh3FGOyiGJ=g82=bsfGqa-COnt5p1g at mail dot gmail dot com> <55C78525 dot 40402 at panix dot com> <CAMe9rOrKg8nzB67+OCXz5n1u7ZLnJncpX7J6KkEXqe0Bra843w at mail dot gmail dot com> <55C79AD8 dot 3070301 at panix dot com> <20150810030920 dot GE23550 at vapier> <20150810211200 dot GA17734 at domone> <CAKCAbMia4RCA7X0YHYeXC6eAGCxzDqhWrMiGS4NxA-cDxFioVw at mail dot gmail dot com> <20150811080451 dot GA6280 at domone> <55CA3E16 dot 9010601 at panix dot com>
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.