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

[Alan Bateman]

On 16/05/2013 15:50, David Chase wrote:
> :
>
> Parallel performance is a little harder to reason about on big x86 boxes (both Intel and AMD), so I am leaving the threshold high.  Dave Dice thought this might be an artifact of cores being put into a power-saving mode and being slow to wake (the particular benchmark I wrote would have been pessimal for this, since it alternated between serial and parallel phases).  The eventual speedups were often impressive (6x-12x) but it was unclear how many hardware threads (out of the 32-64 available) I was using to obtain this.  Yes, I need to plug this into JMH for fine-tuning.  I'm using the system fork-join pool because that initially seemed like the good-citizen thing to do (balance CRC/Adler needs against those of anyone else who might be doing work) but I am starting to wonder if it would make more sense to establish a small private pool with a bounded number of threads, so that I don't need to worry about being a good citizen so much.  It occurs to me, late in the game, that using big-ish units of work is another, different way to be a bad citizen.  (I would prefer to get this checked in if it represents a net improvement, and then work on the tuning afterwards.)
>
I'm sure Doug or Brian or David Holmes will have opinions on this point 
but I would think using the common pool is right. If parallel sort, 
CRC32 and other specific usages each created their own thread pool then 
I could imagine a lot of thread pools hanging around and competing. Plus 
there are cases like EE where no-parallelism might be the right answer 
and one wouldn't want to have to configure each usage.

In any case, this looks really good work. One thing that might be worth 
checking is startup/warm-up. I have a vague memory of this being a 
concern in the past with Adler32, Sherman might remember the details.

-Alan.