This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] randomize benchtests
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 17 May 2013 13:47:22 +0200
- Subject: Re: [PATCH] randomize benchtests
- References: <20130422120018 dot GA30323 at domone dot kolej dot mff dot cuni dot cz> <CAAHN_R1pHJLoS3iP7KrQMmA4gPLawvuRWoK8Xy13VPMBbyPk+Q at mail dot gmail dot com> <20130422125625 dot GA30639 at domone dot kolej dot mff dot cuni dot cz> <1368786270 dot 3054 dot 3119 dot camel at triegel dot csb> <20130517104445 dot GA14264 at domone dot kolej dot mff dot cuni dot cz> <1368789361 dot 3054 dot 3193 dot camel at triegel dot csb>
On Fri, May 17, 2013 at 01:16:01PM +0200, Torvald Riegel wrote:
> On Fri, 2013-05-17 at 12:44 +0200, OndÅej BÃlka wrote:
> > On Fri, May 17, 2013 at 12:24:30PM +0200, Torvald Riegel wrote:
> > > On Mon, 2013-04-22 at 14:56 +0200, OndÅej BÃlka wrote:
> > > > On Mon, Apr 22, 2013 at 05:44:14PM +0530, Siddhesh Poyarekar wrote:
> > > > > On 22 April 2013 17:30, OndÅej BÃlka <neleai@seznam.cz> wrote:
> > > > > > + clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &start);
> > > > > > + for (k = 0; k < iters; k++)
> > > > > > + {
> > > > > > + i = rand_r (&seed)%NUM_SAMPLES;
> > > > > > + BENCH_FUNC(i);
> > > > > > + }
> > > > > > + clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &end);
> > > > >
> > > > > This is wrong. The interval also has the time taken to call rand_r.
> > > > >
> > > > This is not wrong. You are interested only on differences between
> > > > implementations and adding same time from rand_r calls does not change
> > > > that.
> > >
> > > But if we should be changing the rand_r implementation in the future
> > > (e.g., if we might be getting HW support for it on a certain
> > > architecture), then this will lead to a difference in all our
> >
> > From stdlib/rand_r.c:
> >
> > /* This algorithm is mentioned in the ISO C standard, here extended
> > for 32 bits. */
> >
> > Given that we can break applications that depend on rand_r
> > reproducibility it will not change.
> > If you want fully specified generator use drand48.
>
> My comment was about the performance of one call to rand_r. This isn't
> about where or how it's specified, it's just about the performance, and
> trying to keep it reproducible.
Performance does not matter as we measure overhead with empty body and
substract it. This only adds noise which can be controled by sufficient
number of samples.
Reproducibity? These tests are not reproducible nor designed to be
reproducible. Runs in same machine are affected by many environtmental
effects and anything other than randomized comparison of implementations
in same run has bias that makes data worthless.