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: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- 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:54:37 +0200
- Subject: Re: [PATCH] Converted benchmark to benchtest.
- Authentication-results: sourceware.org; auth=none
- References: <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> <CAAHN_R2ZgJrY-3cynReWDZcoNGgNj31+o0eu1QNuqbCd+bUXFQ at mail dot gmail dot com>
On Thu, Jun 05, 2014 at 09:23:04PM +0530, Siddhesh Poyarekar wrote:
> On 5 June 2014 19:21, OndÅej BÃlka <neleai@seznam.cz> 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:
>
> "pthread_rwlock_test": {
> "rwlock": {
> "duration": 2.87958e+09,
> "iterations": 2.7688e+07,
> "max": 172.944,
> "min": 97.516,
> "mean": 104.001
> },
> "rdlock": {
> "duration": 2.88252e+09,
> "iterations": 2.7022e+07,
> "max": 252.66,
> "min": 101.541,
> "mean": 106.673
> }
> }
>
It is that you must always look for ways that could make benchmark
invalid.
Also I noticed that this takes long to run, did you also noticed that?
> > 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.
I am ok also with this benchmark but its your benchmark so I treated it
like that.
> 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.
That is true to some extend, but lets assume that we check this patch in
other way and commit your benchmark. Do you thing that next time when
there comes a patch touching rdlocks somebody will do a comparison if
nobody did it first time?
> 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?
>
Its orthogonal what benchmark we use. However as Carlos said that he
wants a benchtest before it could be commited we should settle for
something.
> > 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 :)
>
> Siddhesh
> --
> http://siddhesh.in