Status update: BigInteger performance enhancements

Louis Wasserman lowasser at google.com
Tue Jun 11 23:04:38 UTC 2013


Any update on http://bugs.sun.com/view_bug.do?bug_id=7131192 ?


On Tue, Jun 11, 2013 at 2:31 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> We previously identified four phases of BigInteger performance improvement
> based on contributions from Alan Eliasen and Tim Buktu:
>
> 1) Multiplication and exponentiation -
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 and
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474
> 2) Conversion to string -
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897
> 3) Division - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014319
> 4) Multiplication and division of very large integers -
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014320
>
> The current status by phase is as follows:
>
> 1) 4837946 and 4646474
> * Code reviewed by me and posted for public review -
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html.
> * Correctness verification partially complete.
> * Preliminary micro-benchmarking on development laptop.
>
> 2) 4641897
> * Code reviewed by me but not yet posted.
> * Rudimentary micro-benchmarking on development laptop.
>
> 3) 8014319
> No progress.
>
> 4) 8014320
> No progress.
>
> On my development laptop, micro-benchmarking suggested that the values of
> the multiplication, squaring, and radix conversion algorithm crossover
> thresholds for phases 1 and 2 are significantly lower than they should be.
> On other, newer systems, the values appeared to be fairly close to
> appropriate values.
>
> The current plan is in effect first to identify reasonable values for
> these thresholds which do not exhibit performance regressions on the matrix
> of platforms of interest. The idea has also surfaced to define system
> properties by means of which the thresholds could be set by applications.
> Given the availability of such properties, the threshold values estimated
> by micro-benchmarking would be the default values if no system property
> were specified for the threshold of interest.
>
> Work on threshold evaluation and the review and validation testing of
> phase 3 will continue in parallel with other work, some of which will
> likely affect the same code in which case the changes will be merged.
>
> Brian




-- 
Louis Wasserman



More information about the core-libs-dev mailing list