This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Support separate benchmark outputs
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 17 Apr 2013 09:18:41 +0530
- Subject: Re: [PATCH] Support separate benchmark outputs
- References: <20130416122544 dot GH3063 at spoyarek dot pnq dot redhat dot com> <20130416132838 dot GA29626 at domone dot kolej dot mff dot cuni dot cz> <20130416140355 dot GI3063 at spoyarek dot pnq dot redhat dot com> <20130416155032 dot GA30216 at domone dot kolej dot mff dot cuni dot cz> <CAAHN_R1U_8_OMuzVKJ2q2w8i_XWYrx0mYmvHodBLxmNLiznSkQ at mail dot gmail dot com> <20130416185720 dot GA790 at domone dot kolej dot mff dot cuni dot cz>
On 17 April 2013 00:27, OndÅej BÃlka <neleai@seznam.cz> wrote:
> How do you want to use data that you get from these benchmarks?
> Could you say that if I come with new implementation if firefox will run
> faster or slower?
That's not the point of a microbenchmark. A microbenchmark will give
you more generic information like performance of the function under
various defined conditions. That way an implementing application can
see that and decide on the tradeoffs it can make. Our goal is to
provide acceptable average case performance, but that definitely does
not mean that we ignore performance characteristics of our functions
under specific loads.
> I measure several implementations (glibc, modified, byte, qwords)
> You measure several implementations (sse3, sse4 , byte, avx)
>
Difference is that your implementations don't sit together in parallel in glibc.
Siddhesh
--
http://siddhesh.in