This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] New numbers in the benchtests.
On Friday 15 December 2017 10:36 PM, Carlos O'Donell wrote:
> That is good, and that will show up when it gets committed as a change
> in the performance for these named sets.
Sure, no harm in adding the numbers, I just pointed it out since I
reckoned that Ben didn't notice that patch.
>>> 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 firstname.lastname@example.org
>>> +## 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?
Sure, but that's more a Red Hat specific use case than an upstream use
case. From the upstream perspective we only care about the input and it
doesn't get treated any more specially than other inputs (my response to
Ben explains why). Maybe one way to deal with this is to upstream this
with just a comment at the end of the upstream namespace it belongs and
then replace the comment with the ##name tag in a downstream patch for