This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] randomize benchtests


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]