RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v2]

Joe Darcy darcy at openjdk.java.net
Fri Nov 19 00:28:43 UTC 2021


On Wed, 17 Nov 2021 19:11:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> 
> 
> > I also do not like potentially non-obvious default behavior, nor a command line flag, nor a (static) setting on `BigInteger`. Thus I think the original `parallelMultiply()` (or perhaps `multiplyParallel()`) would be preferable.
> 
> For the parallel supported features we added in Java 8 we made it explicit for the reasons you and others have stated.
> 
> > Would adding a parameter in the nature of `maxProcessors` make any sense?
> 
> Kind of but i would recommend not doing it. That's hard to express in a manner that developers will choose appropriate values across all deployments. This is why you don't see such configuration for parallel streams or the parallel array operations. It's controlled by the common pool parallelism configuration (developers have learnt the trick of running within some constrained F/J task to limit parallelism but that is unsupported behaviour). The closest we get to anything configurable is a parallelism threshold for methods on `ConcurrentHashMap`, where the developer can assess the cost of transformation per element in combination with how many elements to be processed (likely assessed empirically from performance measurements).
> 
> --
> 
> I would like to get a sense of how common it might be that developers operate on very large numbers that this becomes worthwhile while supporting.
> 
> The implementation looks reasonable and quite cleverly minimal, but I think it would be useful to get a sense of whether the recursion goes beyond some proportion of # runtime processors after which there is likely no point in creating more recursive tasks e.g. from the size in bits of the inputs can we determine a useful approximate threshold?

I think the functionality in this PR is worth pursuing, but with the JDK 18 rampdown 1 date fast approaching, as a non-urgent issue, I think we shouldn't try to rush it into JDK 18.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409


More information about the core-libs-dev mailing list