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
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