JDK 8 RFR 4891331: BigInteger a.multiply(a) should use squaring code
joe.darcy at oracle.com
Wed Nov 27 19:53:25 UTC 2013
Looks good; approved to go back.
On 11/27/2013 11:39 AM, Brian Burkhalter wrote:
> Continuing from the end of this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022399.html ...
> Issue: https://bugs.openjdk.java.net/browse/JDK-4891331
> Webrev: http://cr.openjdk.java.net/~bpb/4891331/webrev.2
> After running more micro-benchmark performance tests using a threshold on the int-length of BigInteger above which squaring code is used for multiply(this), the value 20 appears more apropos. This is the value in the updated webrev. This threshold appears to prevent regressions across the array of machines tested (Linux, Mac, Windows, AMD, Intel). In some cases of course, the threshold prevents performance improvement which would otherwise occur. This is the cost of avoiding regressions.
> It should be noted that a small regression, on the order of 1%-3% is often observed for the case of unity int-length, i.e., when the BigInteger is equivalent to an int. This is apparently the cost of the added conditional val == this. It does not seem to me however to be of sufficient import to argue against going forward with the patch.
More information about the core-libs-dev