This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] New numbers in the benchtests.

On 12/14/2017 11:43 PM, Siddhesh Poyarekar 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
>> +## 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.

That is good, and that will show up when it gets committed as a change
in the performance for these named sets.

>> 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
>> +## 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 #.

This is a question of outcome and expectations.

We have customers for whom certain inputs need to be performant relative
to others. If we mix those numbers into the existing namespace then it's
hard to see if they got better or worse on their own, since they are lost
in the mean.

We identify them as things that Red Hat as a downstream wants to keep
working well and we will put resources behind that.

Does that explain why we don't want to mix these with the other namespaces?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]