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: Tue, 16 Apr 2013 23:09:46 +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>
On 16 April 2013 21:20, OndÅej BÃlka <neleai@seznam.cz> wrote:
> That is my point that you must measure relative performance. However
> code above does not measure performance. In simple test
No, your idea of relative performance is different from mine -
actually I can't call it mine since these are already existing tests
(written by Jakub I think) that I'm only copying over. From your
description it seems like your definition of relative is the original
memcpy vs the modified memcpy. Here 'relative' implies comparison
between multiple implementations of functions, i.e. the sse3, sse4,
avx, etc. and then with the generic implementation and finally the
simple byte copy/move/write, etc.
> According to sequential glibc implementation is better than my by 15%.
> However when I sample randomly my implementation becomes 33% better than
> glibc one.
There's a do_random_tests in memcpy (and possibly in others too, I
haven't checked) that is there just for correctness tests. It can be
trivially modified to measure the cost of the calls and make into a
reasonable random sampling benchmark.
Siddhesh
--
http://siddhesh.in