This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Converted benchmark to benchtest.
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Torvald Riegel <triegel at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 5 Jun 2014 21:23:04 +0530
- 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> <20140605135127 dot GA13361 at domone dot podge>
On 5 June 2014 19:21, OndÅej BÃlka <firstname.lastname@example.org> wrote:
> 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.
If sanity is what you're looking for, i.e. the requisite calls not
being optimized out, then yes, I did verify that and even ran it once
against current master:
> 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.
The benchmark you proposed is equivalent in terms of stuff we're
measuring and I was only trying to help you get your benchmark into
the standard format so that you don't have to redo the json output or
leave that for someone else to do. If uncontended performance is
important then this benchmark is useful regardless of whether it shows
that the assembly implementation is better than the C one or not. In
fact you argued in your patch proposal that the benchmark itself is
orthogonal to Andi's patch. Did you change your mind about that?
> 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?
I like my benchmark name in italics :)