RFR: 4837946 - Faster multiplication and exponentiation of large integers

Brian Burkhalter brian.burkhalter at oracle.com
Fri May 17 23:03:39 UTC 2013

Sergey / David,

Thanks for the observations.

I am disinclined at this time to try to modify in any major way the algorithmic changes represented by the four previously identified phases of BigInteger performance improvement. These changes have been in the queue for a very long time so I think it would be best to focus on evaluating and integrating them essentially as-is without risking additional delay by attempting further simultaneous modifications. I would suggest that instead, any other prospective ameliorations be tracked by new issues (enhancement requests).



On May 17, 2013, at 5:56 AM, David Chase wrote:

> There's been a little pushback against that use of forkjoin, though (as the author of the CRC/Adler work it seems like a reasonable idea to me).  One worry I have had is that in a larger context we are worried not just about speed, but also about efficiency; using 4 threads for a 3x speedup is in fact "less efficient" than using just 1 thread, but not by a lot.  Using 32 threads for a 9x speedup is a good deal less efficient.  (And note I am saying "threads", not "tasks", there are good reasons for breaking big jobs down into more tasks than threads, since not all tasks take the same time to finish and the straggler determines the overall time).
> David
> On 2013-05-17, at 4:23 AM, Sergey Kuksenko <sergey.kuksenko at oracle.com> wrote:
>> Hi Brian,
>> In the parallel thread I see a new implementation of CRC32 & Adler32. I don't mean new HW intrinsics, I mean parallel operation using ForkJoinPool. I think BigInteger operations may be a better candidate for such kind of parallelization. For example Karatsuba may be forkjoined naturally.
>> -- 
>> Best regards,
>> Sergey Kuksenko

More information about the core-libs-dev mailing list