On Wed, 17 Nov 2021 19:11:35 GMT, Paul Sandoz <psan...@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

Reply via email to