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

[Erik Österlund]

On Tue, 16 Nov 2021 21:22:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I would be wary to make any API use multiple threads behind the scenes without the user explicitly asking for it. While latency of the given operation might improve in isolation, parallelization always incur some (often significant) additional cost of computation. This might reduce power efficiency, reduce CPU availability for other tasks, and play tricks with scalability. 
> 
> 
> 
> Cost: On my system `multiply` burns about half as many cycles as `parallelMultiply`, even though it takes 2.4x longer (measured with `-prof perfnorm`).
> 
> 
> 
> Scalability: To simulate how well the solution scales you could try running the `multiply` and `parallelMultiply` micros with increasingly large `-t` values. (`-t` controls the number of threads running the benchmarks in parallel, default 1). On my system the advantage of `parallelMultiply` diminishes markedly as I saturate the system. On a test where I see a 2.4x speed-up at `-t 1` (`n = 50000000`), the advantage drops to 1.5x at `-t 4` and only gives me a 1.1x speed-up at `-t 8`.
> 
> 
> 
> I'd favor a public `parallelMultiply()`. Alternatively a flag to opt-in to parallelization.
> 
> 
> 
> (Nit: avoid appending flags to microbenchmarks that aren't strictly necessary for the tests, or such that can be reasonably expected to be within bounds on any test system. I didn't have 16Gb of free RAM.)
> 
> 

+1 on everything you said. We tell people not to oversaturate their CPUs because latencies then go out of the window then. It is then not helpful when the JDK internals automagically oversaturates the machine for you even though you didn't ask for it. And I can imagine a class like BigInteger being used in latency critical applications. It definitely ought to be an opt in, as opposed to a global opt out behind some flag that 99.9% of users dont know about and shouldn't have to know about, to do the expected thing. Principle of least surprise holds IMHO. 

Also, this is seemingly only a performance win if the rest of the machine is idle. It is far from obvious that the idling machine is in greater need of better performance, compared to the dangerously saturated machine. My gut feeling would be that it is the other way around. That might be another reason why it might not be a suitable default behaviour IMO.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409