[concurrency-interest] A beginner question (on fork-and-join)

Nathan Reynolds nathan.reynolds at oracle.com
Mon Nov 21 16:40:36 EST 2011


Microbenchmarks are incredibly hard to get right.  For example, HotSpot 
7 JVM won't do a full optimization of a method until 10,000 
invocations.  You need to bump up the priority of the test thread so 
that other things on the system don't add noise.  These probably aren't 
applicable to your case, but you may to force a full GC right before 
running the test.

You probably want to use http://code.google.com/p/caliper/ which deals 
with all of these gotchas.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 11/21/2011 2:15 PM, David Harrigan wrote:
> Hi Everyone,
>
> I'm learning about the fork and join framework in JDK7 and to test it
> out I wrote a little program that tries to find a number at the end of
> a list with 50,000 elements.
> What puzzles me is when I run the "find" in a sequential fashion, it
> returns faster than if I use a fork-and-join implementation. I'm
> running each "find" 5000 times
> so as to "warm" up the JVM. I've got a timing listed below:
>
> Generating some data...done!
> Sequential
> Simon Stopwatch: total 1015 s, counter 5000, max 292 ms, min 195 ms,
> mean 203 ms [sequential INHERIT]
> Parallel
> Simon Stopwatch: total 1352 s, counter 5000, max 4.70 s, min 243 ms,
> mean 270 ms [parallel INHERIT]
>
> (some runtime information)
>
> openjdk version "1.7.0-ea"
> OpenJDK Runtime Environment (build 1.7.0-ea-b215)
> OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)
>
> 2.66Mhz Intel Core i7 with 8GB RAM (256KB L2 cache per core (4 cores)
> and 4MB L3 cache) running on a MBP (Lion 10.7.2)
>
> Forgive my ignorance but this type of programming is still quite new
> to me and I'm obviously doing something wrong, but I don't know what.
> My suspicion is
> something to do with spinning up and down threads and the overhead
> that entails. I've posted the src here http://pastebin.com/p96R24R0.
>
> My sincere apologies if this list is not appropriate for this posting,
> if so I would welcome a pointer on where I can find more information
> to help me understand
> better the behaviour of my program when using F&J.
>
> I thought that by using F&J I would be able to find the answer quicker
> than doing the searching sequentially, perhaps I've choosen a wrong
> initial problem to
> test this out (something that is suited to a sequential search and not
> a parallel search?)
>
> Thank you all in advance.
>
> -=david=-
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111121/c94ecd5c/attachment-0001.html>


More information about the Concurrency-interest mailing list