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). Thanks, Brian 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.kukse...@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 >
