On Wed, 17 Nov 2021 18:20:07 GMT, Brian Burkhalter <b...@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? ------------- PR: https://git.openjdk.java.net/jdk/pull/6409
