Yes but that does not help with the decision if parallel should be used or not. But yes, if it is generally not wanted to make the pool explicite a simple parallel signature without argument would also work to make the decision explicite (I.e. new api). That won’t automatically tune the performance but it does allow users to use it - majority would be crypto anyway where it can be used by the JCE and JSSE (maybe?).
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Remi Forax <fo...@univ-mlv.fr> Gesendet: Thursday, November 18, 2021 12:16:31 PM An: Bernd Eckenfels <e...@zusammenkunft.net> Cc: core-libs-dev <core-libs-dev@openjdk.java.net> Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3] ----- Original Message ----- > From: "Bernd Eckenfels" <e...@zusammenkunft.net> > To: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Sent: Jeudi 18 Novembre 2021 12:07:19 > Subject: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger > [v3] > What about a new API multiply method which takes an forkjoinpool, and only if > that is used/specified it will use the parallel mode (and only if Notsitzes > threshold applies?). Most of the pool tuning can then done with this argument. > It also avoids surprise threads. You don't need it, here is the usual trick if you want to specify a specific fork join pool https://stackoverflow.com/questions/21163108/custom-thread-pool-in-java-8-parallel-stream > > Gruss > Bernd regards, Rémi > -- > http://bernd.eckenfels.net > ________________________________ > Von: core-libs-dev <core-libs-dev-r...@openjdk.java.net> im Auftrag von kabutz > <d...@openjdk.java.net> > Gesendet: Thursday, November 18, 2021 11:41:40 AM > An: core-libs-dev@openjdk.java.net <core-libs-dev@openjdk.java.net> > Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger > [v3] > > On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes <dhol...@openjdk.org> wrote: > >> To add my 2c IMO a parallel version of this type absolutely **must** be >> opt-in. >> There are simply far too many side-effects of using the FJP and multiple >> threads to perform the calculation in parallel as if it is just a minor >> implementation detail. A clear API is 1000x better than a "kill switch". >> >> And yes you may still need to expose some kind of tuning knob. >> >> David > > Yes, it **must** be opt-in. However I'm not sure that a tuning knob will be > necessary. BigInteger has thresholds for using different multiply algorithms > and these are also not configurable. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/6409
