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

David Holmes davidcholmes at aapt.net.au
Tue Nov 22 00:23:23 EST 2011


The typical/usual approach with FJ is to submit only a single top-level task
via FJPool.invoke/submit and that task then does the parallel decomposition
via fork/join. Your algorithm, which I confess I can not follow, creates
numerous top-level tasks - which is more akin to submitting tasks to a plain

To avoid all the other microbenchmark gotchas trying running with -Xint and
do away with all the warmups; or keep a simple warmup and run with -Xcomp.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of David
> Harrigan
> Sent: Tuesday, 22 November 2011 7:16 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] A beginner question (on fork-and-join)
> 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=-
> --
> I prefer encrypted and signed messages. KeyID: B20A22F9
> Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9
> "It is not usually until you've built and used a version of the
> program that you understand the issues well enough to get the design
> right." - Rob Pike, Brian Kernighan.
> No trees were harmed in the sending of this message, however, a number
> of electrons were inconvenienced.
> _______________________________________________
> 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