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

[Simon Roberts]

Is there not also an architectural consideration here? I'm inclined to
think that just because execution in parallel finishes in less wall time
does not mean that's the right thing to do. Those CPUs will be unavailable
for other work, and in any multi-user/client type system, that effectively
makes life worse for the others, doesn't it?

On Tue, Nov 16, 2021 at 1:20 PM kabutz <duke at openjdk.java.net> wrote:

> On Tue, 16 Nov 2021 19:59:49 GMT, Joe Darcy <darcy at 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
>


-- 
Simon Roberts
(303) 249 3613