Re: [PATCH] New numbers in the benchtests.

[Ben Woodard <woodard at redhat dot com>]

I think that this actually kind of gets at the nature of what these
benchtests currently show as opposed to what they could ultimately be
used for.

Right now, they demonstrate specific numbers that trigger the
implementation to go into different modes. With our current
implementation, this is the fast path, the slow path and the very slow
path. So these functions are there to show how well the current
implementation is running when it enters those modes. You can easily
see if a code change or a compiler change improves or impacts
performance. This is good for optimizing the implementation for
performance in the traditional way.

However, there are also certain inputs to functions which are known to
be problematic or more difficult to round correctly than others and
you must compute them out to N-digits to get correct rounding when
using a particular implementation. The quality of implementation is in
essence how often we hit those hard cases and how quickly we can deal
with them. These benchtests that I added are more along those lines.
For example, they include exp for the last subnormal and the first
normal floating point number. Together these represent a test case
which is known by the customer to identify quality of implementation
issues. They have indicated to us this case comes up frequently enough
that would like it to be tracked and Carlos suggested adding it to the
benchtests.

When we change the implementation of exp, I still feel like keeping
our eye on cases like this as well as the hard to round cases are
interesting. We want to make sure things like that don't blow up. That
was my intent with this.

-ben

On Thu, Dec 14, 2017 at 11:43 PM, Siddhesh Poyarekar
<siddhesh@gotplt.org> wrote:
> On Friday 15 December 2017 09:50 AM, Ben Woodard wrote:
>> diff --git a/benchtests/exp-inputs b/benchtests/exp-inputs
>> index aff3fb42f1..b94e19c4f5 100644
>> --- a/benchtests/exp-inputs
>> +++ b/benchtests/exp-inputs
>> @@ -587,3 +587,12 @@
>>  0x1.0000015853da7p0
>>  0x1.0000098e5e007p0
>>  0x1.0000099a1ac59p0
>> +
>> +# Contributed based on customer reports
>> +# Ben Woodard woodard@redhat.com
>> +## name: redhat-slow-customer-cases
>> +0x1.0p-53
>> +## name: redhat-fast-customer-cases
>> +0x1.0p-52
>> +0x1.0p+0
>> +0x1.999999999999Ap-4
>
> Paul McGehearty has re-implemented exp which will likely change the
> nature of these numbers.  What it means is that the slow path will be
> gone for exp.  I suggest re-testing with the new implementation because
> we will probably just end up dropping all of these partitions and you
> can then just add these inputs as is.
>
>> diff --git a/benchtests/pow-inputs b/benchtests/pow-inputs
>> index 78f8ac73d5..cea50edea7 100644
>> --- a/benchtests/pow-inputs
>> +++ b/benchtests/pow-inputs
>> @@ -509,3 +509,15 @@
>>  0x1.f8b79758182dap-884, 0x1.ed6174093fca4p-6
>>  0x1.fa5c677254961p133, -0x1.c91962524971ep-1
>>  0x1.ff0544adacb78p649, -0x1.6c17c3a7210e2p-1
>> +
>> +
>> +# Contributed based on customer reports
>> +# Ben Woodard woodard@redhat.com
>> +## name: redhat-slow-customer-cases
>> +0x1.fffffffffffffp-1, 0x1.8p+0
>> +0x1.ffffffffffffdp-1, 0x1.8p+0
>> +0x1.ffffffffffff7p-1, 0x1.8p+0
>> +## name: redhat-fast-customer-cases
>> +0x1.ffffffffffffep-1, 0x1.8p+0
>> +0x1.ffffffffffffcp-1, 0x1.8p+0
>> +0x1.999999999999ap-4, 0x1.8p+0
>>
>
> Why do these inputs need to be in a different namespace?  They should go
> into one of the existing namespaces, i.e. 768bits, 240bits, etc.  Their
> performance relative to the existing namespaces should give you an
> indication where they fit in.  If you want these inputs to look distinct
> then you could add a comment indicating that these inputs came in from
> RH; comments are just a single #.
>
> Thanks,
> Siddhesh