RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

[Paul Sandoz]

On May 17, 2013, at 12:09 AM, David Chase <david.r.chase at oracle.com> wrote:

> 
> On 2013-05-16, at 5:27 PM, Alan Bateman <Alan.Bateman at 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. 

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.


> Right now, the update methods run in parallel for sufficiently large inputs, otherwise serial.  I'm still unsure whether their appetite for tasks should be throttled somewhat above and beyond the size limit.  There's benefit to having CRC run 3x faster if it uses 4 threads to do it, but using 32 threads to run 9x faster is maybe not a win, even though it is nominally "faster".  And here I mean "threads", not tasks, though I don't have a lot of visibility how much of a multiprocessor I am eating when I break something into 32 or 64 tasks.
>