This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Converted benchmark to benchtest.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Torvald Riegel <triegel 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 14:57:10 +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>
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? Andy any insigth?
I could try to simulate it by using many locks and choosing one at
random, how that would work.
Also Siddhesh, benchmarks are useless unless you use their result so
what did you measured with your benchmark and what do you thing about