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 can one imagine a way of checking that a number is twice bigger than another number without copying and shifting the number? For cases when one number has more binary digits than another this should be easy. 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
