This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Add cacos benchmark inputs
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 4 Oct 2013 17:20:02 +0000
- Subject: Re: [PATCH] Add cacos benchmark inputs
- Authentication-results: sourceware.org; auth=none
- References: <20131004113941 dot GF28855 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310041512480 dot 28946 at digraph dot polyomino dot org dot uk> <CAAHN_R3xwx1xfXa99KDPndB_rCGBMqg5R_7PSCrcFRYheuA7wg at mail dot gmail dot com>
On Fri, 4 Oct 2013, Siddhesh Poyarekar wrote:
> On 4 October 2013 20:43, Joseph S. Myers <firstname.lastname@example.org> wrote:
> > On Fri, 4 Oct 2013, Siddhesh Poyarekar wrote:
> >> This patch adds inputs in libm-test.inc as benchmark inputs for cacos.
> >> This needs the recently posted changes to the benchmark framework. OK
> >> to commit?
> > I don't believe these special cases reflect ordinary input to cacos.
> Agreed, they don't. I'm using them as a starting point to get the
> function in. Please let me know if that is not acceptable, since I
> will then not waste time trying to sync up the inputs across the test
> suite and the benchmark suite.
I think it's a mistake to do any sort of syncing of inputs that requires
manual copying of data from one place to another. That is, if you want to
use libm-test.inc for benchmark inputs (bearing in mind that they are
unrepresentative - so if you did some form of randomized benchmarking to
get an overall score, rather than doing many runs with one input, then
many with another inputs, with consequent branch prediction implications,
then the unrepresentative inputs would need down-weighting, and probably
more representative inputs would need adding), then libm-test.inc, or a
source file generating libm-test.inc, needs to be the sole source of that
data to avoid copies getting out of sync. In the absence of
MPFR/MPC-based test generation as discussed at
<https://sourceware.org/ml/libc-alpha/2013-05/msg00059.html>, that means
benchmarks would need actually to include libm-test.c (generated in the
build tree from libm-test.inc), with appropriate predefines as in files
such as test-double.c to control the type being tested, and work from the
data tables therein.
Joseph S. Myers