This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add cacos benchmark inputs
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 5 Oct 2013 06:52:27 +0530
- 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> <Pine dot LNX dot 4 dot 64 dot 1310041709020 dot 28946 at digraph dot polyomino dot org dot uk>
On 4 October 2013 22:50, Joseph S. Myers <joseph@codesourcery.com> wrote:
> 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
Yes, I'm still trying to figure out the best way to represent inputs
that may be suitable for both types of tests. One of the problems I'm
having is to make sure that I don't end up making the benchmark suite
a 'math benchmark suite'.
> 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
That would be necessary if these inputs have a really deviation from
the average case. However in that case I would prefer to explicitly
mention that case separately, like we do for the slow multiple
precision paths. Also, I think from a microbenchmark point of view it
would be much more useful to show the variation in performance than to
come up with a single average case number. The current benchmark
output is not adequate for such an output, but that should be the end
goal IMO. That obviously brings us to graphs, like WIll Newton and
Ondrej suggested in the past.
Siddhesh
--
http://siddhesh.in