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

David Harrigan dharrigan at gmail.com
Mon Nov 21 16:15:44 EST 2011

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!
Simon Stopwatch: total 1015 s, counter 5000, max 292 ms, min 195 ms,
mean 203 ms [sequential INHERIT]
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.


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.

More information about the Concurrency-interest mailing list