Hello Aleksey, Great job! I'm looking into your patch and have got few questions. Please, excuse my limited understanding of the topic.
1. I have noticed that you have replaced shiftLeft(1) with shiftLeftOneBit() in the following checks which appear . Is it performance critical part or just cleaning? // Checking if: remainder * 2 >= scaledDivisor remainder.abs().shiftLeftOneBit().compareTo(scaledDivisor.abs()) If this is critical, then why should we shift and copy (several times) the whole number just for the check? Checking that remainder * 2 >= scaledDivisor can be done more effectively without copying and shifting the number for cases when one number has more binary digits than another. 2. What is the meaning of 2 in the new function name unsignedMultAdd2? Why not unsignedMultAdd4? 2a. What is the purpose of the following fix? How a function call (even for a magic function), could be quicker than multiplication inlined by JIT? Does it mean our JIT poorly inlines multiplication? - long res = (aDigits[0] & 0xFFFFFFFFL) * (factor); + long res = unsignedMultAdd2(aDigits[0], factor, 0, 0); 3. You added a check against shifting zero values. Does adding this check on a common path add to performance? If zeroes come to shift function often enough to give a benefit, which caller spams so much zeroes? Does it worth to patch the caller instead? 4. I have an abstract concern with no idea how to address it. An integer array in memory is very similar to a long array (if endings are correct). Is there any way to use 64-bit operations for speed up? Thank you for a thoughtful patch. On Wed, May 21, 2008 at 7:16 PM, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > Hi, > > There are bunch of optimizations useful for RSA computation using > java.math, filed as HARMONY-5825 [1]. > Could someone please review this issue? > > Thanks, > Aleksey. > > [1] https://issues.apache.org/jira/browse/HARMONY-5825 > -- With best regards, Alexei
