[aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow

[Dmitrij Pochepko]

On 14/09/18 18:29, Andrew Dinn wrote:
> On 13/09/18 15:35, Dmitrij Pochepko wrote:
>> Other comments seems fine
> I am glad to hear that you did not find any errors in my analysis.
> However, I also need to ask you to answer a question that was implicit
> in my earlier note. I said:
>
> "I assume you are familiar with the relevant mathematics and how it has
> been used to derive the algorithm. If so then I would like you to review
> this rewrite and ensure that there are nor mathematical errors in it. I
> would also like you to check that the explanatory comments for of the
> individual steps in the algorithm do not contain any errors.
>
> If you are not familiar with the mathematics then please let me know. I
> need to know whether this has been reviewed by someone competent to do so."
>
> As you didn't respond to this I will have to ask you explicitly this
> time. Do you have a background in mathematics and numerical analysis
> that means you understand how the original algorithm has been arrived
> at? equally, how your algorithm may legitimately vary from that original?
  Yes, I do have relevant background in mathematics. And yes to the 
questions below but for the latest. That said, it's always good to have 
another pair of eyes looking at the review. To be honest, I had to 
refresh my memory regarding Remez polynomials.
>
> I'll break this down into several steps:
>
> Do you understand the (elementary) theory that explains how the various
> polynomial expansions I described in my comments converge to the
> original log and exp functions?
>
> Do you understand the theory that explains how partial polynomial sums
> (Remez polynomials) can be used used to approximate these polynomial
> expansions within specified ranges?
>
> Do you know how the coefficients of these Remez polynomial can be
> derived to any necessary accuracy?
>
> Do you understand how the computation of the values of those Remez
> polynomials must proceed in order to guarantee accuracy in the computed
> result in the presence of rounding errors?
>
> Can you provide a mathematical proof that the variations you have
> introduced into the computational process (specifially the move from
> Horner form to Estrin form) will not introduce rounding errors?
I have formal verification for some arguments ranges that I considered 
the most problematic, but the complete proof is too complicated. Looking 
at the situation from reviewer side I understand why it'll be safer and 
easier to maintain to have assembly version duplicate the original 
fdlibm code and because of that I suggest to revert questionable places 
to original schemas as the performance improvement is not that big.

new webrev with polynomial calculations changed back to original schema. 
Also changed scalbn implementation to be the same as original: 
http://cr.openjdk.java.net/~dpochepk/8189107/webrev.03/

As expected, it's about 2% slower.

Thanks,
Dmitrij

>
> I certainly cannot lay claim to a /thorough/ understanding of most, if
> not all, those topics. If you also cannot then I think we need to bring
> in someone who does. In particular, it is the last point that matters
> most of all here as this is where you have /chosen/ to make your
> algorithm diverge from the code you inherited.
>
> As regards the rest of the background maths, we do at least know that
> the other aspects of the algorithm -- in its original manifestation --
> have been checked by numerical experts. Hence, if we ensure that your
> algorithm implements /equivalent/ steps then it ought to inherit the
> same guarantees of correctness. So, the only task as far as most of the
> code is concerned is to iron out any errors you might inadvertently have
> introduced. I have several nits to pick in that regard that which I will
> be posting shortly.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander