[PATCH] Converted benchmark to benchtest.
Torvald Riegel
triegel@redhat.com
Thu Jun 5 13:06:00 GMT 2014
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
accesses.
> 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.
More information about the Libc-alpha
mailing list