This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Converted benchmark to benchtest.
- From: Torvald Riegel <triegel at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- 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, 05 Jun 2014 15:06:24 +0200
- Subject: Re: [PATCH] Converted benchmark to benchtest.
- Authentication-results: sourceware.org; auth=none
- References: <53497694 dot 4040901 at redhat dot com> <20140412194007 dot GA1284 at domone dot podge> <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>
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.