This is the mail archive of the 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] Converted benchmark to benchtest.

On Thu, Jun 05, 2014 at 03:06:24PM +0200, Torvald Riegel wrote:
> On Thu, 2014-06-05 at 14:57 +0200, OndÅej BÃlka wrote:
> > On Thu, Jun 05, 2014 at 06:07:01PM +0530, Siddhesh Poyarekar wrote:
> > > On Sat, May 03, 2014 at 12:48:31PM +0200, OndÅej BÃlka wrote:
> > > > Its nice to have but orthogonal on proposed change, so it should not
> > > > block this patch
> > > 
> > > This looks like something that could easily use the $bench-inputs
> > > format since you're really just looking for mean times.  I haven't
> > > checked to see if a failed branch would be expensive compared to the
> > > lock/unlock cycle we're testing, but I'm guessing that it should get
> > > cached and hence not have an impact since we don't interleave the
> > > rdlock and wrlock calls.
> > > 
> > Anyway I realized that microbenchmarks may be wrong way here.
> > 
> > How it is likely that you have lock in L1 cache?
> That can indeed be likely, depending on the way the program uses the
> locks.  Especially for a rdlock this can be likely.
That I wanted to hear. 
> > Andy any insigth? 
> > I could try to simulate it by using many locks and choosing one at
> > random, how that would work.
> I don't think that's necessary.  The purpose of this benchmark is to
> measure the single-thread overheads, and whether they differ between a C
> implementation and an assembly implementation.  Assuming that does
> implement the same algorithm, they should roughly make the same memory
> accesses.
That could depend on scheduling but rwlock code looks like taking gcc -S
output anyway.

> > Also Siddhesh, benchmarks are useless unless you use their result so
> > what did you measured with your benchmark and what do you thing about
> > Andi's patch.
> The fact that Siddhesh reviewed it doesn't imply that he has to measure,
> nor that the benchmark would be useless.

For benchmark review you should definitely run it to check if result
make sense. It helps to prevent oops like what happened to me when I
checked pthread_once it took always few cycles and problem turned out to
be not linking with pthread.

Siddhesh send a alternate benchmark so somebody needs to stand before
it. Who will do it? I wont as I am convinced by previous benchmark.
Will one of you stop bikesheding and say that there is really no difference 
between assembly and c rwlock implementation or will you keep arguing
about name of benchmark for next month?

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