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, 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.

> 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

> 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.

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