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

Gregg Wonderly gregg at cytetech.com
Mon Nov 21 17:36:20 EST 2011

So I have to ask, why don't you use the command line property to change this to 
something like 100 for a faster warm up?  For some of my applications, doing 
this reduces startup time by orders of magnitude because of the number of times 
some things are invoked.  In particular, server applications using a security 
manager seem to start much faster.

Gregg Wonderly

On 11/21/2011 3:40 PM, Nathan Reynolds wrote:
> 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 herehttp://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=-
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list