On Wed, 17 Nov 2021 19:11:35 GMT, Paul Sandoz <[email protected]> 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
