On 2013-05-17, at 4:28 AM, Paul Sandoz <paul.san...@oracle.com> wrote:
> > On May 17, 2013, at 12:09 AM, David Chase <david.r.ch...@oracle.com> wrote: > >> >> On 2013-05-16, at 5:27 PM, Alan Bateman <alan.bate...@oracle.com> wrote: >>> The current proposal doesn't change the API at this time but I wonder if >>> you have considered adding parallelUpdate methods to complement the serial >>> methods? >> >> I'm not sure I understand. > > Alan may be suggesting that the caller should explicitly, but unobtrusively, > opt in to parallel execution rather than it being something implicit. Right, but I was responding to this in the context of a compiler bug -- they just wanted CRC32 and Adler32 to go faster, and were not asking for a new interface. My intent/assumption was that if I used the System forkjoin pool for this, that if there were a problem with what I might call "obnoxious parallelism", that the person running the application would turn down the parallelism in the system fork-join pool. If we use forkjoin to make other things go faster (e.g., BigInteger arithmetic and/or formatting) they'll have exactly the same problem, and either they'll have to independently try to deal with it there (in the same way that I worry about whether the CRC/Adler code should be self-throttling) or assume that it will be solved by the same knob being turned (by whoever is tuning the whole application). Baking it in as a static decision is just kicking the can down the road -- once some module that computes CRCs as part of its larger work chooses serial or parallel, what then, if that module's client doesn't like that decision? Another option is to keep an interface, but add a system property enabling or disabling it. I'm not sure that's the right approach; there is a sun. property that I use to check the tuning, but as soon as FJ is widely used (and perhaps statically baked in to some larger modules, even if we adopt the ask-for-parallel method idiom), those selective-disable properties will multiply like bunnies, and I don't think that's a good idea (documentation, testing, arrgh). > That is the approach we have taken for the Streams API, parallel sort and > parallel prefix of arrays in JDK 8 [*]. It's a least surprise principle of > libraries "not eating more compute resources unless you ask it to". I think > Adler32 and CRC32 should stick to the same principle and require opt in from > the caller, thus implying this behaviour cannot be part of the public API in > JDK 7. > > Paul. > > [*] In JDK 8 the Arrays.parallelSort methods use an array length threshold of > 2^13, arrays <= to that length will be sorted sequentially and arrays > than > will be sorted in parallel. IIUC the threshold was chosen to ensure that > Arrays.parallelSort is ~ the same as or faster than Arrays.sort. I picked a threshold for 512K for slow CRC and 1M for Adler and fast CRC, in a conservative approximation of the same reasoning. David
