On Wed, 17 Nov 2021 17:51:03 GMT, Erik Österlund <eosterl...@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. Considering how much memory is allocated by BigInteger, I'd be surprised if latency critical applications used it. Besides, we are talking about rather large calculations, with numbers that are thousands of bits large. But of course I agree that opt-in would be better. > 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. This is why I tried to keep the behaviour similar to what we are used to - parallel streams have to be explicitly opted in and I hardly ever do it in real code. Same with parallelSort() ------------- PR: https://git.openjdk.java.net/jdk/pull/6409
