On Tue, 16 Nov 2021 19:59:49 GMT, Joe Darcy <da...@openjdk.org> wrote:
> As you cite, there are a few other cases in the JDK API were a second > "parallelFoo" method is exposed. However, I don't think those precedents > would necessarily mandate a parallelMultiply method in BigInteger. Without a > separate method, there is a question of tuning of course. Hi Joe, I guess with sorting it makes sense to have two different methods, because it is usually quite a bit slower to parallel sort an already sorted array. Similarly, if the array is short, we don't want to unnecessarily default to trying to do it in parallel. This is different. By the time we are doing a Toom-Cook calculation, we already have thousands of bits that we are multiplying together, thus a rather large number. In all likelihood doing the multiplication in parallel will always be faster, provided that we have enough cores. In that case though, we would need a fall-back in case we have no threads in the common FJP. We could decide that when the multiply() is called and then do the calculation sequentially. We probably also need to be able to turn it off entirely. Perhaps with something like -Djava.math.BigInteger.disableParallelMultiply=true. Heinz ------------- PR: https://git.openjdk.java.net/jdk/pull/6409
