Re: [PATCH 5/6] x86-64: Add pow/powf to libmvec microbenchmark

[Sunil Pandey <skpgkp2@gmail.com>]

Purpose of the libmvec microbenchmark test is to evaluate work path
performance reliably,
not to cover as much input range as possible.

On Thu, Nov 11, 2021 at 9:40 AM Sunil Pandey <skpgkp2@gmail.com> wrote:

>
>
> On Thu, Nov 11, 2021 at 2:39 AM Szabolcs Nagy <szabolcs.nagy@arm.com>
> wrote:
>
>> The 11/10/2021 19:31, Sunil Pandey via Libc-alpha wrote:
>> > On Wed, Nov 10, 2021 at 12:27 PM Joseph Myers <joseph@codesourcery.com>
>> > wrote:
>> >
>> > > On Tue, 9 Nov 2021, Sunil K Pandey via Libc-alpha wrote:
>> > >
>> > > > +# Random inputs in [a=0.01,b=100.00], [c=0.01,d=10.00]
>> > >
>> > > I think there should be a reasonable proportion of negative exponents,
>> > > unless you have evidence that negative exponents are rarely used in
>> > > practice.  (The *first* argument of pow being negative is of use
>> (produces
>> > > finite results) in much more limited cases, so may well be much
>> rarer.)
>> > >
>> >
>> > Negative exponents not used in the input file to avoid denormal
>> > processing. Negative
>> > exponent
>> > may hit the underflow domain when pow(x, -y) produces denormals as
>> results
>> > or as intermediate
>> >  values. Both going to touch very slow special pow() path and invokes
>> Intel
>> > software assist for
>> > denormals processing. All of this will distort the overall performance
>> > result of the main path.
>> > Also the base argument should be small so that it doesn’t produce
>> denormals.
>>
>> i'd expect typical negative exponents would not
>> cause subormal computations.
>>
>> does powf(100, -10) have intermediate underflow
>> with the x86 libmvec code?
>>
>
> It may cause intermediate underflow for single precision function, because
> result
> get quite close to the underflow domain and intermediate values may be
> even smaller.
>