This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Converted benchmark to benchtest.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org
- Date: Thu, 5 Jun 2014 15:51:27 +0200
- Subject: Re: [PATCH] Converted benchmark to benchtest.
- Authentication-results: sourceware.org; auth=none
- References: <1397402907 dot 10643 dot 19303 dot camel at triegel dot csb> <534B8B38 dot 8090402 at redhat dot com> <8761m9iekn dot fsf at tassilo dot jf dot intel dot com> <87mwfifiks dot fsf at tassilo dot jf dot intel dot com> <53603208 dot 8060205 at redhat dot com> <1399033983 dot 32485 dot 5900 dot camel at triegel dot csb> <20140503104831 dot GA16118 at domone dot podge> <20140605123701 dot GF9145 at spoyarek dot pnq dot redhat dot com> <20140605125710 dot GA9316 at domone dot podge> <1401973584 dot 12855 dot 217 dot camel at triegel dot csb>
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?