This is the mail archive of the
mailing list for the glibc project.
Re: RFC: What inputs to use for sqrt perf testing
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Steve Ellcey <sellcey at mips dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 4 Oct 2013 10:17:23 +0530
- Subject: Re: RFC: What inputs to use for sqrt perf testing
- Authentication-results: sourceware.org; auth=none
- References: <cf183992-8b0e-4439-b651-f3da33cda74d at BAMAIL02 dot ba dot imgtec dot org> <CAAHN_R0wRumvcBkfeCAjP5MTbqOpoqXBPoJMdJY4jCyDaant8g at mail dot gmail dot com> <524E3C70 dot 4070800 at redhat dot com>
On 4 October 2013 09:26, Carlos O'Donell <firstname.lastname@example.org> wrote:
> On 10/03/2013 10:39 PM, Siddhesh Poyarekar wrote:
>> On 4 October 2013 02:55, Steve Ellcey <email@example.com> wrote:
>>> While making a sqrt performance improvement for MIPS I noticed that there
>>> was no sqrt performance test in the 'make bench' tests and Joseph suggested
>>> that we should have one. It looks like adding it is trivial (see patch),
>>> but the real question is what input to use. I just threw in 1.9 and 10000.0
>>> to test this patch, but I don't think those are necessarily good choices.
>>> Are there any math experts out there could suggest a better selection of
>>> inputs for sqrt to use in the performance tests?
>>> Here is my strawman patch, I don't expect this to get checked in as it
>>> is, I am just including it for reference purposes.
>> The method I'm using for this is to add probes at various branch
>> points within the function and use a systemtap script to print out the
>> input whenever the probe point is hit. This is a bit slow (in terms
>> of effort), but would ensure good coverage. Also, as a starting
>> point, I wouldn't mind having your strawman patch in and then more
>> inputs added to it when you have them ready.
> Would it make sense to start off with all the inputs used by
> libm-test.inc e.g. sqrt_test_data?
Oh yeah, why not. In fact, it won't be a bad idea to do that for all
functions. That would be a better starting point than using 42.